Дали VPN-от го смени мојот DNS? Споредете пред и потоа

Ќе се поврзете на тунелот, ќе отворите приватен панел, и името се решава на адреса што никогаш не сте ја виделе. Или се случува обратното: прелистувачот продолжува да работи, додека алатката за командна линија одеднаш не решава ништо. Двата резултати доаѓаат од истата промена, и луѓето обично го објаснуваат со една реченица за VPN-от што „го користи својот DNS“, што не е доволно прецизно за отстранување на грешки или за проверка. Во таа реченица се кријат две прашања: кои барања треба да ги преземе овој профил, и дали вашата машина навистина ги испратила до резолверот што ѝ бил даден? Нивното одвојување е целиот метод, бидејќи тестот што ги меша дава сигурен погрешен одговор во двете насоки.

Зошто профилот воопшто обезбедува резолвер

Внатре во тунел, имињата зад далечниот крај обично се решаваат на адреси што постојат само во таа мрежа. Приватна зона како corp.internal нема јавно делегирање, па резолверот што ја опслужува мора да биде достапен од внатрешноста на тунелот. Истиот механизам служи и за втора цел: кога барањата инаку би излегле преку вашиот давател, резолверот на далечната страна го задржува барањето внатре во шифрираната патека. Затоа адресата на DNS серверот доаѓа како дел од политиката на врската, а не како глобална поставка што еднаш сте ја избрале за машината.

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

Споредете ги двата дизајни пред да ги споредите одговорите

Целосниот тунел и поделениот DNS создаваат спротивни очекувања, и ниту еден не е дефект. Под целосен тунел секое барање може да премине кај давателот или кај корпоративниот резолвер, па различен одговор на јавните имиња по поврзувањето е очекуван. Под поделен DNS само наведените домени одат кај приватниот резолвер, додека сето друго останува локално; во Windows списокот на домени живее во Name Resolution Policy Table, во 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 го покажува редоследот што едно пребарување би го следело. Извршете ги двата вида и држете ги во одделни колони од вашите белешки. Успешно експлицитно барање до неуспешно пребарување од апликација е проблем со рутирање или избор, а не резолвер што одбива да работи.

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

Што значи разликата

Споредете ги двата запишани реда и класифицирајте ја промената пред да допрете и една поставка.

Еден ред заслужува акцент. Името што се решава не е услуга што работи, а успехот на DNS кажува само дека е најдена адреса. Не кажува ништо за проследување, правила на огнениот ѕид или дали вашата сметка воопшто смее да ја користи услугата, па завршете со тестирање на вистинската апликација наместо да претпоставите дека дефектот сам се повлекол.

Вратете ја основната линија и проверете ја

Исклучете се преку сопствените контроли на клиентот наместо да го убиете процесот, потоа прочитајте ги повторно истите три команди. Серверите по врска, записите од политиката и одговорот за вашето тест-име треба да се вратат на основната линија што претходно сте ја запишале. Запис од политиката што останува по чисто исклучување е вистински дефект што вреди да се запише, и токму затоа рачните измени на генерирана датотека со резолвер се лоша навика: датотеката се препишува и измената исчезнува, или измената опстојува и закова резолвер што повеќе нема рута.

Поминете ја оваа листа еднаш, по ред. Одлучете кој дизајн го применува профилот пред да оцените каков било резултат. Држете ги името, алатката и суфиксот фиксни во двете извршувања. Одвојте го експлицитното барање од пребарувањето од апликација. Читајте ја ефективната политика, не само одговорот. Исчистете ги кешовите последни, откако споредбата е запишана. Проверете со вистинската апликација, потоа рестартирајте еднаш и потврдете дека исклучената состојба се уште е чиста.