VPN е поврзан, но имињата не се решаваат: каде DNS навистина се крши

Тунелот е кренат, иконата е зелена, а секој јазик во прелистувачот пријавува неуспех при решавање на имиња. Три различни механизми ја создаваат оваа слика: решавачот може да биде недостапен, клиентот може да прашува решавач што не сте го очекувале, или само приватните имиња може да не успеат. Одделете ги пред да промените нешто во протоколот на тунелот, бидејќи секој се поправа на различно место. Редоследот подолу започнува со набљудувањата што ги одделуваат трите.

Што навистина му треба на едно пребарување

На едно пребарување му требаат три работи: адреса на решавач, рута до таа адреса и одговор што се совпаѓа со прашањето. Секоја може да не успее сама, а видливиот симптом е истата страница што не се вчитува. Затоа страницата со грешка не ви кажува речиси ништо додека не знаете која од трите се скрши.

Клиентот го учи својот решавач од VPN профилот, од DHCP на тунелот или од сопствената конфигурација, а кој извор ќе победи зависи од платформата. Во Windows, ipconfig /all ги наведува DNS серверите по адаптер, така што гледате дали испратената вредност навистина пристигнала. Испратена вредност што никогаш не стигнала до оперативниот систем е тивок и чест неуспех. Прочитајте ја конфигурираната вредност пред да го допрете профилот.

Linux и macOS одговараат на истото прашање со различни наредби, а одговорот заслужува исто читање: resolvectl status и scutil --dns двете ги наведуваат серверите по интерфејс. Споредете го тој список со адресата што профилот тврди дека ја испраќа. Несовпаѓање тука го објаснува сето понатаму, затоа средете го пред да тестирате имиња.

Тестирајте едно јавно и едно приватно име

Прашајте обично јавно име на домаќин и документираното приватно име на домаќин од истиот компјутер и запишете кој сервер одговорил на секое. Ако не успеат двете, решавачот или неговата рута се скршени. Ако не успее само приватното име, решавачот одговорил и прашањето станува зоната или рутирањето. Извршете ги двете прашања во рок од една минута едно од друго, за да не може промената на рутата да ја објасни разликата.

Држете ги внатрешните имиња надвор од јавни слики од екран и надвор од јавни решавачи. Истекување на времето и одговор за непостоечка домена се различни набљудувања: првото вели дека ништо не се вратило, второто дека авторитет одговорил оти името не постои. Ако ги третирате како една грешка, одите на погрешниот слој, а предупредувањето за сертификат е повторно трета работа, не неуспех на DNS.

nslookup ги печати и серверот што бил прашан и добиениот одговор, а тоа е токму парот што ви треба. Извршете го двапати во истата обвивка и запишете ја адресата што одговорила покрај секој одговор.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Потврдете дека клиентот навистина стигнува до тој сервер

Приватен решавач што го испраќа профилот е корисен само ако клиентот може да го стигне додека тунелот е кренат. Адреса што изгледа исправно без рута предизвикува истекување на времето, а поврзаната состојба на тунелот не кажува ништо за таа рута. Проверката е пребарување на рута насочено кон самиот решавач, не кон крајната точка на VPN.

Секоја платформа одговара на тоа со еден ред, а интерфејсот наведен во излезот е целиот одговор. Ако тој покажува на физичкиот адаптер додека решавачот стои зад тунелот, профилот не испраќа префикс што ќе го покрие.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

Кај профил со поделен тунел решавачот може да стои надвор од испратените рути, што е проблем на профилот, а не на серверот. Споредете ја адресата на решавачот со испратените префикси и потврдете дека еден од нив го покрива. Истото несовпаѓање објаснува зошто DNS работи во една мрежа, а не успева во друга со идентичен профил.

Запомнете дека прелистувачите можат да го заобиколат системскиот решавач

Прелистувач со вклучен безбеден DNS може да праќа прашања преку HTTPS до добавувач по свој избор и целосно да го игнорира решавачот на оперативниот систем. Тогаш системот изгледа исправно додека прелистувачот не успева, или обратно. Тоа е прашање на политика за прелистувачот, не за тунелот.

Проверете го поставувањето за безбеден DNS во прелистувачот и секоја управувана политика што го контролира, потоа пробајте втора апликација или прелистувач со непроменет тунел. Ако не успее само една апликација, поправката и припаѓа на таа апликација. Приватен прозорец не е чиста споредба, бидејќи може стандардно да ги исклучи екстензиите во еден прелистувач, а во друг не, и никогаш не заобиколува управувана политика. Наместо тоа користете втор профил на прелистувач или друга апликација.

Исчистете го кешот и повторно тестирајте ја вистинската задача

Откако ќе поправите поставување, исчистете го локалниот кеш на решавачот за стариот одговор да не ја надживее поправката. Кратко закрепнување по кое следи нов неуспех значи дека причината сѐ уште е таму, а не дека чистењето не успеало. Изберете го редот што одговара на машината на која сте, бидејќи трите кеша се одделни.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Потоа повторете ја првобитната задача наместо синтетичко пребарување, бидејќи задачата е она што му е важно на корисникот. Поврзете се повторно еднаш, за повторното тестирање да ја покрие состојбата во која корисникот навистина ќе биде. Microsoft референцата за nslookup е страницата што вреди да се чува за аргументите на пребарувањето.

Ако имињата не успеваат само по исклучување, клиентот не ја врати претходната конфигурација, што е грешка во животниот циклус за пријавување, а не DNS сервер за замена. Работечкото пребарување исто така не е тест за истекување, бидејќи излезната земја не ви кажува кој решавач одговорил.