Географічний 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

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