Промени ли VPN моя DNS? Сравнете преди и след

Свързвате тунела, отваряте частен панел и името се разрешава до адрес, който никога не сте виждали. Или се случва обратното: браузърът продължава да работи, докато инструмент от командния ред изведнъж не разрешава нищо. И двата резултата идват от една и съща промяна и хората обикновено я обясняват с едно изречение за VPN, който „използва свой DNS“, а това не е достатъчно точно, за да се отстрани проблемът или да се провери. В това изречение се крият два въпроса: кои заявки трябва да поеме този профил и дали машината ви наистина ги е изпратила до резолвера, който ѝ е бил даден? Разделянето им е целият метод, защото тест, който ги смесва, дава уверен грешен отговор и в двете посоки.

Защо профилът изобщо предоставя резолвер

Вътре в тунела имената зад далекия край обикновено се разрешават до адреси, които съществуват само в тази мрежа. Частна зона като corp.internal няма публично делегиране, затова резолверът, който отговаря за нея, трябва да е достъпен отвътре в тунела. Същият механизъм служи и на втора цел: когато заявките иначе биха излезли през вашия доставчик, резолверът от далечната страна задържа заявката в шифрования път. Ето защо адресът на DNS сървъра идва като част от политиката на връзката, а не като глобална настройка, избрана веднъж за машината.

Адресът сам по себе си не решава нищо. Резолверът може да отговори само ако има маршрут до него, а най-честата повреда е резолвер, достъпен само докато тунелът е активен. Когато тунелът падне, а политиката остане, заявките отиват към адрес без път и симптомът е изтичане на времето, а не чиста грешка. Тази разлика е важна, когато четете следващия резултат от теста, защото изтичането на времето насочва хората към транспортни настройки, които никога не са участвали.

Сравнете двата дизайна, преди да сравнявате отговори

Пълният тунел и разделеният DNS водят до противоположни очаквания и нито едно от двете не е повреда. При пълен тунел всяка заявка може да се премести към доставчика или към корпоративния резолвер, така че различен отговор на публични имена след свързване е очакван. При разделен DNS само изброените домейни отиват към частния резолвер, а всичко останало остава локално; в Windows списъкът с домейни живее в таблицата с правила за разрешаване на имена, в macOS — в съответстващите домейни на DNS настройките, а на хост със systemd-resolved — в маршрутизиращите домейни за всяка връзка.

Това е сравнението, което трябва да се направи първо, защото то решава какво се брои за дефект. При разделен DNS публичното име, което отговаря от нов резолвер, е нещото, което си струва да се разследва, докато вътрешното име, което отговаря правилно, е системата, която си върши работата. При пълен тунел аномалията е публично име, което все още отговаря от резолвера на доставчика ви. Документацията на Microsoft за разрешаване на имена при VPN описва реда на тези правила в Windows, включително как съвпадащ запис в политиката се проверява преди собствените сървъри на адаптера.

В стаята има трети резолвер, за който лесно се забравя. Защитеният DNS на браузъра разрешава имена сам и може да продължи да отговаря, след като тунелът е сменил политиката на операционната система, така че зареждаща се страница доказва, че резолверът на браузъра е работил, а не че профилът е приложен. Ако сравнявате само това, което показва браузърът, в половината случаи проверявате грешния слой.

Запишете базова линия само с една променлива

Сменете тунела. Не сменяйте също името, инструмента или суфикса за търсене в същата стъпка. Изберете име, за което имате право да правите заявки, отбележете кое приложение сте използвали и запишете или адреса, който се върна, или точната грешка. В Windows Get-DnsClientServerAddress -AddressFamily IPv4 отпечатва сървърите за всеки адаптер, а Get-DnsClientNrptPolicy отпечатва записите в политиката; в Linux със systemd-resolved resolvectl status показва DNS сървърите и маршрутизиращите домейни за всяка връзка; в macOS scutil --dns отпечатва реда на резолверите, който системата действително ще следва.

След това се свържете чрез обичайните контроли на клиента и повторете точно същите команди. Запазете първия изход, а не спомен за него, защото цялата работа е в сравнението, а второ четене, направено след изчистване на кеша, вече е друго измерване. Ако базовата линия е снета с браузъра отпред, а пускането след свързване става в терминал, сравнявате два резолвера, а не две състояния на един резолвер.

Явна заявка и търсене от приложение са различни тестове

Заявка към един конкретен сървър, чрез nslookup name 10.20.0.1 или dig @10.20.0.1 name, доказва едно нещо: че сървърът, който сте посочили, отговаря, когато до него има достъп. Тя напълно заобикаля логиката за избор, така че не може да ви каже дали системата би избрала този сървър за това име. Използвайте я, за да проверите дали зададеният резолвер е достъпен, и не я използвайте, за да проверявате политика.

Търсене през локалния резолвер наистина упражнява избор. resolvectl query name минава по същите правила за маршрутизиращи домейни и съобщава кой протокол е отговорил, Resolve-DnsName в Windows минава през таблицата с политики и клиентския кеш, а scutil --dns показва реда, който едно търсене би следвало. Пуснете и двата вида и ги дръжте в отделни колони на бележките си. Успешна явна заявка до провалящо се търсене от приложение е проблем с маршрутизирането или избора, а не резолвер, който отказва да работи.

Кеширането стои между вас и отговора. Операционната система, локалният заглушаващ резолвер, браузърът и отрицателното кеширане всички пазят резултати, така че едно търсене може да успее, без нито един пакет да напусне машината. Запишете резултата, преди да изчистите каквото и да е: ipconfig /flushdns, resolvectl flush-caches или sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder в macOS. Пропуснете широкото нулиране на мрежата на този етап, защото то унищожава доказателствата, които още събирате.

Какво означава разликата

Сравнете двата реда, които записахте, и класифицирайте промяната, преди да докоснете дори една настройка.

Един ред заслужава ударение. Име, което се разрешава, не е услуга, която работи, а успехът на DNS казва само, че е намерен адрес. Той не казва нищо за препращане, правила на защитната стена или дали акаунтът ви изобщо има право да ползва услугата, затова завършете с изпитване на самото приложение, вместо да предполагате, че повредата се е оттеглила сама.

Възстановете базовата линия и я проверете

Прекъснете връзката чрез собствените контроли на клиента, вместо да убивате процеса, после прочетете отново същите три команди. Сървърите за всяка връзка, записите в политиката и отговорът за тестовото ви име трябва да се върнат към базовата линия, която записахте по-рано. Останал запис в политиката след чисто прекъсване е истински дефект, който си струва да се запише, и точно затова ръчните промени в генериран файл на резолвер са лош навик: файлът се пренаписва и промяната изчезва, или промяната оцелява и заковава резолвер, който вече няма маршрут.

Минете този списък веднъж, по ред. Решете кой дизайн прилага профилът, преди да съдите който и да е резултат. Дръжте името, инструмента и суфикса фиксирани в двете пускания. Отделете явната заявка от търсенето на приложението. Четете ефективната политика, а не само отговора. Изчистете кешовете последни, след като сравнението е записано. Проверете с истинското приложение, след което рестартирайте веднъж и потвърдете, че състоянието при прекъсване все още е чисто.