Browser bûten de tunnel, de side mei it iepenbiere IP befêstiget dat syn ferkear fia de thúsferbining fuortgiet, en de ynterne wiki iepenet noch altyd net. Nammerûntleding gie earne oars hinne, en dat earne oars is meastentiids de resolver dy’t de VPN ynsteld hat. Dataline en resolverline binne aparte besluten yn de measte split-tunnelûntwerpen. Kontrolearje hokker de browser echt brûkt hat foardat jo de útsluting stikkene neame.

Dataline en resolverline skiede

In útsluting hellet de pakketten fan in applikaasje út de tunnel, wat in routing- en firewallbeslút op de dataline is. Nammerûntleding is in oare syktocht: in proses freget de resolver fan it systeem, en dy resolver beslút hokker tsjinner de fraach kriget.

Beide kinne opsetlik en ferskillend wêze. In wurkútrulling kin ynterne nammeruimten by de korporative resolver hâlde wylst it keazen iepenbiere browsen bûten de tunnel stjoert, krekt om’t ynterne nammen nearne oars ûntlede wurde. It betiizjende gefal is it omkearde: in iepenbiere side mislearret om’t de browser nea de resolver frege hat dy’t de útrulling ferwachte. Skriuw de rûte en de resolver apart op, en de helte fan ’e diskusjes ferdwynt.

Fyn hokker proses de fraach stelt

In browser kin de resolver fan it systeem, syn eigen fersifere DNS-tsjinst, of in resolver brûke dy’t it bestjoeringssysteem per netwurk tawijst. De earste folget it platfoarmbelied, de twadde giet dat belied hielendal foarby, en de tredde hinget ôf fan hokker skeakel de fraach nei ta rûte wurdt.

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 de jildende konfiguraasje foardat jo testen: hokker skeakels drage DNS-tsjinners, hokker nammeruimten se opeaskje, en oft in belied per namme de standert oerskriuwt. Op Linux brûkt split DNS routingdomeinen; op Windows docht de tabel foar nammerûntledingsbelied itselde wurk foar nammeruimten. Gjin fan beide is fan in lekttestside te sjen.

Beslút hokker resolver hokker namme sjocht

Skriuw de bedoelde mapping op foardat jo eat feroarje: ynterne nammen nei de korporative resolver, iepenbiere nammen nei de tsjinst dy’t it belied tastean, en útsûnderingen mei in eigner. Sûnder dy list wurdt elk label fan de lekttest in beliedsdiskúsje dy’t nimmen besljochtsje kin.

Kontrolearje dan de eigen ynstelling fan de browser, om’t fersifere DNS yn in browser tapast wurdt foardat it bestjoeringssysteem de fraach kriget. In brûker dy’t it oansette om in captive portal te omgean hat stilwei de resolver oerskreaun dy’t de útrulling keazen hie. Dat is in konfiguraasjebeslút en gjin lek, en it fertsjinnet in beslút ynstee fan in blokkearlist.

Skriuw net elk DNS-fjild oer om ien testlabel grien te krijen. It label beskriuwt ien fraach fan ien proses op ien momint.

Kontrolearje fraach en ferbining apart

Test de twa rûtes ûnôfhinklik. De ferbiningstest lit de datarûte sjen, en de resolvertest lit sjen wa’t de namme krige.

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

Freegje de resolver ek eksplisyt, sadat in misslach oan de tsjinner taskreaun wurde kin en net oan ’e rûte. Start dan de browser opnij en werhelje, om’t applikaasjes negative antwurden cacheje en in âlde misslach oanhâldend liket.

Nei in goedkarde feroaring, skriuw de datarûte en de ûntfanger fan de resolver as twa aparte rigels mei de datum op. As it gedrach by de folgjende werferbining weromkomt, is it profyl dat it leveret wat reparearre wurde moat, net de browser.

Relatearre artikelen