Розділений DNS через OpenVPN: що домен маршрутизації має робити в кожній системі
Суфікс пошуку, домен маршрутизації та IP-маршрут — три різні речі. Задайте політику для кожної платформи, а потім доведіть, який сервер відповів на запит.
Кожен запит розділеного DNS починається з одного й того самого речення: назви компанії йдуть до DNS компанії, а все інше продовжує працювати. Перетворити це речення на конфігурацію означає дати три відповіді для кожної операційної системи, і відповіді в кожній з них спираються на різні механізми. Профілі, які працюють на ноутбуці з Linux, часто не працюють на Windows з причин, що не мають нічого спільного з тунелем. Розрив зазвичай — налаштування резолвера, яке помилково вважають маршрутом.
Спершу назвіть політику, а потім виберіть примітив платформи, який її виражає.
Три налаштування, які легко переплутати
Суфікс пошуку розширює коротке ім'я: коли ви вводите files , воно стає files.corp.example , коли резолвер пробує суфікси по черзі. Домен маршрутизації вибирає, який резолвер відповідає на запити в межах простору імен. IP-маршрут лише робить вибраний резолвер доступним. Ці три живуть у різних шарах, і заміна одного на інший дає конфігурацію, яка виглядає правильною і нічого не розв'язує.
Плутанина має ціну: додавання суфікса пошуку надсилає кожне коротке ім'я до робочого резолвера, включно з іменами, що належать іншому місцю. Вибір домену маршрутизації залишає не пов'язані запити на локальному резолвері й далі надсилає *.corp.example через тунель.
Linux: домен лише для маршрутизації, а не суфікс пошуку
У systemd-resolved домен із префіксом тильди — це домен лише для маршрутизації, тобто запити для цього простору імен ідуть до пов'язаного резолвера, не стаючи також суфіксом пошуку. resolvectl domain tun0 '~corp.example' задає це, а resolvectl dns tun0 10.8.0.1 називає сервер. Обидва налаштування належать інтерфейсу, тому зникають разом із ним. Тильда — саме та частина, яку люди пропускають, і без неї короткі імена починають розв'язуватися через робочий резолвер.
Не встановлюйте той самий домен ще й як глобальний суфікс пошуку. Ці два налаштування не є надлишковими; одне маршрутизує, а друге переписує те, що ви ввели.
Windows потребує політики простору імен, а не суфікса
Windows зберігає політику розділеного DNS у таблиці політики розв'язання імен, а не в DNS-суфіксі адаптера. Правило зіставляє простір імен із конкретними серверами: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Саме лише налаштування суфікса змінює вигляд коротких імен; воно не скеровує запит до іншого сервера.
Перевірте чинну політику за допомогою Get-DnsClientNrptPolicy після підключення, бо правило з попереднього з'єднання може пережити тунель. Видаляйте правила за назвою, коли тунель падає, і тримайте відображувану назву стабільною, щоб очищення влучало в потрібний запис.
Тримайте одного власника резолвера на платформу
Менеджер робочого столу, скрипт up від OpenVPN і локальний демон резолвера можуть усі намагатися записати ту саму конфігурацію. Коли вони не згодні, перемагає той, хто записав останнім, і результат залежить від порядку згортання. Виберіть один компонент, який володіє станом резолвера, дозвольте іншим звітувати, а не писати, і перевірте повторне підключення: політика має його пережити без дублювання правил. Перевірте й відключення, бо саме залишковий стан змушує наступне з'єднання поводитися інакше.
Застосунки, що постачають власний зашифрований резолвер, повністю ігнорують політику операційної системи. Це властивість застосунку, а не дефект тунелю.
Перевіряйте результат, а не текст профілю
Розв'яжіть одне ім'я, яке має йти через тунель, і одне, яке не має, на кожній платформі та підтвердьте, який сервер відповів. resolvectl query host.corp.example і Resolve-DnsName host.corp.example обидва повідомляють сервер, що відповів. Повторіть після повторного підключення. Потім підтвердьте, що резолвер тунелю доступний за адресою, яку надсилає профіль, бо правильна політика, спрямована на недоступний сервер, зазнає невдачі так само, як і відсутність політики.
Запишіть бажану поведінку в нотатках профілю: який суфікс маршрутизується, який сервер на нього відповідає і що відбувається з усім іншим. Наступній платформі, яку ви підтримаєте, це речення потрібніше, ніж файл конфігурації.