Split-tunnel sluit de browser uit, niet zijn DNS-query’s

Browser uitgesloten van de tunnel, de pagina met het openbare IP bevestigt dat het verkeer via de thuisverbinding naar buiten gaat, en de interne wiki opent nog steeds niet. Naamresolutie ging ergens anders heen, en dat ergens anders is meestal de resolver die de VPN heeft ingesteld. Het datapad en het resolverpad zijn in de meeste split-tunnelontwerpen aparte beslissingen. Controleer welke de browser werkelijk gebruikte voordat u de uitsluiting kapot noemt.

Het datapad en het resolverpad scheiden zich

Een uitsluiting haalt de pakketten van een toepassing uit de tunnel, wat een routerings- en firewallbeslissing op het datapad is. Naamresolutie is een andere opzoeking: een proces vraagt de resolver van het systeem, en die resolver bepaalt welke server de vraag ontvangt.

Beide kunnen opzettelijk en verschillend zijn. Een werkuitrol kan interne naamruimten bij de bedrijfsresolver houden terwijl geselecteerd openbaar browsen buiten de tunnel wordt gestuurd, juist omdat interne namen nergens anders worden opgelost. Het verwarrende geval is het omgekeerde: een openbare site faalt omdat de browser nooit de resolver vroeg die de uitrol verwachtte. Noteer de route en de resolver apart, en de helft van de discussies verdwijnt.

Zoek uit welk proces de vraag stelt

Een browser kan de resolver van het systeem gebruiken, zijn eigen versleutelde DNS-dienst, of een resolver die het besturingssysteem per netwerk toewijst. De eerste volgt het platformbeleid, de tweede omzeilt dat beleid volledig, en de derde hangt af van welke verbinding de query wordt gerouteerd.

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

Lees de geldende configuratie voordat u test: welke verbindingen DNS-servers dragen, welke naamruimten ze claimen, en of een beleid per naam de standaard overschrijft. Op Linux gebruikt split DNS routeringsdomeinen; op Windows doet de naamresolutiebeleidstabel hetzelfde voor naamruimten. Geen van beide is zichtbaar vanaf een lektestpagina.

Bepaal welke resolver welke naam ziet

Schrijf de bedoelde toewijzing op voordat u iets wijzigt: interne namen naar de bedrijfsresolver, openbare namen naar de dienst die het beleid toestaat, en uitzonderingen met een eigenaar. Zonder die lijst wordt elk label van de lektest een beleidsdiscussie die niemand kan beslechten.

Controleer dan de eigen instelling van de browser, want versleutelde DNS in een browser wordt toegepast voordat het besturingssysteem de query ontvangt. Een gebruiker die het inschakelde om een captive portal te omzeilen, heeft stil de resolver overschreven die de uitrol koos. Dat is een configuratiebeslissing en geen lek, en die verdient een beslissing in plaats van een blokkeerlijst.

Herschrijf niet elk DNS-veld om één testlabel groen te maken. Het label beschrijft één query van één proces op één moment.

Verifieer query en verbinding apart

Test de twee paden onafhankelijk. De verbindingstest toont de dataroute, en de resolvertest toont wie de naam ontving.

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

Vraag de resolver ook expliciet, zodat een fout aan de server kan worden toegeschreven en niet aan het pad. Herstart daarna de browser en herhaal, want toepassingen cachen negatieve antwoorden en een oude fout lijkt blijvend.

Noteer na een goedgekeurde wijziging de dataroute en de ontvanger van de resolver als twee afzonderlijke regels met de datum. Als het gedrag bij de volgende herverbinding terugkomt, is het profiel dat het levert wat moet worden hersteld, niet de browser.