Географический DNS и anycast: проверка входной точки VPN

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

Проверьте, чьё местоположение на самом деле сообщает резолвер

Авторитетный сервер, отвечающий на запрос, чувствительный к топологии, обычно видит адрес рекурсивного резолвера, который спросил, а не адрес человека, набравшего имя. Централизованный резолвер может находиться далеко от клиентов, которым он служит, и ответ отражает резолвер, а не их. Это не дефект; так протокол ведёт себя, если не передана дополнительная информация. Спецификация EDNS Client Subnet описывает и ограничение, и необязательное средство исправления.

EDNS Client Subnet может передавать сведения о сети происхождения, если каждый участник поддерживает и включает его. Он необязателен, имеет последствия для приватности и кеширования и не даёт права предполагать, что какой-либо публичный резолвер сообщает точное местоположение пользователя. Спросите операторов резолвера, прежде чем проектировать с опорой на него.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

Проверьте, что решила маршрутизация anycast

При anycast несколько локаций объявляют доступность одного адреса сервиса, и сеть доставляет каждого клиента тому узлу, который предпочитает его маршрутизация. Этот выбор делают BGP и окружающая политика, а не расстояние на карте. Топологическая близость также обычно не означает лучшую производительность туда и обратно, потому что короткий на вид путь может быть перегружен или асимметричен. Полученный адрес ничего не говорит о том, какой узел ответил.

Подтвердите обслуживающую локацию со стороны сервиса или из ответа, где она названа, а не только из ответа DNS. traceroute -n 198.51.100.20 показывает пройденный путь и по-прежнему не называет хост в его конце, поэтому читайте его как путь, а не как ответ.

Проверьте, что сессия переживает смену узла

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

Наблюдайте сдвиг, а не предполагайте его. sudo tcpdump -ni any -c 20 esp показывает внешние пакеты по мере изменения пути, и внезапное изменение адреса партнёра — это и есть происходящий сдвиг. Явно определите предполагаемое поведение для реализации, которую вы запускаете, а затем проверьте его, принудительно изменив путь. Если проект предполагает репликацию сессии, назовите механизм и назовите отказ, который он не покрывает.

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

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

Проверьте это с клиента, который попал на необычный узел, потому что именно в этом случае сертификат для узла становится видимым. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com печатает цепочку и имена, то есть ровно то, что сравнивает клиент. Затем решите, сужать ли профиль или менять модель сертификатов.

Проверяйте запись, а не только первый ответ

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

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

Запускайте сценарии из репрезентативных сетей доступа, а не только из офиса, потому что весь вопрос в том, до какой точки входа разные клиенты действительно доходят. Одна сеть — это выборка из одной.