Kvifor omgår den eigen DNS-en til ruteren VPN-tunnelen?

Klientoppslag følgjer tunnelen, medan rutarens eigne oppslag går ut via WAN, og brannmurregelen som styrer det eine, har inga verknad på det andre. Årsaka er ikkje ein feil: ein vidaresend førespurnad og ein førespurnad rutaren lagar sjølv, er to åtskilde straumar, og kvar av dei blir jamført med ein annan del av konfigurasjonen. Fangar du berre klienthalvdelen, får du eit sjølvsikkert svar om ein veg den andre halvdelen aldri brukar. Rettinga er å peike løysaren til rutaren med vilje, og deretter teste dei to vegane kvar for seg.

Kva straum pakkefangsten eigentleg høyrer til

Eitt oppslag inneber to utvekslingar. Ein LAN-klient sender ein førespurnad til løysaren til rutaren, og han kjem inn som vidaresend trafikk på LAN-grensesnittet, slik at ei policyrute eller NAT-regel skriven for vidaresende pakkar kan matche han. Deretter svarar rutaren frå hurtigbufferen eller, ved treffmangel, opnar sin eigen førespurnad mot ein oppstraumsserver.

Den andre førespurnaden har rutaren som kjelde og som sin eigen destinasjon, og plattformen vel vegen hans frå ein annan konfigurasjonsblokk. Begge utvekslingane ber same namn, og ingen av dei er ein kopi av den andre. Ein fangst teken på LAN-sida provar derfor kvar pakken til klienten gjekk, og seier ingenting om pakken som går ut.

Den praktiske kontrollen er å overvake begge sider samstundes. På rutaren: list opp socketen til løysaren, spør han lokalt og fang WAN-grensesnittet:

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

Viss socketlista viser ein lyttar bunden til loopback- eller LAN-adressa, svarar rutaren lokalt i staden for å vidaresende til ein annan vert. Fangsten viser då om den resulterande oppstraumsførespurnaden går ut via tunnelgrensesnittet eller via WAN, og det er svaret policyruteregelen aldri ville ha gjeve.

Kvifor policyruta aldri ser den andre førespurnaden

Brannmurreglar blir skrivne mot eit grensesnitt, ei kjelde, ein destinasjon og ein port, og dei blir vurderte for pakkar som passerer gjennom boksen. Ein førespurnad rutaren lagar, passerer ikkje gjennom noko, fordi ein lokal prosess gir han rett til rutetabellen. Policyruteting og NAT gjeld derfor berre for den vidaresende vegen, og nettopp derfor kan eit regelsett sjå komplett ut og likevel la DNS-en til rutaren bli ståande utanfor tunnelen.

Denne skilnaden overlever kvar fastvareomskriving fordi han følgjer av vegen til pakken og ikkje av ein funksjon. Alt boksen lagar for seg sjølv, anten det er løysarførespurnader, tidssynkronisering, oppdateringssjekkar eller tilgang til pakkespegel, er lokalt oppstått og hamnar i same blindsona. Det er også derfor ein test frå ein berbar PC ikkje provar noko om rutaren.

Kvar pfSense-løysaren bestemmer sin eigen oppstraumsveg

pfSense gjer delinga synleg. Klienttrafikk kan policyrutast gjennom ein VPN-gateway, medan den eigne trafikken til brannmuren følgjer den utgåande innstillinga til løysaren i staden for LAN-reglane. I webgrensesnittet ligg den innstillinga under Services > DNS Resolver > Outgoing Network Interfaces, og verdien er lista over grensesnitt løysaren kan bruke til oppstraumsførespurnader.

Å namngje tunnelgrensesnittet der, og berre det grensesnittet, er det som får dei eigne oppslaga til rutaren til å følgje tunnelen. Står det på standardverdien, vel løysaren ein utgang frå rutetabellen, som på ein vert med dobbel WAN eller VPN ofte er WAN.

Annan fastvare viser same avgjerd under ein annan etikett: ei liste over oppstraumsservarar bunden til ei kjeldeadresse, ein modus med berre vidaresending eller ein dokumentert rutepolicy. Innstillinga du skal leite etter, er alltid den som vel ein utgang eller ei kjelde for lokalt genererte førespurnader. Referansen for løysarkonfigurasjon dokumenterer det alternativet for pfSense og er verdt å lese før endringa.

Vel feilåtferd før innstillinga

Når tunnelen fell, er to åtferder forsvarlege: stogge oppstraumsførespurnader slik at ingenting lek, eller falle tilbake til ein godkjend løysar på ein kjend veg. Begge er policy, og ingen av dei er det du får som standard. Bestem kva nettverket treng før du rører grensesnittlista.

Å lukke ved feil er lettare å forsvare, men det gjer eit tunnelutfall til eit namneoppløysingsutfall for kvar eining bak rutaren. Tilbakefallet held kontoret brukbart, men mot at ei oppstraumsutveksling utanfor tunnelen må vere akseptabel med vilje og ikkje ved eit uhell. Skriv ned valet, for den neste personen som ser ei løysaradresse utanfor VPN-en, vil lese det som ein lekkasje med mindre eit notat seier noko anna. Det notatet er det som skil eit dokumentert tilbakefall frå eit uforklart funn i gjennomgangen neste kvartal.

To tilfelle kompliserer avgjerda. Private namn kan trenge ein intern løysar som tunnelen når, og ein nettlesar eller app med eigen kryptert DNS kan omgå rutaren heilt, så løysaren du konfigurerte, er ikkje alltid den ein gjeven app brukar.

Test begge vegane og hald resultata åtskilde

Ein nettlesarbasert DNS-test svarar på eit smalt spørsmål: kva løysarar brukte den nettlesaren under vilkåra i den testen. Han kartlegg ikkje einingane på nettverket og kan ikkje sjå ein førespurnad rutaren laga for seg sjølv. Sjå på utdataene som eitt datapunkt og ikkje som ein revisjon.

Frå ein LAN-klient: be rutaren om eit offentleg namn og deretter om eit privat namn som berre den interne sona di skal svare på. Ein feil berre på den andre førespurnaden peikar på namnevidaresending og ikkje på tunnelen:

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

Senk deretter tunnelen og repetér begge førespurnadene. Avviste svar betyr at løysaren lukkar ved feil; eit vellukka svar peikar på ein reserve-løysar og vegen han brukte. Samanlikn det med notatet du skreiv, og med ein fangst på WAN-grensesnittet teken i same minutt.

Hald observasjonane åtskilde i protokollen: utvekslinga mellom klient og ruter, utvekslinga mellom ruter og oppstraumsserver, og konfigurasjonen som avgjorde den andre. Ei seinare rutingendring vil øve den andre utvekslinga utan varsel. Eit svar som kjem frå ein annan stad enn VPN-endepunktet, er ikkje i seg sjølv ein lekkasje; det blir først ein lekkasje når konfigurasjonen valde den vegen ved eit uhell.