Waarom omzeilt de eigen DNS van de router de VPN-tunnel?

Clientopzoekingen volgen de tunnel, terwijl de eigen opzoekingen van de router via de WAN naar buiten gaan, en de firewallregel die het ene regelt, heeft geen invloed op het andere. De oorzaak is geen bug: een doorgestuurd verzoek en een verzoek dat de router zelf maakt, zijn twee afzonderlijke stromen, en elk wordt tegen een ander deel van de configuratie gematcht. Alleen de clienthelft vastleggen levert een zelfverzekerd antwoord over een pad dat de tweede helft nooit gebruikt. De oplossing is de resolver van de router bewust richten en daarna de twee paden apart testen.

Bij welke stroom de packetcapture eigenlijk hoort

Eén opzoeking omvat twee uitwisselingen. Een LAN-client stuurt een query naar de resolver van de router, en die komt binnen als doorgestuurd verkeer op de LAN-interface, zodat een beleidsroute of NAT-regel die voor doorgestuurde pakketten is geschreven, erbij kan passen. Daarna antwoordt de router uit de cache of, bij een misser, opent hij zijn eigen query naar een upstream-server.

Die tweede query heeft de router als bron en als eigen bestemming, en het platform kiest het pad uit een ander configuratieblok. Beide uitwisselingen dragen dezelfde naam, en geen van beide is een kopie van de andere. Een capture aan de LAN-kant bewijst dus waar het pakket van de client heen ging en zegt niets over het uitgaande pakket.

De praktische controle is beide kanten tegelijk te bekijken. Op de router: list de socket van de resolver op, bevraag die lokaal en leg de WAN-interface vast:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

Als de socketlijst een luisteraar toont die aan het loopback- of LAN-adres gebonden is, antwoordt de router lokaal in plaats van door te sturen naar een andere host. De capture laat dan zien of de resulterende upstream-query via de tunnelinterface of via de WAN naar buiten gaat, en dat is het antwoord dat de beleidsrouteregel nooit zou geven.

Waarom de beleidsroute de tweede query nooit ziet

Firewallregels worden geschreven tegen een interface, een bron, een bestemming en een poort, en ze worden geëvalueerd voor pakketten die door het apparaat gaan. Een query die de router zelf maakt, gaat nergens doorheen, omdat een lokaal proces hem rechtstreeks aan de routingtabel geeft. Beleidsrouting en NAT gelden daarom alleen voor het doorgestuurde pad, en juist daarom kan een regelset compleet lijken en toch de DNS van de router buiten de tunnel laten.

Dat onderscheid overleeft elke firmware-herschrijving omdat het uit het pakketpad volgt en niet uit een functie. Alles wat het apparaat voor zichzelf genereert, of het nu resolverqueries, tijdsynchronisatie, updatecontroles of toegang tot pakketspiegels zijn, is lokaal ontstaan en valt in dezelfde blinde vlek. Daarom bewijst een test vanaf een laptop niets over de router.

Waar een pfSense-resolver zijn eigen upstream-pad bepaalt

pfSense maakt de splitsing zichtbaar. Clientverkeer kan via beleidsrouting door een VPN-gateway gaan, terwijl het eigen verkeer van de firewall de uitgaande instelling van de resolver volgt in plaats van de LAN-regels. In de webinterface staat die instelling onder Services > DNS Resolver > Outgoing Network Interfaces, en de waarde ervan is de lijst met interfaces die de resolver voor upstream-queries mag gebruiken.

De tunnelinterface daar noemen, en alleen die interface, is wat de eigen opzoekingen van de router de tunnel laat volgen. Op de standaardwaarde gelaten kiest de resolver een uitgang uit de routingtabel, wat op een host met dubbele WAN of VPN vaak de WAN is.

Andere firmware toont dezelfde beslissing onder een ander label: een upstream-serverlijst die aan een bronadres is gebonden, een modus met alleen doorsturen, of een gedocumenteerd routebeleid. De instelling die je moet zoeken is altijd degene die een uitgang of een bron kiest voor lokaal gegenereerde queries. De referentie voor resolverconfiguratie documenteert die optie voor pfSense en is het lezen waard vóór de wijziging.

Kies het faalgedrag vóór de instelling

Als de tunnel valt, zijn twee gedragingen verdedigbaar: upstream-queries stoppen zodat er niets weglekt, of terugvallen op een goedgekeurde resolver op een bekend pad. Beide zijn beleid, en geen van beide is wat je standaard krijgt. Beslis welke het netwerk nodig heeft voordat je de interfacelijst aanraakt.

Sluiten bij falen is makkelijker te verdedigen, maar het maakt een tunnelstoring tot een naamresolutiestoring voor elk apparaat achter de router. Terugvallen houdt het kantoor bruikbaar, tegen de prijs van een upstream-uitwisseling buiten de tunnel die met opzet aanvaardbaar moet zijn en niet per ongeluk. Schrijf de keuze op, want de volgende persoon die een resolveradres buiten de VPN ziet, leest het als een lek tenzij een notitie iets anders zegt. Die notitie is wat een gedocumenteerde terugval onderscheidt van een onverklaarde vondst in de review van volgend kwartaal.

Twee gevallen compliceren de beslissing. Privénamen kunnen een interne resolver nodig hebben die de tunnel bereikt, en een browser of applicatie met eigen versleutelde DNS kan de router volledig omzeilen, dus de resolver die je hebt geconfigureerd is niet altijd degene die een bepaalde app gebruikt.

Test beide paden en houd de resultaten apart

Een browsergebaseerde DNS-test beantwoordt een smalle vraag: welke resolvers heeft die browser onder de omstandigheden van die test gebruikt. Hij inventariseert de apparaten op het netwerk niet en kan een query die de router voor zichzelf maakte niet zien. Behandel de uitvoer als één datapunt en niet als een audit.

Vraag vanaf een LAN-client de router om een openbare naam en daarna om een privénaam die alleen je interne zone zou moeten beantwoorden. Een fout alleen bij de tweede query wijst op naamdoorgifte en niet op de tunnel:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Breng dan de tunnel omlaag en herhaal beide queries. Geweigerde antwoorden betekenen dat de resolver bij falen sluit; een geslaagd antwoord wijst op een terugvalresolver en het pad dat die gebruikte. Vergelijk dat met de notitie die je hebt geschreven en met een capture op de WAN-interface uit dezelfde minuut.

Houd de waarnemingen apart in het verslag: de uitwisseling tussen client en router, de uitwisseling tussen router en upstream, en de configuratie die de tweede besliste. Een latere routingwijziging zal die tweede uitwisseling zonder waarschuwing gebruiken. Een antwoord dat van een andere plek dan het VPN-eindpunt komt, is op zichzelf geen lek; het wordt pas een lek als de configuratie dat pad per ongeluk heeft gekozen.