Firwat dnsmasq-Ufroen no enger DNS-Ëmleedung aus der VPN erauskommen
Eng REDIRECT op der Router-Säit mécht aus enger LAN-DNS-Ufro en neien Resolver-Socket. D’Marken um Client-Flow erreechen en ni, also setzt den Upstream-Ausgang direkt.
De LAN-Client erreecht seng VPN richteg, an trotzdem erschéngen seng DNS-Ufroen um falschen Uplink. Dat ass kee Leck am übleche Sënn; et ass dat, wat geschitt, wann de Router ophält eng Ufro weiderzeschécken an se selwer beäntwert. D’Interceptioun schreift d’Destinatioun op en lokale Socket ëm, an da mécht de Resolver eng zweet, onverbonne Konversatioun mat senger eegener Quelladress a senger eegener Routing-Entscheedung op. D’Marken, déi um Client-Flow ugebruecht goufen, beschreiwen déi éischt Konversatioun an absolut näischt iwwer déi zweet.
D’Mark reest net mat der Ufro
Pakmarken liewen op engem conntrack-Antrag an um Pak deen ënnerwee ass. Eng REDIRECT-Reeg mécht deem Fluch en Enn: d’Payload gëtt un en lokale Socket iwwerginn, an den ursprénglechen Antrag huet seng Aarbecht gemaach. Wat duerno de Router verléisst, ass en neie Socket, deen de Resolver-Prozess erstallt huet, mat der Adress vum Router selwer als Quell.
Dofir passt eng Policy-Route, déi op d’Adress vum LAN-Client baséiert, ni op d’Upstream-Ufro. Den neie Socket gehéiert zu dnsmasq an net zum Client, an de Kernel evaluéiert d’Route fir de Verkéier vum Router selwer. Quellregele, Interface-Regele a Markregele gesinn all en aneren Tuple. Unzehuelen, datt d’Mark sech weiderplant, ass dee heefegste Feeler an dësem Opbau, an en ass onsiichtbar an enger Opnam op der Client-Säit.
Déi zwou Konversatioune deelen awer en Numm an en Timing, an dat ass et, wat se wéi eng eenzeg Flow ausgesi léisst, wann een eng Opnam séier duerchkuckt.
Wou aus Weiderschécken lokal Opléisung gëtt
Fänkt domat un erauszefannen, ob de Port 53 ëmgeleet, op en aneren Host iwwersat oder einfach gelooss gëtt, well déi dräi Fäll sech anescht behuelen. Eng Ëmleedung op en lokale Port mécht dem Weiderschécken en Enn, während eng Iwwersetzung op eng aner Maschinn de Pak a Beweegung hält an den Tuple vum Client sënnvoll hält.
Kuckt béid Protokoller un. En Resolver, deen iwwer UDP an TCP erreechbar ass, gëtt iwwer béid getest, an e Reegelset, deen nëmmen UDP deckt, léisst en duuss Lach fir grouss Äntwerten. Reegelen, déi de Konfiguratiounsmanager vum Router selwer generéiert, zielen och, an eng generéiert Datei z’änneren verléiert meeschtens géint déi nächst Neiopladung.
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'
Déi Ausgaben beäntweren dräi Froen an der Rei: wat d’Ufro ëmschreift, wat se empfänkt, a wéi ee Prozess de lauschenden Socket besëtzt. Soubal den Eegentümer bekannt ass, huet d’Upstream-Policy en Ort fir ze liewen.
Gitt dem Resolver seng eege Ausgangspolicy
En domänspezifeschen Upstream ass dat proppst Instrument, wann nëmmen e puer Nimm den Tunnel brauchen. dnsmasq akzeptéiert eng server-Zeil, déi op eng Domän ageschränkt ass, mat engem optionalen Interface oder enger Quelladress, déi d’Ufro aus engem gewielten Apparat erausleot. Genau déi Leedung mécht, datt déi zweet Konversatioun der VPN follegt.
server=/corp.example/10.30.0.53@tun_work
log-queries
D’Domän, d’Adress an d’Interface uewendriwwer sinn Plazhalter fir Är eege Wäerter. D’Domänewiel an d’Ausgangskontroll bleiwen getrennte Entscheedungen: d’Route muss existéieren, d’Quelladress muss vum Upstream-Resolver erlaabt sinn, an d’Firewall muss d’Äntwert erlaben. Nëmmen Interface-Leedung ass net fail-closed, well en verschwundenen Tunnel de Resolver op en anere Wee ka fale loossen. Halt all ëffentlech Eenzelofall wäit ewech vun engem Nummraum, dee privat muss bleiwen.
Setzt d’Zeil bei den Eegentümer vun der Konfiguratioun, deen de Router ënnerstëtzt, an net an eng generéiert Datei, soss läscht déi nächst Neiopladung d’Korrektur.
Wat en gedeelten Cache net bewaache kann
Een Weiderschécker mat engem Cache zerwéiert all LAN-Client, an dat brécht eng Ënnerscheedung zesummen, déi verschidden Netzwierker brauchen. Wann zwee Clienten deeselwechten Numm anescht opléise mussen, huet den gedeelte Socket keng Manéier erauszefannen, wien gefrot huet. D’Policy pro Client muss an getrennte Resolver-Instanzen oder an enger Weiderschéck-Funktioun liewen, déi d’Identitéit behält.
Eng gecachte Äntwert ass och kee Beweis iwwer den neie Wee. D’Äntwert kann aus dem Späicher kommen, während d’Upstream-Route futti bleift.
D’Reegele fir de Port 53 soen näischt iwwer Applikatiounen, déi DNS iwwer HTTPS oder iwwer TLS schwätzen. Déi Ufroe kommen ni bis zur Ëmleedung, also beschreift eng Policy, déi nëmmen um Port 53 opgebaut ass, eng Ënnergrupp vum Verkéier a soll als Ënnergrupp dokumentéiert ginn.
Verifizéiert déi zweet Konversatioun, net déi éischt
Testt mat engem Numm, deen Dir kontrolléiert, a kuckt op béid Säiten. Eng Opnam op der Client-Säit beweist, datt d’Ufro d’LAN verlooss huet; nëmmen d’Router-Säit beweist, wou se duerno higaang ass.
sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53
Leert de Cache virun all Versuch, well eng waarm Äntwert en futti Upstream verstoppt. Widderhëlt iwwer TCP, widderhëlt dann mam Tunnel ënnen, fir ze gesinn, wat de Resolver mécht, wann säi preferéierte Wee fort ass. Genau dat lescht Verhalen entscheet, ob den Design fail-closed oder just glécklech ass.