DNS Балансировка
Предыдущая часть закончилась неудачной балансировкой, которая не решает практически никаких проблем. В комментариях кто‑то спросил, почему я не использовал балансировку на уровне DNS. Так вот, я ее использовал. Оказалось, что c помощью DNS записей можно организовать балансировку Round Robin. Для этого в конфигурации Wireguard всего лишь нужно использовать доменное имя вместо IP адреса. Теперь конфигурация Wireguard будет выглядеть вот так:
[Interface]
PrivateKey = <client_private_key>
Address = <cient_address_on_server>/32
DNS = 8.8.8.8, 1.1.1.1
[Peer]
PublicKey = <server_private_key>
AllowedIPs = 0.0.0.0/0
Endpoint = domainName.com:<server_port>Схема запросов будет выглядеть примерно так:
Плюсы и минусы DNS балансировки
Данную балансировку я использовал довольно длительное время.
Плюсы:
Нет необходимости иметь свой собственный сервер для балансировки, соответственно, не нужно платить за дополнительный трафик и дополнительные серверы.
Для добавления/удаления новых серверов достаточно добавить/удалить A запись у совего DNS провайдера.
Минусы:
При добавлении нового сервера может быть большой временной лаг, так как нужно некоторое время, прежде чем DNS серверы подтянут к себе обновленную информацию.
При удалении сервера необходимо сначала удалить DNS запись и только через некоторое время можно потушить сервер, так как не все DNS серверы успеют убрать запись о старом IP адресе.
Если у нас падает какой‑то из серверов, DNS запись не обновится автоматически, и некоторая часть пользователей будет пытаться подсоединиться к серверу, который не работает
Балансировка не происходит оптимальным образом, так как используется алгоритм Round Robin.
Про получение пользователем конфигурации
Таблица actions:
id | int64 (уникальный идентификатор каждой записи) |
action | ENUM (1 - подключить пользователя; 2 - отключить пользователя) |
user_id | uuid (уникальный идентификатор пользователя) |
timestamp | timestamptz (время создания записи) |
Таблица users:
id | uuid (уникальный идентификатор пользователя) |
chat_id | int64 (уникальный id пользователя в Telegram) |
public_key | text (публичный ключ Wireguard) |
private_key | text (приватный ключ Wireguard) |
wireguard_ip | text (уникальный ip адрес каждого пользователя внутри интерфейса Wireguard) |
subcription_end | timestamptz (время, когда у пользователя кончится подписка) |
Как я уже говорил в прошлой части, у меня есть Master и Slave хосты:
Master включает в себя:
TelegramBot — отвечает за взаимодействие с пользователем. Следит за состоянием подписки, принимает платежи от пользователей, регистрирует новых пользователей, возвращает пользователю конфигурацию для подключения к VPN.
SlavePingWorker — отвечает за проверку исправности серверов. Каждые несколько минут он пингует все slave. Если slave не отвечает, то отправляется ALERT.
PostgresDB — хранит данные пользователей и таблицу actions.
Server — отдает slave хостам записи из таблицы actions.
Slave включает в себя:
SlaveWorker — отправляет запрос в master для получение свежих записей из таблицы actions.
Рассмотрим шаги на рис. 2
Пользователь делает запрос в TelegramBot для получения конфигурации.
TelegramBot получает chat_id пользователя. Далее он генерирует public_key, private_key, wireguard_ip и добавляет все эти данные в таблицу users. Также TelegramBot делает следующую запись в таблице actions:
id | action | user_id | timestamp |
1 | 1 (подключить пользователя) | <user_uuid> | <Текущее время> |
Создается конфигурация пользователя и возвращется пользователю в виде .conf файла.
Slave1Worker и Slave2Worker каждые 5 секунд делают запрос в Master на получение свежих записей из таблицы actions. Если action = 1, то ключи пользователя добавляются в Wireguard, если action = 2, то ключи пользователя удаляются.
Безопасность
Так как master и slave хосты отправляют запросы по IP адресу (неудобно использовать доменные имена, так как по доменному имени у нас реализована балансировка), нету возможности использовать SSL. Из‑за этого возникает 2 уязвимости связанные с Man‑in‑the‑middle attack.
Передаваемые между master и slave данные возможно прочесть (злоумышленник может украсть ключи пользователя и использовать VPN вместо него).
Запросы между master и slave можно перехватить и потом отправить повторно. Так как API master и slave не является идемпотентным, то возможно изменить внутреннее состояние системы и вызвать ошибки.
Было приниято решение все запросы шифровать с помощью RSA ключа. Для этого создаются пары приватный/публичный ключ. Выглядит это так:
Запрос кодируется с помощью master_private_key
Запрос уходит во внешнюю сеть
Запрос приходит в slave хост
Запрос декодируется с помощью master_public_key
Формируется ответ
Ответ кодируется с помощью slave_private_key
Ответ уходит во внешнюю сеть
Master получает ответ
Ответ декодируется с помощью slave_public_key и обрабатывается в responseHandler
Шифрование запросов между серверами делает невозможным прочесть передаваемые данные. Для того чтобы защититься от повторного отправления запроса, было решено добавлять в запрос timestamp. В таком случае, при получении запроса можно проверять, когда был подписан запрос, и, если подпись старая, то отклонять такие запросы. Я решил использовать дедлайн для подписи в 5 секунд. Этого оказалось достаточным для того, чтобы запросы успевали доходить до адресата.
Далее будет еще одна статья, в которой я расскажу подробнее про организацию кода в своем проекте, github actions, про делегацию балансировки клиентам и про то, какие есть планы на будущее.
