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 и средата за скриптове; използвайте го, за да потвърдите какво се очаква да приложи клиентът ви, преди да редактирате поредния файл на резолвера.