Одна учётная запись VPN на двух серверах: три реестра состояния

Одна учётная запись, которая может войти на любой из двух узлов VPN, ставит проектный вопрос задолго до вопроса о программном обеспечении. Представление записи, сеть, которой владеет каждый узел, и сеанс, который держит подключённый клиент, — это три разных вида состояния, и они отказывают по-разному, когда вы копируете их с места на место. Копирование всех трёх в одну систему — распространённый способ потерять одну из них.

Пройдите три реестра ниже по порядку. Каждый спрашивает, что является авторитетным, что локальным и что происходит, когда второго узла нет, и ответы не вытекают один из другого.

Кто может подключаться: одна авторитетная сторона, много узлов

Начните с реестра допуска: какой источник идентичности авторитетен, каким издателям сертификатов доверяют, какие записи допустимы, какой второй фактор применяется и чего может достичь каждая запись. Затем запишите, как каждый узел узнаёт об изменениях и как быстро.

Общая база данных — один из возможных компонентов этого ответа. Она не доказывает, что вся соответствующая политика живёт там или что каждый узел применяет изменение в один и тот же момент. Запись, отключённая на узле A, но всё ещё принимаемая на узле B, означает, что процесс вывода не завершён.

Решите, что делает узел, когда авторитетная сторона недоступна. Принимать кэшированные учётные данные во время сбоя — это выбор политики с ценой для безопасности, а отклонять их — выбор политики с ценой для доступности. Любой из них можно защитить; оставить это неописанным — нельзя.

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

Чем владеет узел: адреса и маршруты

Второй реестр локален для каждого узла: адрес прослушивания, идентичность сервера, пул адресов, маршруты к частным ресурсам, политика резолвера и то, как трафик уходит в интернет. Одна и та же запись может обслуживаться любым из двух узлов, пока эти объекты остаются разными.

Обратный путь — это часть, которую забывают. Если оба узла выдают адреса из одного пула, частная сеть не может сказать, какому узлу принадлежит данный клиент, и ответ может уйти не туда. Разным пулам тоже нужны маршруты и разрешения, поэтому отдельный диапазон номеров — не полный проект.

Направляйте клиентов на узел осознанно. Выбор DNS, списки конечных точек клиента и фронтенд-сервис — разные механизмы с разным поведением при проверке здоровья и переключении при отказе. Выбрать один — нормально; считать «балансировку нагрузки» проектом — значит оставить обратный путь и поведение при отказе неопределёнными.

Документированный пример продукта здесь помогает. Документация Pritunl по репликации рассматривает сеть VPN как объект на каждую реплику, и клиентам на разных репликах нужны дополнительные маршруты и связность, чтобы достичь друг друга. Это специфичное для продукта устройство, а не рецепт для Community OpenVPN, но оно показывает, почему добавление реплики меняет сеть, а не только хранилище записей.

Что такое сеанс: живое состояние, а не строка

Третий реестр — живой сеанс. У подключённого клиента есть состояние протокола и сетевое назначение на узле, который его принял. Знание записи на другом узле не даёт этому узлу сеанс, ключи или возможность продолжать пакеты.

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

Правила ёмкости требуют такого же подхода. Ограничение в два одновременных сеанса на запись можно обеспечить между узлами только тогда, когда у какой-либо авторитетной стороны есть согласованное представление о занятых местах. Локальные для узлов списки и историческая запись не складываются в такое представление.

Проверка трёх реестров

Проверьте каждый отдельно. Войдите через узел A, затем через узел B и убедитесь, что оба успешны с ожидаемыми диапазонами адресов. Отзовите идентичность и проверьте оба узла, а не только тот, который вы случайно тестировали. Затем остановите один узел и посмотрите, что на самом деле делают клиент и частное приложение.

Включите обратный путь в приёмочный тест. Клиент, который подключается к B, но не может получать ответы от ресурса за A, прошёл проверку допуска и провалил сетевую, и это различие должно появиться в отчёте.

Проект записи для нескольких узлов завершён только тогда, когда у всех трёх реестров есть явный владелец, путь изменения и поведение при отказе. Копирование файла конфигурации между узлами не отвечает ни на один из этих вопросов.