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

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

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