Один служебный IP на каждом узле OpenVPN: чего он не делает

Клиент подключается к одному из нескольких серверов OpenVPN и затем нуждается в небольшом сервисе, который работает на этом узле: страница состояния, точка метрик, агент резервного копирования. Если дать каждому узлу один и тот же частный служебный адрес, конфигурация клиента остаётся одинаковой независимо от того, на какой сервер он попал. Это удобство реально, и его так же легко переоценить: общий адрес говорит, до какого узла вы дошли, а не то, что что-то резервируется.

Почему один и тот же адрес на каждом узле работает

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

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

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

Назначьте его loopback, а не туннелю

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

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

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

ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev lo

Протолкните один маршрут и подразумевайте один пункт назначения

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

Проверьте, что установил клиент, прежде чем винить сервис.

ip route get 10.250.0.1

Для HTTP-сервиса дайте адресу имя и сертификат для этого имени. Общий IP не идентичность, и он не отменяет проверку TLS, а также не оправдывает копирование одного закрытого ключа на каждый узел. Имя, которое разрешается в общий адрес, сохраняет историю сертификата обычной и позволяет сохранить идентичность на узел, если она нужна.

Чего общий адрес не может

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

Он не переносит живую TCP-сессию, потому что новое соединение завершается на другом хосте, который ничего не знает о старом.

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

Держите идентичность сервиса вместе с именем

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

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

Если требование стабильный пункт назначения для локального сервиса узла, шаблон подходит и почти ничего не стоит.

Если требование доступность, поднимитесь на уровень выше: балансировщик нагрузки, имя сервиса с проверками здоровья или система оркестрации, которая уже умеет заменять узел.

Раннее решение сохраняет общий адрес тем, чем он является, удобной меткой, а не компонентом, от которого молча ждут работы, для которой он никогда не проектировался.