CUA-admin-guide

Это относительно подробное руководство создано для введения в курс дела системных администраторов.

Описание системы

Речь будет идти об инфраструктуре CUA (Centralized User Administration). Она представляет собой комплексная система, призванная/ориентированная на централизованное управление учетными записями сотрудников и ресурсами компании (контролируя доступ к файлам, приложениям и другим данным).

Система разработана для повышения безопасности, эффективности и удобства работы сотрудников, в особенности работающих удалённо.
С помощью VPN для защищённого соединения, CUA, будет обеспечивать безопасный доступ к необходимым для работы ресурсам.
Система также включает в себя функции мониторинга и резервного копирования, благодаря чему системные администраторы смогут быстро реагировать на неисправности и легко поддерживать систему.

Система состоит из следующих нод:
1. CA node
Отвечает за создание и подпись цифровых сертификатов с использованием EasyRSA. В частности, обеспечивает управление ключами и сертификатами, необходимыми для аутентификации и шифрования в VPN-соединениях.
2. VPN node
Узел, через который проходит весь зашифрованный трафик от сотрудников к корпоративным ресурсам; устанавливает безопасное VPN-соединение и управляет доступом пользователей к сети компании.
3. Monitoring node
Предназначен для наблюдения за работой всей системы. Отслеживает состояние серверов и сервисов, предупреждает о неисправностях в инфраструктуре (алерты).
4. Two backup nodes (№1 and №2)
Обеспечивают резервное копирование важных данных с двух нод: CA и VPN. Таким образом гарантируют сохранность этих данных в случае сбоев или потери самих данных, позволяя восстановить данные и, тем самым, работоспособность системы после сбоев.

Проект расположен на gitlab.com в репозитории под названием cua-infrastructure-setup (это и есть название проекта): https://gitlab.com/arut_plus/cua-infrastructure-setup
+ Облачный провайдер: Yandex Cloud
+ Название облака: cua-cloud
+ Название аккаунта: cua-account
доступ имеет (на момент сдачи проекта) только один человек: Я (создатель проекта).
+ Название сервисного аккаунта: cua-service-account

Компоненты инфраструктуры

Описание компонентов

CA node

На ноде разворачивается EasyRSA, который выполняет роль центра сертификации (CA), создавая и управляя инфраструктурой открытых ключей (PKI), необходимой для генерации сертификатов и ключей, которые обеспечивают аутентификацию и шифрование в OpenVPN. Всё просто.

VPN node

Ключевую функцию во всей инфраструктуре - создание защищенных частный виртуальных сетей (VPN) - выполняет VPN-нода. На нем разворачивается EasyRSA и OpenVPN, и последний выполняет роль VPN сервера.

Backup nodes

Для выполнения резервного копирования важных данных на CA и VPN нодах задействуются две (во избежание единой точки отказа) backup ноды, на которых ставится утилита rsync, запланированную работу которого обеспечивает systemd. (Также реализован самописный алертинг для бэкапов).

Monitoring node

С помощью утилит Prometheus, Alertmanager и Grafana обеспечивается мониторинг за ключевыми сервисами всех нод и алертинг, то есть, система оповещения о проблемах и сбоях в системе.

Взаимодействие компонентов

Для более легкого понимания этой "главы" рекомендую параллельно смотреть в "Схему потоков данных в CUA инфраструктуре", которая, по сути, визуализирует описанное ниже.
В Readme указано, где можно найти изображения этих схем.

Взаимодействие CA и VPN нод

В схеме взаимодействия CA - VPN нод первый лишь отвечает на запросы второго. То есть, VPN нода отправляет запросы на подпись сертификатов CA ноде и получает от нее "ответы". Всё их взаимодействие осуществляется с помощью ssh.
Есть два типа запросов, которые отправляет VPN нода:
1. Подписание серверного сертификата
+ Генерируется запрос на сертификат для сервера (easyrsa gen-req server)
+ Запрос отправляется на CA ноду по ssh с помощью библиотечной функции Sign_Request.lib
+ CA нода подписывает запрос и возвращает готовый серверный сертификат
2. Подписание клиентского сертификата
+ Генерируется запрос на сертификат для клиента (easyrsa gen-req <client-ID>)
+ Запрос отправляется на CA ноду по ssh с помощью библиотечной функции Sign_Request.lib
+ CA нода подписывает запрос и возвращает готовый клиентский сертификат

