Два VPN, один резолвер: перемагає той, хто записав останнім

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

Міф: найновіший VPN володіє DNS

Немає загального правила, що перемагає найостанніше підключення. Що станеться, залежить від механізму платформи й від того, як його записує кожен клієнт. Клієнт, який замінює файл резолвера, дає один результат; клієнт, який додає домен для кожного з'єднання, — інший; клієнт, який нічого не робить, залишає попередній стан недоторканим.

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

Зіставте простори імен із резолверами

Перелічіть приватні суфікси й резолвер, якого потребує кожна мережа, потім вирішіть, куди мають іти публічні імена. Цей список і є дизайном. Без нього клієнти ухвалюють рішення випадково.

Платформа, що підтримує DNS для кожного з'єднання або домени маршрутизації, може виразити поділ навмисно: один домен іде до одного з'єднання, інший — до іншого, а все решта прямує за явним значенням за замовчуванням. Два пласкі скрипти, які перезаписують той самий файл, не можуть зберегти цей дизайн, бо кожен вважає, що володіє всією конфігурацією.

У Windows таблиця політики розв'язання імен може спрямовувати суфікси до певних серверів, і клієнт VPN може встановлювати там правила. Перевіряйте політику, а не список адаптерів, бо ім'я розв'язує не список адаптерів.

Тримайте шлях початкового завантаження

Кожен клієнт має знайти свою кінцеву точку, перш ніж зможе користуватися послугою, яку ця точка надає. Якщо ім'я хоста кінцевої точки розв'язується лише через тунель, а тунелю потрібне розв'язане ім'я хоста, у вас циклічна залежність, що проявляється як тайм-аут з'єднання. Тримайте один шлях початкового завантаження поза обома тунелями. Він нічого не коштує до того дня, коли рятує з'єднання.

Дивіться на шлях до кожного резолвера, а не лише на ім'я, задане для нього. Резолвер, доступний лише через інший тунель, поводиться як відсутній, і симптом — тайм-аут, а не помилка маршрутизації.

Перекривні адреси — не проблема DNS

Дві приватні мережі з однаковим діапазоном адрес не виправити порядком DNS. Якщо обидва тунелі претендують на 10.0.0.0/8, ім'я, що розв'язується правильно, все одно вказує на адресу, до якої хост не може спрямувати правильний тунель. Це потребує рішення на рівні адрес, як-от різні діапазони, простір імен або трансляція, а не ще одне налаштування резолвера. Раннє рішення позбавляє довгого обходу через конфігурацію DNS, яка ніколи не працювала б.

Порівняйте призначення адрес обох тунелів, перш ніж звинувачувати розв'язання імен. Коли обидві сторони просувають однаковий префікс, хост тримає для нього один маршрут, і ім'я, розв'язане через другий тунель, усе одно потрапляє на адресу, якою володіє перший тунель. Різні діапазони, простір імен для кожної мережі або трансляція — це виправлення; після підключення кожного клієнта переконайтеся, що таблиця маршрутів показує потрібний шлях.

Доведіть це реальними застосунками

Виберіть два хости, що існують лише у своєму просторі імен, і одне публічне ім'я, потім розв'яжіть кожен через клієнт, якому він має належати. Правильна відповідь від очікуваного резолвера не доводить, що застосунок досягає хоста, бо маршрут до цієї адреси все ще може не спрацювати. Після кожного запиту виконуйте перевірку з'єднання з програми, яку користувач справді запустить.

Клієнт із власною опцією зашифрованого DNS може обійти щойно перевірену політику, тож перевірте це налаштування в межах огляду. Потім перепідключіть обидва клієнти в порядку, який підтримує постачальник, і повторіть запити; якщо відповіді міняються місцями при зміні порядку, конкуруючий записувач усе ще володіє частиною конфігурації. З'ясуйте, який компонент установлює правило — клієнт, профіль ОС чи агент керування, — перш ніж щось редагувати. Запишіть порядок і власників, щоб наступній людині не довелося відкривати їх заново.