Имя конечной точки VPN против имени приватного сервиса: два владельца

Два имени могут описывать один и тот же филиал и отвечать на совершенно разные вопросы. vpn.branch.example сообщает удалённому партнёру, где найти конечную точку VPN, и должен разрешаться до появления любого туннеля. inventory.branch.example сообщает авторизованному пользователю, где живёт приватное приложение, и имеет значение только после поднятия туннеля. Поддержка одного ничего не делает для другого.

Назовите обе записи, прежде чем отлаживать любую из них

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

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

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

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

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

Эту зависимость от начальной загрузки стоит назвать прямо, потому что её легко создать случайно, когда все внутренние резолверы находятся за VPN. Сохраняйте путь до туннеля для поиска конечной точки и проверяйте поведение клиента при переподключении, а не предполагайте, что новый ответ подхватывается немедленно.

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

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

Имя сервиса описывает, где живёт приложение

Теперь предположим, что туннель остаётся здоровым, но сервер инвентаризации переезжает с 172.26.14.20 на 172.26.14.35. Публичная запись конечной точки не затрагивается, а приватная запись сервиса должна измениться. Использование адреса, зарезервированного для этого сервиса, или статическое назначение делает это более редким; авторизованный путь обновления обрабатывает случаи, когда это задумано.

Здесь смешиваются два механизма обновления. RFC 2136 определяет протокол добавления и удаления записей DNS в зоне, а коммерческий поставщик динамического DNS может предоставлять совершенно другой HTTP API для другой цели. Использование одного не означает, что другой существует в вашей среде. Проверьте, какой механизм ваша зона действительно принимает, прежде чем писать под него обновлятор.

Правильный приватный ответ — это только первое условие. Чтобы удалённый вызывающий мог им воспользоваться, клиенту нужен резолвер, несущий приватную зону, политика, разрешающая запросы к этому резолверу, и пересылка для адреса, который возвращается. Имя, разрешающееся в адрес, недостижимый для клиента, создаёт тайм-аут, который выглядит как сбой сервера.

Проверьте оба пути по отдельности

Проверьте конечную точку снаружи туннеля, а сервис изнутри, и сохраняйте результаты как два независимых факта:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

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

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