Взаимодействие Backup нод с CA и VPN нодами

Для удобства буду описывать взаимодействие одной из backup нод к CA и VPN нодам, ибо вторая backup нода делает абсолютно тоже самое, что и первая. Вторая нода является функциональной копией первой и нужна во избежание единой точки отказа, как я писал выше.
Здесь тоже всё взаимодействие осуществляется с помощью ssh, но в обертке rsync, то есть rsync на backup ноде использует ssh для взаимодействия с нодами CA и VPN.

В итоге, backup нода с помощью rsync (via ssh) выполняет резервное копирование важных данных с CA и VPN нод к "себе" в файловую систему.

Взаимодействие Monitoring и остальных нод

На каждой ноде запущены экспортеры метрик системы/служб, к которым "обращается" prometheus, запущенный на monitoring ноде, для получения тех самых метрик и дальнейшей их обработки, передачи другим локальным сервисам (grafana, alertmanager).
На этом взаимодействие monitoring ноды ко всем остальным нодам заканчивается, а более подробное описание системы мониторинга будет в отдельной соответствующей главе ниже.

Создание виртуальных машин. Terraform и Yandex.Cloud

Terraform выбран как IaS (Infrastructure as code) инструмент для работы с Yandex.Cloud, ибо последний официально поддерживает операции в облаке с помощью terraform. И IaS подход проще автоматизировать.

Далее последуют команды, которые позволят поднять все нужные виртуальные машины для дальнейшей развертки на них компонентов CUA инфраструктуры.

Инструкция по поднятию виртуальных машин в Yandex.Cloud с помощью Terraform

Предполагается, что вы уже авторизованы в Yandex.Cloud через Yandex аккаунт и привязали банковскую карту к платежному аккаунту Yandex.Cloud

Для начала потребуется установить yc-cli (Yandex.Cloud CLI tool) и авторизоваться по инструкции из официальной документации.

Важно

Все дальнейшие команды нужно делать, находясь в папке ~/cua-infrastructure-setup/cloud/ .
К примеру, чтобы файл authorized_key.json создался при экспорте именно в этой папке (этот файл нужен будет terraform-у).

Далее нужно создать сервисный аккаунт (для работы с terraform):

Bash

yc iam service-account create --name cua-service-account

Назначить сервисному аккаунту роли, необходимые для управления ресурсами Yandex.Cloud:

Bash

yc resource-manager cloud add-access-binding cua-cloud \
  --role resource-manager.clouds.owner \
  --service-account-name cua-service-account

Экспортировать ключ сервисного аккаунта в файл authorized_key.json:

Bash

yc iam key create \
  --service-account-name cua-service-account \
  --folder-name default \
  --output authorized_key.json

Необходимо настроить профиль CLI (cloud-id и folder-id берутся с профиля по-умолчанию) и сменить (активировать) на настроенный:

Bash

YC_CLOUD_ID="$(yc config get cloud-id)"
YC_FOLDER_ID="$(yc config get folder-id)"
export YC_CLOUD_ID YC_FOLDER_ID

yc config set service-account-key authorized_key.json
yc config set cloud-id "$YC_CLOUD_ID"
yc config set folder-id "$YC_FOLDER_ID"

yc config profile activate sa-terraform

Нужно внести следующие строки в ~/.terraformrc для корректной работы провайдера (Yandex.Cloud):

Terraform

provider_installation {
  network_mirror {
    url     = "https://terraform-mirror.yandexcloud.net/"
    include = ["registry.terraform.io/*/*"]
  }
  direct {
    exclude = ["registry.terraform.io/*/*"]
  }
}

Дальше начинается само создание виртуальных машин.
Для этого нужно инициализировать terraform (Напоминаю: в папке ~/cua-infrastructure-setup/cloud/):

