Чому приватні DNS-імена не працюють на клієнтах VPN і де це перевірити

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

Перш ніж редагувати будь-який профіль, перевірте, що клієнт робить з іменем. У Linux resolvectl query files.corp.example показує, через яке з'єднання і який резолвер отримано відповідь. У Windows Resolve-DnsName files.corp.example показує сервер, який відповів, і адресу, яку він повернув.

Прочитайте відповідь, перш ніж щось змінювати

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

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

Роздайте резолвер зсередини тунелю

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

OpenVPN у першій групі. На сервері push "dhcp-option DNS 10.8.0.53" і push "dhcp-option DOMAIN corp.example" ідуть каналом керування, але лише якщо в конфігурації клієнта pull ще ввімкнено. Клієнт, відредагований вручну і з pull-filter ignore "dhcp-option", ніколи їх не побачить, і цей єдиний рядок пояснює напрочуд багато випадків на кшталт «сервер це проштовхує, але мій ноутбук не згоден».

WireGuard у другій групі, бо протокол узагалі не має узгодження параметрів. Резолвер і домен пошуку потрапляють у власний блок [Interface] клієнта як DNS = 10.8.0.53, corp.example. wg-quick застосовує це через resolvconf або systemd-resolved, а у Windows офіційний клієнт ставить правила NRPT, які існують лише поки тунель піднято: Get-DnsClientNrptPolicy перелічує їх, що робить це швидким способом побачити, чи клієнт колись застосував ваш файл.

IPsec/IKEv2 посередині. Плагін attr від strongSwan може повернути DNS-сервер, узятий із пулу, і клієнт Windows зазвичай його приймає, але профіль, який закріплює власний сервер імен, перемагає все, що запропонує шлюз. На клієнті Linux еквівалентний ручний крок — resolvectl dns wg0 10.8.0.53, далі resolvectl domain wg0 '~corp.example'; обидва зникають разом з інтерфейсом, що саме те, що потрібно для налаштування, прив'язаного до тунелю.

Обмежте суфікс, а не ковтайте кожен запит

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

Надсилайте всередину лише приватний суфікс. У systemd-resolved домен, що починається з ~, призначений лише для маршрутизації, тому ~corp.example означає, що запити під цим суфіксом ідуть на сервери того з'єднання, а все інше далі використовує фізичну мережу. Windows робить те саме з правилами NRPT, обмеженими простором імен, а macOS — з додатковим файлом резолвера в /etc/resolver/.

Мультикаст-імена заслуговують на власну відповідь. Імена .local за задумом link-local (RFC 6762), і інтерфейс tun точка-до-точки не несе цю мультикаст-групу, тому додавання публічного резолвера їх не опублікує, а запит до внутрішнього unicast-резолвера повертає NXDOMAIN. Відбивач на кшталт avahi в режимі відбиття може з'єднати два сегменти, але це рішення на боці сервера, якого жоден клієнт не може зажадати. Якщо принтер або NAS має бути доступним за іменем, дайте йому запис A у своїй зоні.

Доведіть, що відповідь може повернутися

Правильна відповідь, що вказує на недосяжну адресу, виглядає точно як проблема резолвера, доки ви не перевірите маршрут. Запитайте ядро, куди піде відповідь: ip route get 10.20.5.20 називає інтерфейс і, корисніше, вихідну адресу, яку він використає.

Стежте за самою адресою резолвера. Клієнт з DNS = 10.8.0.53 поруч із AllowedIPs = 10.20.0.0/16 надсилає запити через фізичну NIC, де вони тихо вмирають, бо резолвер не лежить у жодному префіксі, який вимагає тунель. Ця розбіжність — найчастіша однопричинна відмова в усій цій царині, і вона залишається невидимою, доки ви не порівняєте налаштування DNS із дозволеними префіксами рядок за рядком.

Перекривні діапазони спричиняють зворотну відмову. Відповідь правильна, маршрут існує, і він вказує на неправильний хост, бо 192.168.0.0/24 удома конкретніший за маршрут тунелю в той самий діапазон. Перенумеруйте один бік або проштовхніть вужчий маршрут, потім підтвердьте брандмауер і зворотний шлях хоста служби; нотатки strongSwan про переспрямування охоплюють бік sysctl цього шляху.

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

Перевірте ще раз з клієнта, а не зі шлюзу

Перевіряйте всередині застосунку, на який скаржиться користувач, бо пошук із командного рядка не доводить, що браузер іде тим самим шляхом. Безпечний DNS Chrome і network.trr.mode у Firefox можуть повністю обійти системний резолвер, і коли вони це роблять, приватне ім'я або зазнає невдачі, або витікає до публічного резолвера. Порівняння resolvectl query із запущеним вручну dig @10.8.0.53 files.corp.example скаже, який із двох випадків стався.

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

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