VPN переехал: почему ваш клиент OpenVPN по-прежнему звонит на старый IP

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

Смотрите, куда звонит профиль, а не что говорит DNS

Откройте соединение, которое вы действительно используете, и прочитайте строку remote. Числовой адрес там никогда не следует за обновлением имени хоста, каким бы правильным ни стала запись.

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

Два файла, одна конечная точка — вот типичная находка здесь.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Прочитайте следующую попытку подключения клиента

Перезапустите соединение с подробным журналированием и прочитайте строку, где назван адрес, к которому он обратится. Именно это значение важно, а не то, что разрешил ваш браузер.

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

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

Знайте, какой перезапуск вы делаете

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

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

Самая чистая проверка — новый запуск из нужного профиля, а затем взгляд на строку журнала, где названа конечная точка. Всё, что вы узнаете из частично сохранённой сессии, — это утверждение об этой сессии.

Четыре параметра и их отдельные задачи

remote с именем хоста — это параметр, который вообще делает возможным повторное разрешение; буквальный адрес в этой строке исключает его. resolv-retry управляет тем, что происходит при неудачном поиске, и 2.6 уже по умолчанию делает его бесконечным. Поэтому его добавление ничего не меняет, и он никогда не планирует периодическую проверку другого ответа. Кто говорит, что он опрашивает новые адреса, тот путает восстановление со свежестью.

persist-remote-ip — про непрерывность, а не про свежесть: он повторно использует конечную точку, которая последней прошла аутентификацию, через поддерживаемые мягкие перезапуски. Пока вы тестируете переезд, это противоположность тому, что вам нужно. Отключите его для теста, если ваша сборка его включает, а затем восстановите, когда новая конечная точка доказана. Если оставить включённым, успешное переподключение может ничего не сказать вам о DNS.

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

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

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

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

Держите внеполосный путь на сервер, прежде чем перезапускать туннель, по которому идёт ваш административный доступ. Одна эта мера предосторожности предотвращает большинство инцидентов, которые порождает этот сценарий.