Bash

terraform init

Создать нужные сети, подсети и сами ВМ (виртуальные машины):

Bash

source ../scripts/env.sh

terraform apply \
  -var "CA_NODE_IP=$CA_NODE_IP" \
  -var "VPN_NODE_IP=$VPN_NODE_IP" \
  -var "BCK1_NODE_IP=$BCK1_NODE_IP" \
  -var "BCK2_NODE_IP=$BCK2_NODE_IP" \
  -var "MON_NODE_IP=$MON_NODE_IP"

После того, как terraform закончит свою работу, уведомив о запущенных и готовых сетях, подсетях и ВМ, нужно осуществить передачу ssh ключей на нужные ВМ (для возможности их "общения"):

Bash

./transfer-ssh-keys.sh

На этом работа с terraform заканчивается.

Для дальнейшей работы с ВМ можно использовать команду terraform output, которая покажет внешние IP адреса для подключения.
Дефолтный юзер на машинах будет заменен юзером под именем admin с помощью cloud-init скрипта, поэтому для подключения к ВМ нужно будет использовать, примерно, такую команду:

Bash

ssh admin@12.34.56.78

Дополнительные материалы по этой главе:
Начало работы с Terraform
Метаданные виртуальной машины

Развертывание серверов

Как устроены деплой-скрипты?

Скрипты написаны на bash по соответствии с лучшими практиками bash и с использованием идиоматических конструкций (которые разъясняются комментариями в самих скриптах), характерных для bash.

Во всех скриптах реализована обработка ошибок в виде функции в начале скрипта под названием Error_Handler.
В скриптах, в которых требуются запуск от имени суперпользователя, реализована проверка прав суперпользователя.
Скриптам, поддерживающим аргументы при запуске, можно передать ключ -h или --help для получения информации об использовании (usage info/help text).
Скрипты подтягивают и инициализируют глобальные переменные из env-файла set-env.sh.
В деплой-скриптах после запуске в самом начале запрашивается пароль для юзера с именем admin и устанавливается срок действия пароля в 90 дней для большей безопасности.
В деплой-скриптах реализована конфигурация правил iptables (для каждой ноды - своя).
Запуск деплой-скриптов с помощью библиотечного скрипта Install_Docker.lib устанавливает docker, который нужен, как минимум, для запуска экспортеров. В Install_Docker.lib нет ничего особенного - просто устанавливает docker, а вынесен в отдельную библиотечную функцию во избежание дублирующихся строк кода, ибо используется во всех деплой-скриптах.
Во всех деплой скриптах запускается библиотечный скрипт Security_Configuration.lib, который выполняет следующие операции для повышения общей безопасности системы:
- Установка срока действия пароля пользователя (как было сказано выше)
- Ограничение прав доступа для конфигурационных файлов и директорий
- Установка failban и конфигурация с помощью deb пакета fail2ban-config_1.0.deb
- Конфигурация sshd с помощью deb пакета sshd-config_1.0.deb
- Установка iptables, iptables-persistent
- Установка rsyslog
- Установка ntp и настройка часового пояса
- Установка unattended-upgrades и конфигурация с помощью deb пакета unattended-upgrades-config_1.0.deb
- Конфигурация sysctl с помощью deb пакета sysctl-config_1.0.deb

Всё описанное выше повторяется во всех деплой-скриптах, поэтому в следующих главах будут описаны только те части скрипта, которые отличаются от упомянутых выше.

Развертывание компонентов на CA ноде

После подключения к CA ноде нужно перейти в директорию, где находятся все деплой-скрипты и запустить deploy-CA-node.sh с правами суперпользователя:

Bash

cd ~/cua-infrastructure-setup/scripts
sudo ./deploy-CA-node.sh

Что делает скрипт `deploy-CA-node.sh` ?

