Split-tunel isključuje preglednik, ne njegove DNS upite

Izravna putanja podataka ne pomiče razrješavanje imena. Provjerite koji resolver prima upit i je li to bila namjera, prije nego to nazovete curenjem.

Preglednik isključen iz tunela, stranica javnog IP-a potvrđuje da njegov promet izlazi preko kućne veze, a interni wiki se ipak ne otvara. Razrješavanje imena otišlo je negdje drugdje, a to drugdje je obično resolver koji je VPN postavio. Putanja podataka i putanja resolvera odvojene su odluke u većini dizajna split-tunela. Provjerite koju je preglednik stvarno koristio prije nego isključenje nazovete pokvarenim.

Putanja podataka i putanja resolvera se razdvajaju

Isključenje uklanja pakete aplikacije iz tunela, što je odluka o usmjeravanju i vatrozidu na putanji podataka. Razrješavanje imena je druga pretraga: proces pita sistemski resolver, a taj resolver odlučuje koji poslužitelj prima pitanje.

Oboje može biti namjerno i različito. Radna implementacija može zadržati interne prostore imena na korporativnom resolveru dok odabrano javno pregledavanje šalje izvan tunela, upravo zato što se interna imena ne razrješavaju nigdje drugdje. Zbunjujući slučaj je obrnut: javna stranica ne radi jer preglednik nikada nije pitao resolver koji je implementacija očekivala. Zabilježite rutu i resolver odvojeno, i pola rasprave nestaje.

Pronađite koji proces postavlja pitanje

Preglednik može koristiti sistemski resolver, vlastitu uslugu šifriranog DNS-a ili resolver koji operacijski sustav dodjeljuje po mreži. Prvi slijedi politiku platforme, drugi potpuno zaobilazi tu politiku, a treći ovisi o tome na koju se vezu upit usmjerava.

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

Pročitajte važeću konfiguraciju prije testiranja: koje veze nose DNS poslužitelje, koje prostore imena tvrde i nadjačava li politika po imenu zadanu vrijednost. Na Linuxu split DNS koristi domene usmjeravanja; na Windowsu tablica politike razrješavanja imena radi isti posao za prostore imena. Nijedno nije vidljivo sa stranice testa curenja.

Odlučite koji resolver vidi koje ime

Zapišite namjeravano mapiranje prije ikakve promjene: interna imena na korporativni resolver, javna imena na uslugu koju politika dopušta, i iznimke s vlasnikom. Bez tog popisa svaka oznaka testa curenja postaje politička rasprava koju nitko ne može riješiti.

Zatim provjerite vlastitu postavku preglednika, jer se šifrirani DNS u pregledniku primjenjuje prije nego operacijski sustav primi upit. Korisnik koji ga je uključio da zaobiđe captive portal tiho je nadjačao resolver koji je implementacija odabrala. To je odluka o konfiguraciji, a ne curenje, i zaslužuje odluku, a ne blok-popis.

Ne prepisujte svako DNS polje da bi jedna oznaka testa postala zelena. Oznaka opisuje jedan upit jednog procesa u jednom trenutku.

Provjerite upit i vezu odvojeno

Testirajte dvije putanje neovisno. Test veze pokazuje rutu podataka, a test resolvera pokazuje kome je ime dostavljeno.

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

Pitajte resolver i izričito, kako bi se neuspjeh mogao pripisati poslužitelju, a ne putanji. Zatim ponovno pokrenite preglednik i ponovite, jer aplikacije keširaju negativne odgovore i zastario neuspjeh izgleda trajno.

Nakon odobrene promjene zabilježite rutu podataka i primatelja resolvera kao dva odvojena retka s datumom. Ako se ponašanje vrati pri sljedećem povezivanju, profil koji ga daje je ono što treba popraviti, ne preglednik.

Povezani članci