Вашиот VPN испраќа три DNS сервери: кој одговара?

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

Зошто списокот е подолг од вашиот профил

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

Во еден интерфејс клиентот навистина ги пробува своите сервери по ред, па подреден список не е бесмислен. Она што не е ред е споениот приказ, каде записите од профилот, физичката врска и правилата по домен стојат еден до друг без единствено рангирање. Таа разлика решава што тестирате: редот објаснува однесување во еден опсег, а опсегот објаснува сѐ друго.

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

Што кажува секоја од трите проверки

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

На систем што користи systemd-resolved, resolvectl status е меродавна, бидејќи известува за DNS по врска заедно со рутирачките домени. macOS одговара преку scutil --dns, која ги наведува резолверите со опсег по редослед на пробување. Windows ги дели двете половини: Get-DnsClientServerAddress за сервери по интерфејс и Get-DnsClientNrptPolicy за правилата за наставка. Извршете ја командата што му припаѓа на резолверот што навистина се користи, бидејќи машина со контејнерска околина и десктоп резолвер може да има повеќе од еден инсталиран.

Резервен резолвер што не може да одговори за вашата зона

Вториот запис обично постои заради достапност, а достапноста работи само ако резервата ги знае имињата. Прашајте јавен резолвер за внатрешно име на домаќин и тој враќа NXDOMAIN, или џокер одговор од домен за пребарување што нема никаква врска со вас. Непровереното префрлање тогаш создава прекин точно во моментот кога е потребно.

Split DNS постои за да го спречи тоа: наставките на компанијата одат кај резолвер што ја држи зоната, а јавните имиња остануваат на стандардната патека. Дизајнот е цврст, и зависи од тоа списокот со наставки да биде целосен. Microsoft ја документира политиката на резолвер по наставка што го води ова на Windows, и истата идеја се појавува како рутирачки домени во systemd-resolved и како резолвери со опсег на macOS.

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

Прашајте преку политиката, не околу неа

Прашајте преку резолверот на оперативниот систем, бидејќи директното барање до сервер ја заобиколува политиката и известува само што би рекол тој сервер. Разликата меѓу двата одговори е целата поента:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

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

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

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

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

Одлучете: задржете, ограничете или отстранете

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

Запишете го резултатот во четири колони: наставка, резолвер, интерфејс и сопственик. Таа линија одговара на следното прашање на ревизијата побрзо од која било слика од екран, и преживува ажурирање на клиентот што тивко го прередува списокот.