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 сървър, който да смените. Работещата заявка също не е тест за изтичане, защото държавата на изхода не ви казва кой резолвер е отговорил.