Установка и настройка EasyRSA:
- После установки EasyRSA создается директория для симлинков на файлы EasyRSA (/usr/share/easy-rsa/*)
- Инициализируется PKI
- Устанавливается конфигурационный deb пакет easyrsa-config_1.0.deb
- Создается CA сервер
Docker compose:
- Запускается node-exporter

Как проверить работу сервисов после деплоя?

Можно проверить состояние контейнеров:

Bash

docker ps
# и логи можно проверить:
docker logs --follow <container_name>

Развертывание компонентов на VPN ноде

После подключения к VPN ноде нужно перейти в директорию, где находятся все деплой-скрипты и запустить deploy-VPN-node.sh с правами суперпользователя:

Bash

cd ~/cua-infrastructure-setup/scripts
sudo ./deploy-VPN-node.sh

Что делает скрипт `deploy-VPN-node.sh`

Установка, настройка EasyRSA и управление сертификатами:
- После установки EasyRSA создаются директории для EasyRSA и клиентских файлов
- Инициализируется PKI и генерируется запрос на серверный сертификат
- Запрос подписывается на CA сервере и возвращается готовый серверный сертификат. Это делается с помощью библиотечной функции Sign_Request, которая делает следующее:
  1. Отправка запроса на CA сервер путем перемещения туда файла запроса на сертификат с помощью scp.
  2. Подпись запроса на CA сервере удаленной командой с помощью ssh
  3. Получение подписанного сертификата через scp
- Также генерируется секретный ключ для tls-crypt.
Установка и конфигурация OpenVPN:
- После установки OpenVPN устанавливается конфигурационный пакет openvpn-config_1.0.deb
- Включается IP forwarding в sysctl
Docker compose:
- Запускается node-exporter
- Запускается openvpn-exporter

"Что делает скрипт `make-ovpn.sh`?" или "Как генерировать клиентские конфиг файлы .ovpn"

Для генерации клиентских конфиг файлов с расширением .ovpn, которые нужны клиентам для подключения к VPN, нужно воспользоваться скриптом make-ovpn.sh в директории ~/cua-infrastructure-setup/scripts. Скрипт делает следующее:
1. Генерация запроса на клиентский сертификат
2. Подпись сертификата с помощью библиотечной функции Sign_Request (с которой вы уже знакомы)
3. Создание клиентского конфигурационного файла (.ovpn)
4. Вывод в консоль пути к созданному файлу конфигурации клиента (.ovpn).

Как проверить работу сервисов после деплоя?

Можно проверить состояние контейнеров:

Bash

docker ps
# и логи можно проверить:
docker logs --follow <container_name>

Можно проверить состояние служб systemd:

Bash

systemctl status openvpn-server@server.service

В случае с подключением к VPN со стороны клиентов нужно будет проверить, корректно ли работает подключение в клиентском приложении OpenVPN и меняется ли внешний IP адрес адрес после подключении к VPN в специальных сервисах:
Яндекс Интернетометр
2ip.ru
MYIP.com

А состояние клиентов можно мониторить в web интерфейсе Grafana в соответствующем дашборде.

Развертывание компонентов на Backup нодах

После подключения к одной из Backup нод нужно перейти в директорию, где находятся все деплой-скрипты и внести в файл set-env.sh нужные конфиденциальные данные - пароли и электронную почту для алертинга (на последних строчках).
Далее просто запустить deploy-backup-node.sh с правами суперпользователя:

Bash

cd ~/cua-infrastructure-setup/scripts

# Добавьте данные для аутентификации в файл set-env.sh и только потом:
sudo ./deploy-backup-node.sh

Это нужно повторить и на второй Backup ноде.

Что делает скрипт `deploy-backup-node.sh`

Настройка rsync:
- После установки rsync создаются директории для резервного копирования
- Устанавливается deb пакет rsync-systemd-setup_1.0.deb для настройки службы и таймера systemd
- Локальные IP адреса CA и VPN нод для вставляются в бэкап-скрипт /usr/local/bin/backup.sh с помощью sed
- Перезагружается systemd daemon и запускается служба rsync-backup.
Docker compose:
- Запускается node-exporter

Как проверить работу сервисов после деплоя?

Можно проверить состояние контейнеров:

Bash

docker ps
# и логи можно проверить:
docker logs --follow <container_name>

Можно проверить состояние служб systemd:

Bash

systemctl status rsync-backup.service
systemctl status rsync-backup.timer

Можно вручную проверить содержимое директорий для резервного копирования, которые находятся в ~/backup_dir.

Более подробно работа системы резервного копирования будет описана в соответствующей главе ниже.

Развертывание компонентов на Monitoring ноде

После подключения к Monitoring ноде нужно перейти в директорию, где находятся все деплой-скрипты и внести в файл set-env.sh нужные конфиденциальные данные - пароли и электронную почту для алертинга (на последних строчках).
Далее просто запустить deploy-monitoring-node.sh с правами суперпользователя:

Bash

cd ~/cua-infrastructure-setup/scripts

# Добавьте данные для аутентификации в файл set-env.sh и только потом:
sudo ./deploy-monitoring-node.sh

Что делает скрипт `deploy-monitoring-node.sh`

Docker compose:
- Запускается node-exporter
- Запускается prometheus
- Запускается alertmanger
- Запускается grafana

Как проверить работу сервисов после деплоя?

Можно проверить состояние контейнеров:

Bash

docker ps
# и логи можно проверить:
docker logs --follow <container_name>

Можно проверить доступность сервисов по их web интерфейсу:

Bash

curl --head http://localhost:9093 # Alertmanager
curl --head http://localhost:1194 # OpenVPN
curl --head --user admin http://localhost:3000 # Grafana
curl --head --user admin http://localhost:9090 # Prometheus

Можно проверить состояние target-ов в prometheus по ссылке http://<IP>:9090/api/v1/targets.

Можно проверить метрики и алерты в web интерфейсах Grafana, Prometheus и Alertmanager.

Более подробно работа системы мониторинга будет описана в соответствующей главе ниже.

Система резервного копирования

Как работает?

Система резервного копирования автоматически выполняет резервное копирование важных данных с CA и VPN нод на резервную ноду, то есть, к себе в файловую систему по пути ~/backup_dir/.
Важные данные - это директория ~/easy-rsa на CA ноде и директории ~/easy-rsa, ~/OpenVPN-clients на VPN ноде.
Для каждой ноды есть своя директория в ~/backup_dir: ~/backup_dir/CA_node/ и ~/backup_dir/VPN_node/.
Система использует rsync для копирования данных и отправляет уведомления по электронной почте в случае ошибок или если размер резервной копии меньше ожидаемого.
Запуск резервного копирования происходит еженедельно по расписанию (не считая самого первого раза при запуске деплой-скрипта deploy-backup-node.sh), настроенному в systemd timer. Резервное копирование происходит каждое воскресенье в 13:00.

Из чего состоит?

Система резервного копирования состоит из следующих файлов:
+ backup.sh: Bash скрипт, выполняющий резервное копирование с алертингом. После деплоя находится по пути /usr/local/bin/
+ rsync-backup.service: Юнит-файл systemd, который запускает скрипт /usr/local/bin/backup.sh
+ rsync-backup.timer: Таймер systemd, который запускает rsync-backup.service по расписанию.

На чем основан?

Система основана на:
+ rsync: утилита для синхронизации файлов и директорий между двумя узлами. Выбран rsync из-за своей простоты, ибо и в самой схеме резервного копирования в этой инфраструктуре нет ничего сложного - не хотелось городить что-то неоправданно сложное.
+ systemd: менеджер системы и служб, используемый для автоматического запуска резервного копирования по расписанию.
+ curl: утилита используется для отправки уведомлений по электронной почте через SMTP. Так выглядит функция в backup.sh, реализующая это:

Bash

function Curl_Mail_Command {
    local args="${*:-}"
    curl \
      --silent \
      --ssl-reqd \
      --url 'smtps://smtp.gmail.com:465' \
      --user "${ALERT_EMAIL}:${ALERT_EMAIL_PASSWORD}" \
      --mail-from "$ALERT_EMAIL" \
      --mail-rcpt "$ALERT_EMAIL" \
      --upload-file \
      "$args"
}

# Пример вызова функции
Curl_Mail_Command <(echo -e "$msg")

Как использовать артефакты из нее?

Как я понимаю, под "артефактами" в данном контексте подразумеваются результаты резервного копирования (резервные копии) и уведомления. Вот как их использовать:
+ Резервные копии:
+ Резервные копии данных хранятся в директориях ~/backup_dir/CA_node и ~/backup_dir/VPN_node.
+ Для восстановления данных можно использовать тот же rsync для копирования файлов обратно на исходные ноды.
+ Уведомления:
+ Уведомления отправляются на указанный адрес электронной почты (хранится в переменной окружения $ALERT_EMAIL, задаваемой в env-файле cua-infrastructure-setup/scripts/set-env.sh) в случае ошибок или если размер резервной копии меньше ожидаемого.
+ Уведомления содержат информацию о статусе выполнения резервного копирования (exit code/$?), которая будет полезна для мониторинга и устранения проблем.

Пример использования артефактов

Запуск резервного копирования вручную:
Bash
```
sudo systemctl start rsync-backup.service
```
Проверка статуса службы резервного копирования:
Bash
```
sudo systemctl status rsync-backup.service
```
Проверка расписания таймера:
Bash
```
sudo systemctl list-timers --all
```

Восстановление данных из резервной копии:

Bash

# CA node:
rsync --archive --verbose --compress --rsh 'ssh -p 2222' \
  /home/admin/backup_dir/CA_node/easy-rsa \
  admin@10.1.2.3:/home/admin/easy-rsa

# VPN node:
rsync --archive --verbose --compress --rsh 'ssh -p 2222' \
  /home/admin/backup_dir/VPN_node/easy-rsa \
  admin@10.1.2.4:/home/admin/easy-rsa
rsync --archive --verbose --compress --rsh 'ssh -p 2222' \
  /home/admin/backup_dir/VPN_node/OpenVPN-clients \
  admin@10.1.2.4:/home/admin/OpenVPN-clients
# или в одну команду, с помощью --include и --exclude:
rsync --archive --verbose --compress --rsh 'ssh -p 2222' \
  --include 'easy-rsa' \
  --include 'OpenVPN-clients' \
  --exclude '*' \
  /home/admin/backup_dir/VPN_node/ \
  admin@10.1.2.4:/home/admin/

Система мониторинга

Описание системы мониторинга как части инфраструктуры

Система состоит из следующих компонентов:
1. Prometheus:
+ Сбор метрик с нод и сервисов
+ Хранение и обработка метрик
+ Настройка алертов для уведомления о сбоях
2. Alertmanager:
+ Управление алертами, отправленными Prometheus
+ Группировка и отправка уведомлений по электронной почте
3. Экспортеры, размещенные на всех нодах:
+ Сбор метрик о состоянии системы на каждой ноде. Эту задачу выполняют node-exporter-ы, запущенные на всех нодах, включая саму Monitoring ноду
+ Сбор метрик о состоянии сервисов на каждой ноде. Во всей инфраструктуре есть один такой эспортер - openvpn-exporter - который запущен на VPN ноде и хостит метрики OpenVPN сервера.
4. Grafana:
+ Визуализация собранных метрик с Prometheus

Алерты

Алертов всего 10:

InstanceDown:
- Условие: up == 0
- Время: 1 минута
- Уровень: критический
- Описание: Уведомляет, если сервис недоступен более 1 минуты.
CPUIdleLow:
- Условие: avg(irate(node_cpu_seconds_total{mode="idle"}[10m])) * 100 < 10
- Время: 15 секунд
- Уровень: предупреждение
- Описание: Уведомляет, если время простоя CPU падает ниже 10% за последние 10 минут.
HighCPULoad:
- Условие: node_load1 > 1.5
- Время: 30 секунд
- Уровень: предупреждение
- Описание: Уведомляет о высокой загрузке CPU, если средняя нагрузка за 1 минуту превышает 1.5.
SwapinHigh:
- Условие: rate(node_vmstat_pswpin[5m]) / 1024 / 1024 > 1
- Время: 15 секунд
- Уровень: предупреждение
- Описание: Уведомляет, если скорость свопинга превышает 1 МБ/с за последние 2-5 минут.
HighMemoryLoad:
- Условие: (sum(node_memory_MemTotal) - sum(node_memory_MemFree + node_memory_Buffers + node_memory_Cached)) / sum(node_memory_MemTotal) * 100 > 85
- Время: 30 секунд
- Уровень: критический
- Описание: Уведомляет о высокой загрузке памяти, если использование памяти превышает 85%.
IOStatHigh:
- Условие: 100 * (1 - avg_over_time(node_filesystem_avail_bytes[1h]) / avg_over_time(node_filesystem_size_bytes[1h])) > 95
- Время: 15 секунд
- Уровень: критический
- Описание: Уведомляет, если использование диска превышает 95% за последний час.
HighStorageLoad:
- Условие: (node_filesystem_size{fstype="aufs"} - node_filesystem_free{fstype="aufs"}) / node_filesystem_size{fstype="aufs"} * 100 > 85
- Время: 30 секунд
- Уровень: критический
- Описание: Уведомляет о высокой загрузке хранилища, если использование хранилища превышает 85%.
TimeOutOfSync:
- Условие: ntp_drift_seconds > 500
- Время: 5 минут
- Уровень: предупреждение
- Описание: Уведомляет, если время не синхронизировано более чем на 500 миллисекунд за последние 5 минут.
ReceivedTrafficHigh:
- Условие: irate(node_network_receive_bytes_total[5m]) / 1024^2 / 200 * 100 > 75
- Время: 15 секунд
- Уровень: предупреждение
- Описание: Уведомляет, если входящий трафик превышает 75% за последние 15 секунд.
TransmittedTrafficHigh:
- Условие: irate(node_network_transmit_bytes_total[5m]) / 1024^2 / 200 * 100 > 75
- Время: 15 секунд
- Уровень: предупреждение
- Описание: Уведомляет, если исходящий трафик превышает 75% за последние 15 секунд.
OpenVPNServiceDown:
- Условие: openvpn_up == 0
- Время: 1 минута
- Уровень: критический
- Описание: Уведомляет, если сервис OpenVPN недоступен более 1 минуты.

Помощь

Если возникли какие-то проблемы - обращайтесь к администратору/создателю проекта по электронной почте: test@gmail.com

CUA-admin-guide

Описание системы

Компоненты инфраструктуры

Описание компонентов

CA node

VPN node

Backup nodes

Monitoring node

Взаимодействие компонентов

Взаимодействие CA и VPN нод

Взаимодействие Backup нод с CA и VPN нодами

Взаимодействие Monitoring и остальных нод

Создание виртуальных машин. Terraform и Yandex.Cloud

Инструкция по поднятию виртуальных машин в Yandex.Cloud с помощью Terraform

Развертывание серверов

Как устроены деплой-скрипты?

Развертывание компонентов на CA ноде

Что делает скрипт deploy-CA-node.sh ?

Как проверить работу сервисов после деплоя?

Развертывание компонентов на VPN ноде

Что делает скрипт deploy-VPN-node.sh

"Что делает скрипт make-ovpn.sh?" или "Как генерировать клиентские конфиг файлы .ovpn"

Как проверить работу сервисов после деплоя?

Развертывание компонентов на Backup нодах

Что делает скрипт deploy-backup-node.sh

Как проверить работу сервисов после деплоя?

Развертывание компонентов на Monitoring ноде

Что делает скрипт deploy-monitoring-node.sh

Как проверить работу сервисов после деплоя?

Система резервного копирования

Как работает?

Из чего состоит?

На чем основан?

Как использовать артефакты из нее?

Пример использования артефактов

Система мониторинга

Описание системы мониторинга как части инфраструктуры

Алерты

Помощь

Что делает скрипт `deploy-CA-node.sh` ?

Что делает скрипт `deploy-VPN-node.sh`

"Что делает скрипт `make-ovpn.sh`?" или "Как генерировать клиентские конфиг файлы .ovpn"

Что делает скрипт `deploy-backup-node.sh`

Что делает скрипт `deploy-monitoring-node.sh`