Kial dnsmasq-demandoj eskapas la VPN post DNS-alidirektigo

La LAN-kliento ĝuste atingas sian VPN, kaj tamen ĝiaj DNS-demandoj aperas sur la malĝusta suprena kanalo. Tio ne estas liko laŭ la kutima senco; ĝi estas tio, kio okazas kiam la enkursigilo ĉesas plusendi demandon kaj mem respondas ĝin. La interkapto reverkas la celon al loka ingo, kaj poste la solvilo malfermas duan, nerilatan konversacion kun propra fontadreso kaj propra enkursiga decido. Markoj aplikitaj al la klienta fluo priskribas la unuan konversacion kaj tute nenion pri la dua.

La marko ne vojaĝas kun la demando

Paketaj markoj vivas sur conntrack-enskribo kaj sur la paketo dumfluge. Regulo REDIRECT finas tiun flugon: la ŝarĝo estas transdonita al loka ingo, kaj la origina enskribo jam faris sian taskon. Tio, kio poste forlasas la enkursigilon, estas freŝa ingo kreita de la solvila procezo, kun la adreso de la enkursigilo mem kiel fonto.

Tial politika vojo ligita al la adreso de la LAN-kliento neniam kongruas kun la suprena demando. La nova ingo apartenas al dnsmasq anstataŭ al la kliento, kaj la kerno taksas la vojon por la propra trafiko de la enkursigilo. Fontaj reguloj, interfacaj reguloj kaj markaj reguloj ĉiuj vidas alian opon. Supozi, ke la marko disvastiĝas, estas la plej ofta eraro en ĉi tiu agordo, kaj ĝi estas nevidebla en klientflanka kaptado.

La du konversacioj ja kunhavas nomon kaj tempon, kaj tio igas ilin aspekti kiel unu fluo kiam vi trarigardas kaptaĵon.

Kie plusendo fariĝas loka solvado

Komencu trovante ĉu pordo 53 estas alidirektata, tradukata al alia gastiganto aŭ lasata netuŝita, ĉar la tri kazoj kondutas malsame. Alidirektado al loka pordo finas plusendadon, dum tradukado al alia maŝino tenas la paketon moviĝanta kaj tenas la opon de la kliento senchava.

Rigardu ambaŭ protokolojn. Solvilo atingebla per UDP kaj TCP estos testita per ambaŭ, kaj regularo kovranta nur UDP lasas silentan truon por grandaj respondoj. Reguloj generitaj de la propra agordadministrilo de la enkursigilo ankaŭ validas, kaj redakti generitan dosieron kutime perdas kontraŭ la sekva reŝargo.

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'

Tiuj eligoj respondas tri demandojn laŭorde: kio reverkas la demandon, kio ricevas ĝin kaj kiu procezo posedas la aŭskultantan ingon. Post kiam la posedanto estas konata, la suprena politiko havas lokon por vivi.

Donu al la solvilo propran elirpolitikon

Domajno-specifa suprena kanalo estas la plej pura ilo kiam nur kelkaj nomoj bezonas la tunelon. dnsmasq akceptas server-linion limigitan al domajno, kun laŭvola interfaco aŭ fontadreso kiu direktas la demandon el elektita aparato. Ĝuste tiu direktado igas la duan konversacion sekvi la VPN.

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

La domajno, adreso kaj interfaco supre estas lokokupiloj por viaj propraj valoroj. Domajna elekto kaj elirkontrolo restas apartaj decidoj: la vojo devas ekzisti, la fontadreso devas esti permesita de la suprena solvilo, kaj la fajroŝirmilo devas permesi la respondon. Nur interfaca direktado ne estas fail-closed, ĉar malaperinta tunelo povas lasi la solvilon refali al alia vojo. Tenu ajnan publikan rezervan vojon for de nomspaco, kiu devas resti privata.

Metu la linion en la agordan posedanton, kiun la enkursigilo subtenas, anstataŭ en generitan dosieron, alie la sekva reŝargo forviŝas la riparon.

Kion komuna kaŝmemoro ne povas konservi

Unu plusendilo kun unu kaŝmemoro servas ĉiun LAN-klienton, kaj tio faligas distingon, kiun iuj retoj bezonas. Se du klientoj devas solvi la saman nomon malsame, la komuna ingo havas neniun manieron rekuperi, kiu kliento demandis. Politiko por kliento devas vivi en apartaj solvilaj kazoj aŭ en plusenda trajto, kiu konservas la identecon.

Kaŝmemorita respondo ankaŭ ne estas pruvo pri la nova vojo. La respondo povas veni el memoro dum la suprena vojo restas rompita.

Reguloj pri pordo 53 diras nenion pri aplikaĵoj, kiuj parolas DNS per HTTPS aŭ per TLS. Tiuj demandoj neniam atingas la alidirektadon, do politiko konstruita nur sur pordo 53 priskribas subaron de la trafiko kaj devus esti dokumentita kiel subaro.

Kontrolu la duan konversacion, ne la unuan

Testu per unu nomo, kiun vi kontrolas, kaj observu ambaŭ flankojn. Klientflanka kaptado pruvas, ke la demando forlasis la LAN-on; nur la enkursigila flanko pruvas, kien ĝi iris poste.

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

Malplenigu la kaŝmemoron antaŭ ĉiu provo, ĉar varma respondo kaŝas rompitan supran kanalon. Ripetu per TCP, poste ripetu kun la tunelo malsupra por vidi, kion la solvilo faras kiam ĝia preferata vojo mankas. Tiu lasta konduto decidas ĉu la dezajno estas fail-closed aŭ simple bonŝanca.