Ваш VPN шаље три DNS сервера: који одговара?
Додатни уноси могу бити резерва, рута по домену или остатак физичке везе. Повежите сваки са опсегом пре него што листу назовете цурењем.
Отворите страницу подешавања након повезивања и три DNS адресе су наведене; питање ревизије је која је обрадила ваш последњи упит. Сам број не одговара ни на шта, јер клијентско гурање, физички интерфејс и политика по домену пишу у исти приказ. Ови уноси носе различите опсеге, а опсег, а не позиција, одлучује ко одговара. Почните раздвајањем извора, затим тестирајте онај који поседује име које вам је важно.
Зашто је листа дужа од вашег профила
VPN клијент гура адресе резолвера за везу тунела, а оперативни систем их држи поред онога што је физички интерфејс већ имао. Рутер, корпоративни DHCP закуп, други VPN и политика по домену сваки додаје свој унос. Зато три адресе на страници могу значити три опсега, а не три кандидата за један посао. Читање броја као доказа цурења прва је грешка ове ревизије.
Унутар једног интерфејса клијент заиста редом покушава своје сервере, па уређена листа није бесмислена. Оно што није ред је обједињени приказ, где уноси из профила, физичке везе и правила по домену стоје један поред другог без једног рангирања. Та разлика одлучује шта тестирате: редослед објашњава понашање унутар једног опсега, а опсег објашњава све остало.
Шифровани DNS разбија слику изнутра апликације. Прегледач или клијент за разговор са сопственим DNS-over-HTTPS резолвером шаље упите потпуно мимо листе оперативног система, па адресе на страници подешавања описују саобраћај који апликација никада није створила. Проверите сопствено подешавање резолвера апликације пре него што оптужите профил за погрешно добијено име.
Шта говори свака од три провере
Сваки извор оставља свој траг на другом месту, и ниједна команда не приказује све. Ово је мапирање које вреди држати поред странице подешавања:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
На систему који користи 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Избришите ту руту чим питање заврши, иначе следећа особа наслеђује мистерију. Ако се интерна имена у том прозору још разрешавају, нешто изван предвиђеног опсега им је одговорило. Ако уместо тога истекну, резерва недостаје или је исправно ограничена, и сопствени дневник резолвера вам каже која од две је била.
Одлучите: задржати, ограничити или уклонити
Задржите други резолвер када одговара на простор имена који вам треба и остаје доступан под профилом. Ограничите га када треба да види један наставак и ништа друго, и уклоните га када нема ни опсег ни документовану сврху. Унос без посла је будуће цурење без користи, а подразумевана вредност добављача није сврха.
Забележите резултат у четири колоне: наставак, резолвер, интерфејс и власник. Та линија одговара на следеће питање ревизије брже од било ког снимка екрана и преживљава ажурирање клијента које тихо преуређује листу.