Varför kringgår routerns egen DNS VPN-tunneln?

Klienternas uppslagningar följer tunneln, medan routerns egna uppslagningar går ut via WAN, och brandväggsregeln som styr den ena har ingen effekt på den andra. Orsaken är inte en bugg: en vidarebefordrad begäran och en begäran som routern själv skapar är två separata flöden, och var och en matchas mot en annan del av konfigurationen. Att bara fånga klienthalvan ger ett självsäkert svar om en väg som den andra halvan aldrig använder. Åtgärden är att medvetet peka routerns resolver och sedan testa de två vägarna var för sig.

Vilket flöde paketfångsten egentligen tillhör

En uppslagning innefattar två utbyten. En LAN-klient skickar en fråga till routerns resolver, och den anländer som vidarebefordrad trafik på LAN-gränssnittet, så en policyrutt eller NAT-regel skriven för vidarebefordrade paket kan matcha den. Därefter svarar routern från cachen eller, vid miss, öppnar sin egen fråga mot en uppströmsserver.

Den andra frågan har routern som källa och som sin egen destination, och plattformen väljer dess väg från ett annat konfigurationsblock. Båda utbytena bär samma namn, och ingen av dem är en kopia av den andra. En fångst tagen på LAN-sidan bevisar därför vart klientens paket tog vägen och säger ingenting om det utgående paketet.

Den praktiska kontrollen är att övervaka båda sidorna samtidigt. På routern: lista resolverns socket, fråga den lokalt och fånga WAN-gränssnittet:

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

Om socketlistan visar en lyssnare bunden till loopback- eller LAN-adressen svarar routern lokalt i stället för att vidarebefordra till en annan värd. Fångsten visar då om den resulterande uppströmsfrågan går ut via tunnelgränssnittet eller via WAN, och det är svaret som policyruttregeln aldrig skulle ha gett.

Varför policyrutten aldrig ser den andra frågan

Brandväggsregler skrivs mot ett gränssnitt, en källa, en destination och en port, och de utvärderas för paket som passerar genom enheten. En fråga som routern skapar passerar inte genom något, eftersom en lokal process lämnar den direkt till routingtabellen. Policyrouting och NAT gäller därför bara den vidarebefordrade vägen, och just därför kan en regeluppsättning se komplett ut och ändå lämna routerns DNS utanför tunneln.

Den skillnaden överlever varje firmware-omskrivning eftersom den följer av paketets väg och inte av en funktion. Allt enheten skapar åt sig själv, vare sig det är resolverfrågor, tidssynkronisering, uppdateringskontroller eller åtkomst till paketspeglar, har lokalt ursprung och hamnar i samma blinda fläck. Det är också därför ett test från en bärbar dator inte bevisar något om routern.

Var en pfSense-resolver bestämmer sin egen uppströmsväg

pfSense gör uppdelningen synlig. Klienttrafik kan policyrutas genom en VPN-gateway medan brandväggens egen trafik följer resolverns utgående inställning i stället för LAN-reglerna. I webbgränssnittet finns den inställningen under Services > DNS Resolver > Outgoing Network Interfaces, och dess värde är listan över gränssnitt som resolvern får använda för uppströmsfrågor.

Att namnge tunnelgränssnittet där, och bara det gränssnittet, är det som får routerns egna uppslagningar att följa tunneln. Lämnad på standardvärde väljer resolvern en utgång från routingtabellen, vilket på en värd med dubbel WAN eller VPN ofta är WAN.

Annan firmware visar samma beslut under en annan etikett: en lista över uppströmsservrar bunden till en källadress, ett läge med bara vidarebefordran eller en dokumenterad ruttpolicy. Inställningen att leta efter är alltid den som väljer en utgång eller en källa för lokalt skapade frågor. Referensen för resolverkonfiguration dokumenterar det alternativet för pfSense och är värd att läsa före ändringen.

Välj felbeteende före inställningen

När tunneln faller är två beteenden försvarbara: stoppa uppströmsfrågor så att ingenting läcker, eller falla tillbaka på en godkänd resolver på en känd väg. Båda är policy, och ingen av dem är det man får som standard. Bestäm vilken nätverket behöver innan du rör gränssnittslistan.

Att stänga vid fel är lättare att försvara, men det gör ett tunnelavbrott till ett namnupplösningsavbrott för varje enhet bakom routern. Återfallet håller kontoret användbart, men till priset av ett uppströmsutbyte utanför tunneln som måste vara acceptabelt med avsikt och inte av misstag. Skriv ner valet, för nästa person som ser en resolveradress utanför VPN:en kommer att läsa det som en läcka om inte en anteckning säger annat. Den anteckningen är det som skiljer ett dokumenterat återfall från ett oförklarat fynd i nästa kvartals genomgång.

Två fall komplicerar beslutet. Privata namn kan kräva en intern resolver som tunneln når, och en webbläsare eller app med egen krypterad DNS kan kringgå routern helt, så resolvern du konfigurerade är inte alltid den som en viss app använder.

Testa båda vägarna och håll resultaten åtskilda

Ett webbläsarbaserat DNS-test svarar på en smal fråga: vilka resolvers använde den webbläsaren under testets förhållanden. Det inventerar inte enheterna på nätverket och kan inte se en fråga som routern skapade åt sig själv. Behandla dess utdata som en datapunkt och inte som en revision.

Från en LAN-klient: be routern om ett offentligt namn och sedan om ett privat som bara din interna zon ska svara på. Ett fel bara på den andra frågan pekar på namnvidarebefordran och inte på tunneln:

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

Sänk sedan tunneln och upprepa båda frågorna. Avvisade svar betyder att resolvern stänger vid fel; ett lyckat svar pekar på en reservresolver och vägen den använde. Jämför det med anteckningen du skrev och med en fångst på WAN-gränssnittet tagen i samma minut.

Håll observationerna åtskilda i protokollet: utbytet mellan klient och router, utbytet mellan router och uppströmsserver och konfigurationen som avgjorde det andra. En senare routingändring kommer att utnyttja det andra utbytet utan varning. Ett svar som kommer från annan plats än VPN-slutpunkten är inte i sig en läcka; det blir en läcka först när konfigurationen valde den vägen av misstag.