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

LAN klijent ispravno doseže svoj VPN, a njegovi DNS upiti ipak se pojavljuju na pogrešnom uzlaznom kanalu. To nije curenje u uobičajenom smislu; to je ono što se dogodi kada usmjerivač prestane prosljeđivati upit i sam na njega odgovori. Presretanje prepisuje odredište na lokalni socket, a razrješivač zatim otvara drugi, nepovezani razgovor s vlastitom adresom izvora i vlastitom odlukom o usmjeravanju. 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 predaje se lokalnom socketu, a izvorni je zapis odradio svoj posao. Ono što nakon toga napušta usmjerivač jest svjež socket koji je stvorio proces razrješivača, s adresom samog usmjerivača kao izvorom.

Zato se politička ruta vezana uz adresu LAN klijenta nikada ne poklapa s uzlaznim upitom. Novi socket pripada dnsmasq-u, a ne klijentu, i kernel ocjenjuje rutu za vlastiti promet usmjerivača. Pravila izvora, pravila sučelja i pravila oznaka svi vide drugačiji tuple. Pretpostavka da se oznaka prenosi najčešća je pogreš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 je li port 53 preusmjeren, preveden na drugog hosta 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 drugo računalo drži paket u kretanju i zadržava tuple klijenta smislenim.

Pogledajte oba protokola. Razrješivač dostupan preko UDP-a i TCP-a bit će testiran preko oba, a skup pravila koji pokriva samo UDP ostavlja tihu rupu za velike odgovore. Pravila koja generira vlastiti upravitelj konfiguracije usmjerivača 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: što prepisuje upit, što ga prima i koji proces posjeduje socket koji sluša. Kad je vlasnik poznat, politika prema upstreamu ima gdje živjeti.

Dajte razrješivaču 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 neobveznim sučeljem 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 sučelje gore su zamjenske vrijednosti za vaše vlastite. Odabir domene i kontrola izlaza ostaju odvojene odluke: ruta mora postojati, adresu izvora mora dopustiti upstream razrješivač i vatrozid mora dopustiti odgovor. Samo usmjeravanje sučelja nije fail-closed, jer nestali tunel može ostaviti razrješivač 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 usmjerivač podržava, a ne u generiranu datoteku, inače sljedeće učitavanje briše popravak.

Što 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 razrješivača 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-a ili preko TLS-a. 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 kontrolirate i gledajte obje strane. Snimka na strani klijenta dokazuje da je upit napustio LAN; samo strana usmjerivača 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 razrješivač radi kada njegova preferirana putanja nestane. To posljednje ponašanje odlučuje je li dizajn fail-closed ili samo sretan.