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 и скриптното опкружување; користете го за да потврдите што се очекува вашиот клиент да примени пред да уредите уште една датотека на резолверот.