Hvorfor omgår routerens egen DNS VPN-tunnelen?

Klientoppslag følger tunnelen, mens routerens egne oppslag går ut via WAN, og brannmurregelen som styrer det ene, har ingen virkning på det andre. Årsaken er ikke en feil: en videresendt forespørsel og en forespørsel routeren lager selv, er to atskilte strømmer, og hver av dem matches mot en annen del av konfigurasjonen. Fanger du bare klienthalvdelen, får du et selvsikkert svar om en vei den andre halvdelen aldri bruker. Rettelsen er å peke resolveren til routeren bevisst, og deretter teste de to veiene hver for seg.

Hvilken strøm pakkefangsten egentlig tilhører

Ett oppslag innebærer to utvekslinger. En LAN-klient sender en forespørsel til routerens resolver, og den ankommer som videresendt trafikk på LAN-grensesnittet, slik at en policyrute eller NAT-regel skrevet for videresendte pakker kan matche den. Deretter svarer routeren fra hurtigbufferen eller, ved treffmangel, åpner sin egen forespørsel mot en oppstrømsserver.

Den andre forespørselen har routeren som kilde og som sin egen destinasjon, og plattformen velger veien dens fra en annen konfigurasjonsblokk. Begge utvekslingene bærer samme navn, og ingen av dem er en kopi av den andre. En fangst tatt på LAN-siden beviser derfor hvor klientens pakke gikk, og sier ingenting om pakken som går ut.

Den praktiske kontrollen er å overvåke begge sider samtidig. På routeren: list opp socketen til resolveren, spør den lokalt og fang WAN-grensesnittet:

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

Hvis socketlisten viser en lytter bundet til loopback- eller LAN-adressen, svarer routeren lokalt i stedet for å videresende til en annen vert. Fangsten viser da om den resulterende oppstrømsforespørselen går ut via tunnelgrensesnittet eller via WAN, og det er svaret policyruteregelen aldri ville ha gitt.

Hvorfor policyruten aldri ser den andre forespørselen

Brannmurregler skrives mot et grensesnitt, en kilde, en destinasjon og en port, og de vurderes for pakker som passerer gjennom boksen. En forespørsel routeren lager, passerer ikke gjennom noe, fordi en lokal prosess gir den rett til rutetabellen. Policyruteting og NAT gjelder derfor bare for den videresendte veien, og nettopp derfor kan et regelsett se komplett ut og likevel la routerens DNS bli stående utenfor tunnelen.

Denne forskjellen overlever hver fastvareomskriving fordi den følger av pakkens vei og ikke av en funksjon. Alt boksen lager for seg selv, enten det er resolverforespørsler, tidssynkronisering, oppdateringssjekker eller tilgang til pakkespeil, er lokalt oppstått og havner i samme blindsonen. Det er også derfor en test fra en bærbar PC ikke beviser noe om routeren.

Hvor pfSense-resolveren bestemmer sin egen oppstrømsvei

pfSense gjør delingen synlig. Klienttrafikk kan policyroutes gjennom en VPN-gateway, mens brannmurens egen trafikk følger resolverens utgående innstilling i stedet for LAN-reglene. I webgrensesnittet ligger den innstillingen under Services > DNS Resolver > Outgoing Network Interfaces, og verdien er listen over grensesnitt resolveren kan bruke til oppstrømsforespørsler.

Å navngi tunnelgrensesnittet der, og bare det grensesnittet, er det som får routerens egne oppslag til å følge tunnelen. Står det på standardverdien, velger resolveren en utgang fra rutetabellen, som på en vert med dobbel WAN eller VPN ofte er WAN.

Annen fastvare viser samme beslutning under en annen etikett: en liste over oppstrømsservere bundet til en kildeadresse, en modus med bare videresending eller en dokumentert rutepolicy. Innstillingen du skal lete etter, er alltid den som velger en utgang eller en kilde for lokalt genererte forespørsler. Referansen for resolverkonfigurasjon dokumenterer det alternativet for pfSense og er verdt å lese før endringen.

Velg feiloppførselen før innstillingen

Når tunnelen faller, er to oppførsler forsvarlige: stopp oppstrømsforespørsler slik at ingenting lekker, eller fall tilbake til en godkjent resolver på en kjent vei. Begge er policy, og ingen av dem er det du får som standard. Bestem hvilken nettverket trenger før du rører grensesnittlisten.

Å lukke ved feil er lettere å forsvare, men det gjør et tunnelutfall til et navneoppløsningsutfall for hver enhet bak routeren. Tilbakefallet holder kontoret brukbart, men mot at en oppstrømsutveksling utenfor tunnelen må være akseptabel med vilje og ikke ved et uhell. Skriv ned valget, for den neste personen som ser en resolveradresse utenfor VPN-en, vil lese det som en lekkasje med mindre et notat sier noe annet. Det notatet er det som skiller et dokumentert tilbakefall fra et uforklart funn i gjennomgangen neste kvartal.

To tilfeller kompliserer beslutningen. Private navn kan trenge en intern resolver som tunnelen når, og en nettleser eller app med egen kryptert DNS kan omgå routeren helt, så resolveren du konfigurerte, er ikke alltid den en gitt app bruker.

Test begge veiene og hold resultatene atskilt

En nettleserbasert DNS-test svarer på et smalt spørsmål: hvilke resolvere brukte den nettleseren under betingelsene i den testen. Den kartlegger ikke enhetene på nettverket og kan ikke se en forespørsel routeren laget for seg selv. Behandle utdataene som ett datapunkt og ikke som en revisjon.

Fra en LAN-klient: be routeren om et offentlig navn og deretter om et privat navn som bare din interne sone skal svare på. En feil bare på den andre forespørselen peker på navnevideresending og ikke på tunnelen:

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

Senk deretter tunnelen og gjenta begge forespørslene. Avviste svar betyr at resolveren lukker ved feil; et vellykket svar peker på en reserve-resolver og veien den brukte. Sammenlign det med notatet du skrev, og med en fangst på WAN-grensesnittet tatt i samme minutt.

Hold observasjonene atskilt i protokollen: utvekslingen mellom klient og router, utvekslingen mellom router og oppstrømsserver, og konfigurasjonen som avgjorde den andre. En senere rutingendring vil øve den andre utvekslingen uten varsel. Et svar som kommer fra et annet sted enn VPN-endepunktet, er ikke i seg selv en lekkasje; det blir først en lekkasje når konfigurasjonen valgte den veien ved et uhell.