Varför dnsmasq-frågor lämnar VPN:en efter en DNS-omdirigering

LAN-klienten når sin VPN korrekt och ändå dyker dess DNS-frågor upp på fel uppströmslänk. Det är inte en läcka i vanlig mening; det är vad som händer när routern slutar vidarebefordra en fråga och svarar på den själv. Avlyssningen skriver om målet till en lokal socket, och sedan öppnar resolvern ett andra, orelaterat samtal med sin egen källadress och sitt eget routingbeslut. Markeringarna som satts på klientflödet beskriver det första samtalet och absolut ingenting om det andra.

Markeringen reser inte med frågan

Paketmarkeringar lever på en conntrack-post och på paketet under vägs. En REDIRECT-regel avslutar den färden: nyttolasten lämnas till en lokal socket, och den ursprungliga posten har gjort sitt. Det som därefter lämnar routern är en färsk socket skapad av resolverprocessen, med routerns egen adress som källa.

Därför matchar en policyrutt knuten till LAN-klientens adress aldrig uppströmsfrågan. Den nya socketen tillhör dnsmasq och inte klienten, och kärnan utvärderar rutten för routerns egen trafik. Källregler, gränssnittsregler och markeringsregler ser alla en annan tupel. Att anta att markeringen fortplantas är det vanligaste felet i den här uppsättningen, och det syns inte i en fångst på klientsidan.

De två samtalen delar faktiskt ett namn och en timing, och det är vad som får dem att se ut som ett enda flöde när man skummar igenom en fångst.

Där vidarebefordran blir lokal uppslagning

Börja med att ta reda på om port 53 omdirigeras, översätts till en annan värd eller lämnas ifred, eftersom de tre fallen beter sig olika. En omdirigering till en lokal port avslutar vidarebefordran, medan en översättning till en annan maskin håller paketet i rörelse och håller klientens tupel meningsfull.

Titta på båda protokollen. En resolver som nås över UDP och TCP testas över båda, och en regeluppsättning som bara täcker UDP lämnar ett tyst hål för stora svar. Regler som routerns egen konfigurationshanterare genererar räknas också, och att redigera en genererad fil förlorar oftast mot nästa omladdning.

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'

Dessa utdata besvarar tre frågor i ordning: vad som skriver om frågan, vad som tar emot den och vilken process som äger den lyssnande socketen. När ägaren är känd har uppströmspolicyn någonstans att bo.

Ge resolvern en egen utströmspolicy

En domänspecifik upstream är det renaste verktyget när bara vissa namn behöver tunneln. dnsmasq accepterar en server-rad begränsad till en domän, med ett valfritt gränssnitt eller källadress som styr frågan ut ur en vald enhet. Den styrningen är vad som får det andra samtalet att följa VPN:en.

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

Domänen, adressen och gränssnittet ovan är platshållare för dina egna värden. Domänval och utgångskontroll förblir separata beslut: rutten måste finnas, källadressen måste tillåtas av uppströmsresolvern och brandväggen måste tillåta svaret. Enbart gränssnittsstyrning är inte fail-closed, eftersom en försvunnen tunnel kan lämna resolvern att falla tillbaka på en annan väg. Håll varje offentlig reservväg långt borta från ett namnutrymme som måste förbli privat.

Sätt raden hos den konfigurationsägare som routern stöder i stället för i en genererad fil, annars raderar nästa omladdning rättelsen.

Vad en delad cache inte kan bevara

En vidarebefordrare med en cache betjänar varje LAN-klient, och det kollapsar en distinktion som vissa nätverk behöver. Om två klienter måste slå upp samma namn olika, har den delade socketen inget sätt att återställa vilken klient som frågade. Policy per klient måste leva i separata resolverinstanser eller i en vidarebefordringsfunktion som behåller identiteten.

Ett cachat svar är inte heller bevis om den nya vägen. Svaret kan komma från minnet medan uppströmsrutten förblir trasig.

Regler för port 53 säger ingenting om applikationer som talar DNS över HTTPS eller över TLS. De frågorna når aldrig omdirigeringen, så en policy byggd bara på port 53 beskriver en delmängd av trafiken och bör dokumenteras som en delmängd.

Verifiera det andra samtalet, inte det första

Testa med ett namn du kontrollerar och titta på båda sidorna. En fångst på klientsidan bevisar att frågan lämnade LAN:et; bara routersidan bevisar vart den tog vägen sedan.

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

Töm cachen före varje försök, eftersom ett varmt svar döljer en trasig upstream. Upprepa över TCP och upprepa sedan med tunneln nere för att se vad resolvern gör när dess föredragna väg är borta. Det sista beteendet avgör om designen är fail-closed eller bara lycklig.