Split-tunnel undantar webbläsaren, inte dess DNS-frågor

Webbläsaren undantagen från tunneln, sidan med offentlig IP bekräftar att trafiken går ut via hemanslutningen, och den interna wikin öppnas fortfarande inte. Namnuppslagningen gick någon annanstans, och den platsen är oftast resolvern som VPN:t ställde in. Datavägen och resolvervägen är separata beslut i de flesta split-tunnel-design. Kontrollera vilken webbläsaren faktiskt använde innan du kallar undantaget trasigt.

Datavägen och resolvervägen skiljs åt

Ett undantag tar bort ett programs paket från tunneln, vilket är ett routing- och brandväggsbeslut på datavägen. Namnuppslagning är en annan sökning: en process frågar systemets resolver, och den resolvern avgör vilken server som tar emot frågan.

Båda kan vara avsiktliga och olika. En arbetsutrullning kan behålla interna namnrymder hos företagsresolvern medan vald offentlig surfning skickas utanför tunneln, just eftersom interna namn inte löses någon annanstans. Det förvirrande fallet är det omvända: en offentlig webbplats misslyckas därför att webbläsaren aldrig frågade resolvern som utrullningen förväntade sig. Anteckna rutten och resolvern separat, och hälften av diskussionerna försvinner.

Ta reda på vilken process som ställer frågan

En webbläsare kan använda systemets resolver, sin egen krypterade DNS-tjänst eller en resolver som operativsystemet tilldelar per nätverk. Den första följer plattformens policy, den andra kringgår policyn helt, och den tredje beror på vilken länk frågan dirigeras till.

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

Läs den gällande konfigurationen innan du testar: vilka länkar som bär DNS-servrar, vilka namnrymder de gör anspråk på, och om en policy per namn åsidosätter standarden. På Linux använder delad DNS routingdomäner; på Windows gör tabellen för namnupplösningspolicy samma sak för namnrymder. Ingen av dem syns från en läcktestssida.

Bestäm vilken resolver som ser vilket namn

Skriv ned den avsedda mappningen innan du ändrar något: interna namn till företagsresolvern, offentliga namn till den tjänst policyn tillåter, och undantag med en ägare. Utan listan blir varje etikett i läcktestet en policydebatt som ingen kan avgöra.

Kontrollera sedan webbläsarens egen inställning, eftersom krypterad DNS i en webbläsare tillämpas innan operativsystemet tar emot frågan. En användare som aktiverade det för att kringgå en captive portal har tyst åsidosatt resolvern som utrullningen valde. Det är ett konfigurationsbeslut och inte en läcka, och det förtjänar ett beslut i stället för en blockeringslista.

Skriv inte om varje DNS-fält för att göra en testetikett grön. Etiketten beskriver en fråga från en process vid ett tillfälle.

Verifiera fråga och anslutning separat

Testa de två vägarna oberoende. Anslutningstestet visar datarutten, och resolvertestet visar vem som tog emot namnet.

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

Fråga också resolvern uttryckligen, så att ett fel kan tillskrivas servern och inte vägen. Starta sedan om webbläsaren och upprepa, eftersom program cachar negativa svar och ett gammalt fel ser bestående ut.

Efter en godkänd ändring, anteckna datarutten och mottagaren av resolvern som två separata rader med datumet. Om beteendet återkommer vid nästa återanslutning är det profilen som levererar det som ska rättas, inte webbläsaren.