Zašto dnsmasq upiti izlaze izvan VPN-a nakon DNS preusmjeravanja

LAN klijent ispravno doseže svoj VPN, a njegovi DNS upiti se ipak pojavljuju na pogrešnom uzlaznom kanalu. To nije curenje u uobičajenom smislu; to je ono što se dogodi kada ruter prestane prosljeđivati upit i sam na njega odgovori. Presretanje prepisuje odredište na lokalni socket, a rezolver zatim otvara drugi, nepovezani razgovor s vlastitom adresom izvora i vlastitom odlukom o rutiranju. Oznake primijenjene na klijentov tok opisuju prvi razgovor i baš ništa o drugom.

Oznaka ne putuje s upitom

Oznake paketa žive na conntrack zapisu i na paketu u letu. REDIRECT pravilo završava taj let: korisni teret se predaje lokalnom socketu, a originalni zapis je odradio svoj posao. Ono što nakon toga napušta ruter je svjež socket koji je stvorio proces rezolvera, s adresom samog rutera kao izvorom.

Zato se politička ruta vezana za adresu LAN klijenta nikada ne poklapa s uzlaznim upitom. Novi socket pripada dnsmasq-u, a ne klijentu, i kernel ocjenjuje rutu za vlastiti promet rutera. Pravila izvora, pravila interfejsa i pravila oznaka svi vide drugačiji tuple. Pretpostavka da se oznaka prenosi najčešća je greška u ovom postavu i nevidljiva je u snimci na strani klijenta.

Dva razgovora doista dijele ime i vrijeme, i upravo to čini da izgledaju kao jedan tok kada na brzinu pregledate snimku.

Gdje se prosljeđivanje pretvara u lokalno razrješavanje

Počnite tako što ćete utvrditi da li je port 53 preusmjeren, preveden na drugi host ili ostavljen na miru, jer se tri slučaja ponašaju različito. Preusmjeravanje na lokalni port završava prosljeđivanje, dok prevođenje na drugu mašinu drži paket u kretanju i zadržava tuple klijenta smislenim.

Pogledajte oba protokola. Rezolver dostupan preko UDP i TCP bit će testiran preko oba, a skup pravila koji pokriva samo UDP ostavlja tihu rupu za velike odgovore. Pravila koja generira vlastiti menadžer konfiguracije rutera također se računaju, a uređivanje generirane datoteke obično gubi od sljedećeg ponovnog učitavanja.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

Ti izlazi odgovaraju na tri pitanja po redu: šta prepisuje upit, šta ga prima i koji proces posjeduje socket koji sluša. Kad je vlasnik poznat, politika prema upstreamu ima gdje živjeti.

Dajte rezolveru vlastitu izlaznu politiku

Upstream specifičan za domenu najčišći je alat kada samo neka imena trebaju tunel. dnsmasq prihvaća server liniju ograničenu na domenu, s opcionalnim interfejsom ili adresom izvora koja usmjerava upit iz odabranog uređaja. Upravo to usmjeravanje čini da drugi razgovor slijedi VPN.

server=/corp.example/10.30.0.53@tun_work
log-queries

Domena, adresa i interfejs gore su zamjenske vrijednosti za vaše vlastite. Odabir domene i kontrola izlaza ostaju odvojene odluke: ruta mora postojati, adresu izvora mora dopustiti upstream rezolver i firewall mora dopustiti odgovor. Samo usmjeravanje interfejsa nije fail-closed, jer nestali tunel može ostaviti rezolver da padne na drugu putanju. Držite svaki javni rezervni put dalje od prostora imena koji mora ostati privatan.

Stavite liniju kod vlasnika konfiguracije koji ruter podržava, a ne u generiranu datoteku, inače sljedeće učitavanje briše popravku.

Šta zajednički cache ne može sačuvati

Jedan prosljeđivač s jednim cacheom služi svakom LAN klijentu i to ruši razliku koja je nekim mrežama potrebna. Ako dva klijenta moraju različito razriješiti isto ime, zajednički socket nema načina da povrati koji je klijent pitao. Politika po klijentu mora živjeti u odvojenim instancama rezolvera ili u funkciji prosljeđivanja koja čuva identitet.

Keširani odgovor također nije dokaz o novoj putanji. Odgovor može stići iz memorije dok uzlazna ruta ostaje pokvarena.

Pravila za port 53 ne govore ništa o aplikacijama koje govore DNS preko HTTPS ili preko TLS. Ti upiti nikada ne stižu do preusmjeravanja, zato politika izgrađena samo na portu 53 opisuje podskup prometa i treba je dokumentirati kao podskup.

Provjerite drugi razgovor, ne prvi

Testirajte s jednim imenom koje kontrolišete i gledajte obje strane. Snimka na strani klijenta dokazuje da je upit napustio LAN; samo strana rutera dokazuje kamo je otišao dalje.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

Očistite cache prije svakog pokušaja, jer topao odgovor skriva pokvaren upstream. Ponovite preko TCP-a, zatim ponovite s ugašenim tunelom da vidite što rezolver radi kada njegova preferirana putanja nestane. To posljednje ponašanje odlučuje je li dizajn fail-closed ili samo sretan.