OpenVPN передає DNS, але ваш резолвер може його так і не побачити

Журнал клієнта показує переданий DNS-сервер, тунель підключено, а внутрішнє ім’я все одно не розв’язується. У самій передачі нічого не зламано. Параметр надійшов, але резолвер операційної системи так і не використав його, бо на більшості Unix-клієнтів OpenVPN передає значення й залишає застосування платформі.

Симптом: журнал показує DNS, а імена все ще не працюють

OpenVPN dhcp-option несе інформацію про DNS і домен, а клієнт записує те, що отримав. У деяких реалізаціях клієнт застосовує ці налаштування всередині; в інших експортує їх для скрипту інтеграції або мережевої служби. Рядок журналу описує лише першу половину історії. Друга половина відбувається там, де клієнт не керує. Саме там зазвичай живе збій.

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

Отримано — не означає застосовано

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

Перевірте підтримувану інтеграцію реалізації, а не припускайте, що кожен Unix-клієнт переписує той самий файл. Саме це припущення змушує людей редагувати конфігурацію резолвера, яку ніщо не читає.

Знайдіть власника резолвера для кожної платформи

У Windows таблиця політики розв’язання імен може спрямовувати певні суфікси на певні сервери, і VPN-клієнт може встановлювати там правила. Перевіряйте політику, а не лише список DNS адаптера. У Linux конфігурацією може володіти NetworkManager або systemd-resolved, і те, хто з них володіє нею, визначає, що збереже повторне підключення.

Читайте фактичний стан інструментом, який справді відповідає на запити: resolvectl query internal.example.net на хості з systemd-resolved або еквівалентом платформи. Потім порівняйте цю відповідь із DNS-сервером, який, за словами журналу клієнта, було передано.

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

Скрипти та foreign_option

OpenVPN експортує передані параметри у скрипти через змінні з іменем foreign_option_N, і скрипт може перетворити їх на команди резолвера. Така схема — підтримувана інтеграція, а не автоматична поведінка, і її треба встановити та викликати на клієнті.

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

Перевіряйте ім’я, а не журнал

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

Якщо ім’я розв’язується, але служба не працює, переходьте до маршрутизації та доступу застосунків, а не змінюйте DNS знову. Посібник OpenVPN описує dhcp-option і середовище скриптів; використайте його, щоб підтвердити, що має застосовувати ваш клієнт, перш ніж редагувати черговий файл резолвера.