Zakaj poizvedbe dnsmasq uidejo iz VPN po preusmeritvi DNS

Odjemalec v LAN pravilno doseže svoj VPN, a njegove poizvedbe DNS se vseeno pojavijo na napačni vzponski povezavi. To ni uhajanje v običajnem smislu; to se zgodi, ko usmerjevalnik preneha posredovati poizvedbo in nanjo odgovori sam. Prestrezanje prepiše cilj na lokalno vtičnico, nato pa resolver odpre drugi, nepovezan pogovor z lastnim izvornim naslovom in lastno odločitvijo o usmerjanju. Oznake, uporabljene na toku odjemalca, opisujejo prvi pogovor in prav nič o drugem.

Oznaka ne potuje s poizvedbo

Oznake paketov živijo v vnosu conntrack in na paketu med letom. Pravilo REDIRECT konča ta let: tovor se preda lokalni vtičnici, prvotni vnos pa je opravil svoje delo. Kar po tem zapusti usmerjevalnik, je sveža vtičnica, ki jo je ustvaril proces resolverja, z naslovom samega usmerjevalnika kot virom.

Zato se politična pot, vezana na naslov odjemalca v LAN, nikoli ne ujema z vzponsko poizvedbo. Nova vtičnica pripada dnsmasq in ne odjemalcu, jedro pa pot ocenjuje za promet samega usmerjevalnika. Pravila vira, pravila vmesnika in pravila oznak vsa vidijo drugačno tuple. Predpostavka, da se oznaka širi, je najpogostejša napaka v tej postavitvi in je nevidna v zajemu na strani odjemalca.

Pogovora si res delita ime in čas, in prav zato so videti kot en tok, ko na hitro preletiš zajem.

Kje se posredovanje spremeni v lokalno razreševanje

Začnite s tem, da ugotovite, ali so vrata 53 preusmerjena, prevedena na drugega gostitelja ali puščena pri miru, ker se trije primeri obnašajo različno. Preusmeritev na lokalna vrata konča posredovanje, medtem ko prevajanje na drug stroj drži paket v gibanju in ohranja tuple odjemalca smiseln.

Poglejte oba protokola. Resolver, dosegljiv prek UDP in TCP, bo preizkušen prek obeh, nabor pravil, ki pokriva samo UDP, pa pušča tiho luknjo za velike odgovore. Pravila, ki jih ustvari lastni upravitelj konfiguracije usmerjevalnika, se prav tako štejejo, urejanje ustvarjene datoteke pa običajno izgubi proti naslednjemu nalaganju.

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 izhodi po vrsti odgovarjajo na tri vprašanja: kaj prepiše poizvedbo, kaj jo prejme in kateri proces ima v lasti poslušajočo vtičnico. Ko je lastnik znan, ima politika proti upstreamu kje živeti.

Dajte resolverju lastno izhodno politiko

Upstream, specifičen za domeno, je najčistejše orodje, ko tunel potrebuje le nekaj imen. dnsmasq sprejme vrstico server, omejeno na domeno, z neobveznim vmesnikom ali izvornim naslovom, ki poizvedbo odpelje iz izbrane naprave. Prav to vodenje poskrbi, da drugi pogovor sledi VPN.

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

Domena, naslov in vmesnik zgoraj so nadomestna mesta za vaše lastne vrednosti. Izbira domene in nadzor izhoda ostaneta ločeni odločitvi: pot mora obstajati, izvorni naslov mora dovoliti upstream resolver in požarni zid mora dovoliti odgovor. Samo vodenje po vmesniku ni fail-closed, ker lahko izginuli tunel pusti resolver, da pade na drugo pot. Vsako javno rezervno pot držite stran od imenskega prostora, ki mora ostati zaseben.

Vrstico vstavite k lastniku konfiguracije, ki ga usmerjevalnik podpira, in ne v ustvarjeno datoteko, sicer naslednje nalaganje popravek izbriše.

Česa si skupni predpomnilnik ne more ohraniti

En posredovalnik z enim predpomnilnikom služi vsakemu odjemalcu v LAN, in to podre razlikovanje, ki ga nekatere mreže potrebujejo. Če morata dva odjemalca isto ime razrešiti različno, skupna vtičnica nima načina, da bi ugotovila, kateri odjemalec je vprašal. Politika za posameznega odjemalca mora živeti v ločenih primerki resolverja ali v funkciji posredovanja, ki ohrani identiteto.

Predpomnjeni odgovor tudi ni dokaz o novi poti. Odgovor lahko pride iz pomnilnika, medtem ko vzponska pot ostaja pokvarjena.

Pravila za vrata 53 ne povedo ničesar o aplikacijah, ki govorijo DNS prek HTTPS ali prek TLS. Te poizvedbe nikoli ne dosežejo preusmeritve, zato politika, zgrajena samo na vratih 53, opisuje podmnožico prometa in bi morala biti dokumentirana kot podmnožica.

Preverite drugi pogovor, ne prvega

Preizkusite z enim imenom, ki ga nadzorujete, in opazujte obe strani. Zajem na strani odjemalca dokazuje, da je poizvedba zapustila LAN; le stran usmerjevalnika dokazuje, kam je šla naprej.

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

Izpraznite predpomnilnik pred vsakim poskusom, ker topel odgovor skrije pokvarjen upstream. Ponovite prek TCP in nato ponovite z izklopljenim tunelom, da vidite, kaj resolver počne, ko njegove prednostne poti ni več. Prav to zadnje vedenje odloči, ali je zasnova fail-closed ali le srečna.