Устаревшая запись DDNS или сломанная конечная точка VPN: как их различить

Снаружи устаревшее имя хоста и сломанный VPN выглядят одинаково. Клиент разрешает имя, имя указывает куда-то, а соединение либо завершается по тайм-ауту, либо отклоняется. Одно — проблема обновления DNS, другое — проблема аутентификации или пересылки, и разница становится очевидной только тогда, когда вы сравните опубликованный адрес с адресом, который ваша линия действительно имеет.

Две неисправности, которые выглядят одинаково

Первая неисправность в том, что запись всё ещё содержит вчерашний адрес WAN. Вторая — в том, что запись верна, а туннель отвергает вас по своим причинам. Обе дают одно и то же сообщение на клиенте, и возникает соблазн начать перегенерировать сертификаты.

Здесь важен порядок. Проверка DNS занимает минуту и обратима. Перегенерация CA не является ни тем, ни другим.

Сначала сравните адреса

Спросите у владельца сети, какой адрес сейчас у линии, затем спросите у DNS, что он публикует. dig +short vpn.example.com даёт ответ, который получит ваш клиент, а dig @1.1.1.1 vpn.example.com показывает, видит ли другой резолвер что-то иное. Если эти два не совпадают, вы смотрите на поведение кэша, а не на сломанный обновитель.

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

Что на самом деле представляет собой учётные данные обновителя

Старые устройства DDNS часто аутентифицируются самим паролем учётной записи, поэтому смена этого пароля молча ломает их. Они продолжают пытаться со старым значением и ничего полезного не сообщают. Руководство No-IP по паролю устройства документирует именно эту проблему совместимости на старом оборудовании, и разумный ответ — ограниченные по области действия учётные данные обновления, а не более слабый пароль учётной записи.

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

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

Чего не может сделать исправление DNS

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

И наоборот, смена пароля VPN не является исправлением устаревшего DNS. Она лишь добавляет вторую неисправность в тот же тикет.

Переподключитесь и докажите это от начала до конца

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

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