Waarom dnsmasq-query’s na een DNS-omleiding buiten de VPN belanden

De LAN-client bereikt zijn VPN correct en toch verschijnen zijn DNS-query’s op de verkeerde uplink. Dat is geen lek in de gebruikelijke zin; het is wat er gebeurt wanneer de router een query niet meer doorstuurt en er zelf antwoord op geeft. De onderschepping herschrijft de bestemming naar een lokale socket, en vervolgens opent de resolver een tweede, ongerelateerd gesprek met zijn eigen bronadres en zijn eigen routeringsbeslissing. De markeringen op de clientflow beschrijven het eerste gesprek en helemaal niets over het tweede.

De markering reist niet mee met de query

Packetmarkeringen leven op een conntrack-regel en op het pakket onderweg. Een REDIRECT-regel beëindigt die vlucht: de payload wordt aan een lokale socket overgedragen, en de oorspronkelijke regel heeft zijn werk gedaan. Wat daarna de router verlaat, is een verse socket die het resolverproces heeft gemaakt, met het adres van de router zelf als bron.

Daarom komt een policy-route die op het adres van de LAN-client is gebaseerd nooit overeen met de upstream-query. De nieuwe socket hoort bij dnsmasq en niet bij de client, en de kernel beoordeelt de route voor het verkeer van de router zelf. Bronregels, interfaceregels en markeringsregels zien allemaal een andere tuple. Aannemen dat de markering zich voortplant is de meest voorkomende fout in deze opzet, en ze is onzichtbaar in een capture aan de clientkant.

De twee gesprekken delen wel een naam en een timing, en dat is wat ze op één flow laat lijken wanneer je een capture snel doorbladert.

Waar doorsturen lokale resolutie wordt

Begin met vast te stellen of poort 53 wordt omgeleid, naar een andere host vertaald of met rust gelaten, want de drie gevallen gedragen zich anders. Een omleiding naar een lokale poort beëindigt het doorsturen, terwijl een vertaling naar een andere machine het pakket in beweging houdt en de tuple van de client betekenisvol houdt.

Kijk naar beide protocollen. Een resolver die via UDP en TCP bereikbaar is, wordt via beide getest, en een regelset die alleen UDP dekt, laat een stil gat voor grote antwoorden. Regels die de configuratiemanager van de router zelf genereert tellen ook mee, en het bewerken van een gegenereerd bestand verliest meestal van de volgende herlaadbeurt.

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'

Die uitvoer beantwoordt drie vragen in volgorde: wat de query herschrijft, wat hem ontvangt, en welk proces de luisterende socket bezit. Zodra de eigenaar bekend is, heeft het upstream-beleid een plek om te wonen.

Geef de resolver zijn eigen uitgangsbeleid

Een domeinspecifieke upstream is het schoonste gereedschap wanneer alleen sommige namen de tunnel nodig hebben. dnsmasq accepteert een server-regel die tot een domein is beperkt, met een optionele interface of bronadres dat de query uit een gekozen apparaat stuurt. Die sturing is wat het tweede gesprek de VPN laat volgen.

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

Het domein, het adres en de interface hierboven zijn plaatsaanduidingen voor uw eigen waarden. Domeinkeuze en uitgangscontrole blijven aparte beslissingen: de route moet bestaan, het bronadres moet door de upstream-resolver worden toegestaan, en de firewall moet het antwoord toestaan. Alleen sturing via de interface is niet fail-closed, want een verdwenen tunnel kan de resolver op een ander pad laten terugvallen. Houd elke openbare terugval ver weg van een naamruimte die privé moet blijven.

Zet de regel bij de configuratie-eigenaar die de router ondersteunt in plaats van in een gegenereerd bestand, anders wist de volgende herlaadbeurt de correctie.

Wat een gedeelde cache niet kan bewaren

Eén doorstuurder met één cache bedient elke LAN-client, en dat laat een onderscheid instorten dat sommige netwerken nodig hebben. Als twee clients dezelfde naam verschillend moeten oplossen, heeft de gedeelde socket geen manier om te achterhalen welke client het vroeg. Beleid per client moet leven in afzonderlijke resolver-instanties of in een doorstuurfunctie die de identiteit bewaart.

Een gecacht antwoord is ook geen bewijs over het nieuwe pad. Het antwoord kan uit het geheugen komen terwijl de upstream-route kapot blijft.

Regels voor poort 53 zeggen niets over toepassingen die DNS over HTTPS of over TLS spreken. Die query’s bereiken de omleiding nooit, dus een beleid dat alleen op poort 53 is gebouwd, beschrijft een deelverzameling van het verkeer en zou als deelverzameling gedocumenteerd moeten worden.

Controleer het tweede gesprek, niet het eerste

Test met één naam die u beheert en kijk naar beide kanten. Een capture aan de clientkant bewijst dat de query het LAN heeft verlaten; alleen de routerkant bewijst waar hij daarna heen ging.

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

Leeg de cache voor elke poging, want een warm antwoord verbergt een kapotte upstream. Herhaal over TCP en herhaal daarna met de tunnel neer om te zien wat de resolver doet wanneer zijn voorkeurspad weg is. Dat laatste gedrag bepaalt of het ontwerp fail-closed is of alleen gelukkig.