Разделеният тунел изключва браузъра, не неговите DNS заявки

Правият път на данните не мести разрешаването на имена. Проверете кой резолвер получава заявката и дали това е било замислено, преди да го наречете изтичане.

Браузърът е изключен от тунела, страницата с публичния IP потвърждава, че трафикът му излиза през домашната връзка, а вътрешното уики все още не се отваря. Разрешаването на имена е отишло другаде и това другаде обикновено е резолверът, който VPN е настроил. Пътят на данните и пътят на резолвера са отделни решения в повечето проекти на разделен тунел. Проверете кой от тях браузърът действително е използвал, преди да наречете изключването счупено.

Пътят на данните и пътят на резолвера се разделят

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

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

Открийте кой процес задава въпроса

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

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Прочетете действащата конфигурация преди тестване: кои връзки носят DNS сървъри, какви пространства от имена претендират и дали политика за отделно име отменя подразбирането. В Linux разделеният DNS използва домейни за маршрутизация; в Windows таблицата с политика за разрешаване на имена върши същата работа за пространства от имена. Никое от тях не се вижда от страница за тест за изтичане.

Решете кой резолвер да вижда кое име

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

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

Не преписвайте всяко DNS поле, за да стане един етикет от теста зелен. Етикетът описва една заявка от един процес в един момент.

Проверявайте заявката и връзката отделно

Тествайте двата пътя независимо. Тестът на връзката показва маршрута на данните, а тестът на резолвера показва кой е получил името.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

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

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

Подобни статии