Hvorfor omgår routerens egen DNS VPN-tunnelen?

Klientopslag følger tunnelen, mens routerens egne opslag forlader via WAN, og firewallreglen, der styrer det ene, har ingen virkning på det andet. Årsagen er ikke en fejl: en videresendt anmodning og en anmodning, som routeren selv opretter, er to adskilte strømme, og hver især matches mod en anden del af konfigurationen. Optager du kun klientsiden, får du et selvsikkert svar om en vej, som den anden halvdel aldrig bruger. Rettelsen er bevidst at pege routerens resolver og derefter teste de to veje hver for sig.

Hvilken strøm pakkeoptagelsen egentlig hører til

Ét opslag indebærer to udvekslinger. En LAN-klient sender en forespørgsel til routerens resolver, og den ankommer som videresendt trafik på LAN-interfacet, så en policyrute eller NAT-regel skrevet til videresendte pakker kan matche den. Derefter svarer routeren fra cachen eller åbner ved et miss sin egen forespørgsel til en opstrømsserver.

Den anden forespørgsel har routeren som kilde og som sin egen destination, og platformen vælger dens vej fra en anden konfigurationsblok. Begge udvekslinger bærer samme navn, og ingen af dem er en kopi af den anden. En optagelse taget på LAN-siden beviser derfor, hvor klientens pakke gik hen, og siger intet om den udgående pakke.

Den praktiske kontrol er at overvåge begge sider samtidig. På routeren: list resolverens socket, forespørg den lokalt, og optag WAN-interfacet:

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 at videresende til en anden vært. Optagelsen viser så, om den resulterende opstrømsforespørgsel forlader via tunnelinterfacet eller via WAN, og det er det svar, policyruten aldrig ville give.

Hvorfor policyruten aldrig ser den anden forespørgsel

Firewallregler skrives mod et interface, en kilde, en destination og en port, og de evalueres for pakker, der passerer gennem boksen. En forespørgsel, som routeren selv opretter, passerer ikke gennem noget, fordi en lokal proces giver den direkte til routingtabellen. Policyrouting og NAT gælder derfor kun for den videresendte vej, og netop derfor kan et regelsæt se komplet ud og alligevel efterlade routerens DNS uden for tunnelen.

Adskillelsen overlever enhver firmwareomskrivning, fordi den følger af pakkens vej og ikke af en funktion. Alt, hvad boksen opretter for sig selv, hvad enten det er resolverforespørgsler, tidssynkronisering, opdateringstjek eller adgang til pakkespejle, har lokal oprindelse og ender i samme blinde vinkel. Det er også derfor, en test fra en bærbar computer intet beviser om routeren.

Hvor en pfSense-resolver vælger sin egen opstrømsvej

pfSense gør opdelingen synlig. Klienttrafik kan policyroutes gennem en VPN-gateway, mens firewallens egen trafik følger resolverens udgående indstilling i stedet for LAN-reglerne. I webinterfacet findes den indstilling under Services > DNS Resolver > Outgoing Network Interfaces, og dens værdi er listen over interfaces, som resolveren må bruge til opstrømsforespørgsler.

At navngive tunnelinterfacet der, og kun det interface, er det, der får routerens egne opslag til at følge tunnelen. Efterladt på standard vælger resolveren en udgang fra routingtabellen, som på en vært med dobbelt WAN eller VPN ofte er WAN.

Anden firmware blotlægger samme beslutning under en anden etiket: en liste over opstrømsservere bundet til en kildeadresse, en tilstand med kun videresendelse eller en dokumenteret routepolitik. Den indstilling, du skal lede efter, er altid den, der vælger en udgang eller en kilde til lokalt oprettede forespørgsler. Reference for resolverkonfiguration dokumenterer den valgmulighed for pfSense og er værd at læse før ændringen.

Vælg fejlfunktionen før indstillingen

Når tunnelen falder, er to funktioner forsvarlige: stop opstrømsforespørgsler, så intet lækker, eller fald tilbage til en godkendt resolver på en kendt vej. Begge er politik, og ingen af dem er det, du får som standard. Beslut, hvilken netværket har brug for, før du rører interfacelisten.

Lukket ved fejl er lettere at forsvare, men det gør et tunneludfald til et navneopløsningsudfald for hver enhed bag routeren. Tilbagefald holder kontoret brugbart, men på bekostning af en opstrømsudveksling uden for tunnelen, som må være acceptabel med vilje og ikke ved et uheld. Skriv valget ned, for den næste person, der ser en resolveradresse uden for VPN'en, vil læse det som en lækage, medmindre en note siger andet. Den note er det, der skiller et dokumenteret tilbagefald fra et uforklaret fund i næste kvartals gennemgang.

To tilfælde komplicerer beslutningen. Private navne kan kræve en intern resolver, som tunnelen kan nå, og en browser eller et program med egen krypteret DNS kan helt omgå routeren, så den resolver, du konfigurerede, er ikke altid den, en given app bruger.

Test begge veje og hold resultaterne adskilt

En browserbaseret DNS-test besvarer et snævert spørgsmål: hvilke resolvere brugte den browser under den tests betingelser. Den opgør ikke enhederne på netværket og kan ikke se en forespørgsel, som routeren oprettede for sig selv. Behandl dens output som ét datapunkt og ikke som en revision.

Fra en LAN-klient: bed routeren om et offentligt navn og derefter om et privat, som kun din interne zone bør svare på. En fejl på kun den anden forespørgsel peger på navnevideresendelse og ikke på tunnelen:

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

Sænk derefter tunnelen og gentag begge forespørgsler. Afviste svar betyder, at resolveren er lukket ved fejl; et vellykket svar peger på en reserve-resolver og den vej, den brugte. Sammenlign det med den note, du skrev, og med en optagelse på WAN-interfacet taget i samme minut.

Hold observationerne adskilt i protokollen: udvekslingen mellem klient og router, udvekslingen mellem router og opstrømsserver og den konfiguration, der afgjorde den anden. En senere routingændring vil øve den anden udveksling uden varsel. Et svar, der kommer fra et andet sted end VPN-endepunktet, er ikke i sig selv en lækage; det bliver først en lækage, når konfigurationen valgte den vej ved et uheld.