Split-tonnel sluit die blaaier uit, nie sy DNS-navrae nie

Blaaier uit die tonnel uitgesluit, ’n publieke-IP-bladsy bevestig dat sy verkeer via die tuisverbinding uitgaan, en die interne wiki wil steeds nie oopmaak nie. Naamresolusie het elders heen gegaan, en daardie elders is gewoonlik die resolveerder wat die VPN opgestel het. Datapad en resolveerderpad is in die meeste split-tonnel-ontwerpe afsonderlike besluite. Kontroleer watter een die blaaier werklik gebruik het voordat jy die uitsluiting as stukkend bestempel.

Datapad en resolveerderpad skei

’n Uitsluiting verwyder ’n toepassing se pakkette uit die tonnel, wat ’n roete- en vuurmuurbesluit op die datapad is. Naamresolusie is ’n ander opsoektog: ’n proses vra die stelsel se resolveerder, en daardie resolveerder besluit watter bediener die vraag ontvang.

Albei kan opsetlik en verskillend wees. ’n Werksontplooiing kan interne naamruimtes by die korporatiewe resolveerder hou terwyl gekose publieke blaaiery buite die tonnel gestuur word, juis omdat interne name nêrens anders opgelos word nie. Die verwarrende geval is die omgekeerde: ’n publieke werf wat misluk omdat die blaaier nooit die resolveerder gevra het wat die ontplooiing verwag het nie. Teken die roete en die resolveerder afsonderlik aan, en die helfte van die argumente verdwyn.

Vind watter proses die vraag vra

’n Blaaier kan die stelsel se resolveerder gebruik, sy eie versleutelde DNS-diens, of ’n resolveerder wat die bedryfstelsel per netwerk toeken. Die eerste volg platformbeleid, die tweede omseil daardie beleid heeltemal, en die derde hang daarvan af na watter skakel die navraag geroteer word.

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

Lees die effektiewe konfigurasie voordat jy toets: watter skakels dra DNS-bedieners, watter naamruimtes hulle opeis, en of ’n beleid per naam die verstek oorheers. Op Linux gebruik gesplete DNS roeteringsdomeine; op Windows doen die naamresolusiebeleidstabel dieselfde werk vir naamruimtes. Nie een is van ’n lektoetsbladsy sigbaar nie.

Besluit watter resolveerder watter naam sien

Skryf die beoogde kartering neer voordat jy iets verander: interne name na die korporatiewe resolveerder, publieke name na watter diens die beleid ook al toelaat, en uitsonderings met ’n eienaar. Sonder daardie lys word elke lektoets-etiket ’n beleidsargument wat niemand kan besleg nie.

Kontroleer dan die blaaier se eie instelling, want versleutelde DNS in ’n blaaier word toegepas voordat die bedryfstelsel die navraag ontvang. ’n Gebruiker wat dit aangeskakel het om ’n vasvangportaal te omseil, het stilweg die resolveerder wat die ontplooiing gekies het, oorheers. Dit is ’n konfigurasiebesluit eerder as ’n lek, en dit verdien ’n besluit eerder as ’n blokkeerlys.

Moenie elke DNS-veld herskryf om een toetsetiket groen te laat word nie. Die etiket beskryf een navraag van een proses op een oomblik.

Verifieer navraag en verbinding afsonderlik

Toets die twee paaie onafhanklik. Die verbindingstoets wys die dataroete, en die resolveerderstoets wys wie die naam ontvang het.

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

Vra die resolveerder ook eksplisiet, sodat ’n mislukking aan die bediener toegeskryf kan word eerder as aan die pad. Herbegin dan die blaaier en herhaal, want toepassings kas negatiewe antwoorde en ’n verouderde mislukking lyk aanhoudend.

Teken ná ’n goedgekeurde verandering die dataroete en die ontvanger van die resolveerder as twee afsonderlike reëls saam met die datum aan. As die gedrag by die volgende herverbinding terugkeer, is die profiel wat dit verskaf die ding om reg te maak, nie die blaaier nie.