Prečo dopyty dnsmasq unikajú z VPN po presmerovaní DNS

Klient v LAN sa k svojej VPN dostane správne, a napriek tomu sa jeho dopyty DNS objavujú na nesprávnom vzostupnom spoji. To nie je únik v obvyklom zmysle; je to to, čo sa stane, keď router prestane dopyt preposielať a odpovie naň sám. Zachytenie prepíše cieľ na lokálny socket a resolver potom otvorí druhú, nesúvisiacu konverzáciu s vlastnou zdrojovou adresou a vlastným rozhodnutím o smerovaní. Značky použité na tok klienta opisujú prvú konverzáciu a o druhej nehovoria vôbec nič.

Značka necestuje spolu s dopytom

Značky paketov žijú v zázname conntrack a v pakete na ceste. Pravidlo REDIRECT ten let ukončí: dátová časť sa odovzdá lokálnemu socketu a pôvodný záznam už svoju prácu urobil. To, čo potom opustí router, je čerstvý socket vytvorený procesom resolvera so zdrojovou adresou samotného routera.

Preto sa politická trasa viazaná na adresu klienta v LAN nikdy nezhoduje so vzostupným dopytom. Nový socket patrí dnsmasq, nie klientovi, a jadro trasu vyhodnocuje pre prevádzku samotného routera. Pravidlá zdroja, pravidlá rozhrania aj pravidlá značiek vidia inú n-ticu. Predpoklad, že sa značka prenáša, je v tomto usporiadaní najčastejšou chybou a v zachytení na strane klienta nie je vidieť.

Obe konverzácie skutočne zdieľajú meno aj časovanie, a práve preto vyzerajú ako jeden tok, keď zachytením len preletíte.

Kde sa preposielanie mení na lokálny preklad

Začnite tým, že zistíte, či je port 53 presmerovaný, preložený na iného hostiteľa, alebo ponechaný tak, ako je, pretože všetky tri prípady sa správajú inak. Presmerovanie na lokálny port preposielanie ukončí, zatiaľ čo preklad na iný stroj drží paket v pohybe a udržiava n-ticu klienta zmysluplnou.

Pozrite sa na oba protokoly. Resolver dostupný cez UDP aj TCP bude testovaný cez oba a sada pravidiel pokrývajúca len UDP necháva tichú dieru pre veľké odpovede. Pravidlá generované vlastným správcom konfigurácie routera sa tiež počítajú a úprava generovaného súboru zvyčajne prehrá s ďalším načítaním.

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'

Tieto výstupy odpovedajú na tri otázky v poradí: čo dopyt prepisuje, čo ho prijíma a ktorý proces vlastní načúvajúci socket. Keď je vlastník známy, politika voči upstreamu má kde žiť.

Dajte resolveru vlastnú výstupnú politiku

Upstream špecifický pre doménu je najčistejší nástroj, keď tunel potrebujú len niektoré mená. dnsmasq prijíma riadok server obmedzený na doménu, s voliteľným rozhraním alebo zdrojovou adresou, ktorá vedie dopyt zvoleným zariadením von. Práve toto vedenie spôsobuje, že druhá konverzácia nasleduje VPN.

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

Doména, adresa a rozhranie vyššie sú zástupné hodnoty pre vaše vlastné. Voľba domény a riadenie výstupu zostávajú oddelenými rozhodnutiami: trasa musí existovať, zdrojovú adresu musí povoliť upstream resolver a firewall musí povoliť odpoveď. Samotné vedenie rozhraním nie je fail-closed, pretože zmiznutý tunel môže nechať resolver spadnúť na inú cestu. Držte každú verejnú zálohu ďaleko od menného priestoru, ktorý musí zostať súkromný.

Vložte riadok k vlastníkovi konfigurácie, ktorého router podporuje, nie do generovaného súboru, inak ďalšie načítanie opravu zmaže.

Čo zdieľaná cache nedokáže zachovať

Jeden preposielač s jednou cache obsluhuje každého klienta v LAN, a to búra rozlíšenie, ktoré niektoré siete potrebujú. Ak dvaja klienti musia preložiť ten istý názov rôzne, zdieľaný socket nemá ako zistiť, ktorý klient sa pýtal. Politika pre jednotlivých klientov musí žiť v oddelených inštanciách resolvera alebo vo funkcii preposielania, ktorá zachováva identitu.

Uložená odpoveď tiež nie je dôkazom o novej ceste. Odpoveď môže prísť z pamäte, zatiaľ čo vzostupná trasa zostáva pokazená.

Pravidlá pre port 53 nehovoria nič o aplikáciách, ktoré hovoria DNS cez HTTPS alebo cez TLS. Tie dopyty sa k presmerovaniu nikdy nedostanú, takže politika postavená len na porte 53 opisuje podmnožinu prevádzky a mala by byť dokumentovaná ako podmnožina.

Overte druhú konverzáciu, nie prvú

Testujte s jedným menom, ktoré ovládate, a sledujte obe strany. Zachytenie na strane klienta dokazuje, že dopyt opustil LAN; iba strana routera dokazuje, kam išiel ďalej.

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

Pred každým pokusom vyprázdnite cache, pretože teplá odpoveď skrýva pokazený upstream. Zopakujte cez TCP, potom zopakujte s vypnutým tunelom, aby ste videli, čo resolver robí, keď jeho preferovaná cesta zmizne. Práve toto posledné správanie rozhoduje, či je návrh fail-closed alebo len šťastný.