Вашата 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

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

Решете: задръжте, ограничете или премахнете

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

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