Miks ruuteri enda DNS möödub VPN-tunnelist?

Kliendi päringud järgivad tunnelit, samal ajal kui ruuteri enda päringud väljuvad WAN-i kaudu, ja tulemüüri reegel, mis reguleerib ühte, ei mõjuta teist. Põhjus ei ole viga: edastatud taotlus ja taotlus, mille ruuter ise loob, on kaks eraldi voogu ja kumbki sobitatakse konfiguratsiooni erineva osaga. Ainult kliendipoole jäädvustamine annab enesekindla vastuse tee kohta, mida teine pool kunagi ei kasuta. Parandus on suunata ruuteri resolver teadlikult ja seejärel testida mõlemat teed eraldi.

Millisele voolule paketijäädvustus tegelikult kuulub

Üks päring hõlmab kahte vahetust. LAN-klient saadab päringu ruuteri resolverile ja see saabub LAN-liidesele edastatud liiklusena, nii et edastatud pakettide jaoks kirjutatud poliitikamarsruut või NAT-reegel võib selle sobitada. Seejärel vastab ruuter vahemälust või avab vahelejäägi korral oma päringu ülesvoolu serverile.

Sellel teisel päringul on allikaks ruuter ise ja sihtkohaks samuti tema ise, ning platvorm valib selle tee teisest konfiguratsiooniplokist. Mõlemad vahetused kannavad sama nime ja kumbki ei ole teise koopia. Seetõttu tõestab LAN-poolel tehtud jäädvustus, kuhu kliendi pakett läks, ja ei ütle väljuva paketi kohta midagi.

Praktiline kontroll on jälgida mõlemat poolt korraga. Ruuteris loetle resolveri sokkel, päri seda lokaalselt ja jäädvusta WAN-liides:

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

Kui soklite loend näitab loopback- või LAN-aadressiga seotud kuulajat, vastab ruuter lokaalselt, mitte ei edasta teisele hostile. Seejärel näitab jäädvustus, kas sellest tulenev ülesvoolu päring väljub tunneli liidese või WAN-i kaudu, ja see on vastus, mida poliitikamarsruudi reegel kunagi ei annaks.

Miks poliitikamarsruut teist päringut kunagi ei näe

Tulemüüri reeglid kirjutatakse liidese, allika, sihtkoha ja pordi kohta ning neid hinnatakse pakettide puhul, mis läbivad seadet. Päring, mille ruuter ise loob, ei läbi mitte midagi, sest lokaalne protsess annab selle otse marsruutimistabelile. Poliitikamarsruutimine ja NAT kehtivad seetõttu ainult edastatud teele ja just seepärast võib reeglistik tunduda täielik ning jätta ruuteri DNS-i siiski tunnelist välja.

See eristus püsib pärast iga püsivara ümberkirjutust, sest see tuleneb paketi teest, mitte funktsioonist. Kõik, mida seade ise loob, olgu resolveri päringud, aja sünkroonimine, värskenduste kontrollid või paketipeeglite kasutamine, on lokaalse päritoluga ja satub samasse pimedasse alasse. Seepärast ei tõesta sülearvutist tehtud test ruuteri kohta midagi.

Kus pfSense'i resolver oma ülesvoolu tee üle otsustab

pfSense teeb selle jaotuse nähtavaks. Kliendiliiklust saab poliitikamarsruudiga VPN-lüüsist läbi suunata, samal ajal kui tulemüüri enda liiklus järgib resolveri väljamineva seade asetust, mitte LAN-reegleid. Veebiliideses asub see säte Services > DNS Resolver > Outgoing Network Interfaces all ja selle väärtus on liideste loend, mida resolver võib ülesvoolu päringuteks kasutada.

Tunneliliidese seal nimetamine ja ainult selle liidese nimetamine on see, mis paneb ruuteri enda päringud tunnelit järgima. Vaikeväärtusele jäetuna valib resolver väljundi marsruutimistabelist, mis kahe WAN-iga või VPN-iga hostis on sageli WAN.

Teised püsivarad toovad sama otsuse esile teise sildi all: allikaaadressiga seotud ülesvoolu serverite loend, ainult edastamise režiim või dokumenteeritud marsruudipoliitika. Säte, mida otsida, on alati see, mis valib lokaalselt loodud päringutele väljundi või allika. Resolveri konfiguratsiooni viide dokumenteerib selle valiku pfSense'i jaoks ja tasub enne muudatust läbi lugeda.

Vali rikkekäitumine enne sätet

Kui tunnel langeb, on kaks käitumist kaitstavad: peatada ülesvoolu päringud, et midagi ei lekitseks, või langeda tagasi kinnitatud resolverile teadaoleval teel. Mõlemad on poliitikad ja kumbki ei ole see, mille vaikimisi saad. Otsusta, millist võrk vajab, enne kui liideste loendit puudutad.

Rikke korral sulgemine on kergem kaitsta, kuid muudab tunneli katkemise nimelahenduse katkemiseks iga ruuteri taga oleva seadme jaoks. Tagasilangus hoiab kontori kasutatavana, kuid tunnelist väljaspool toimuva ülesvoolu vahetuse hinnaga, mis peab olema vastuvõetav meelega, mitte kogemata. Kirjuta valik üles, sest järgmine inimene, kes näeb VPN-ist väljaspool resolveri aadressi, loeb seda lekkeks, kui märkus ei ütle teisiti. Just see märkus eristab dokumenteeritud tagasilangust seletamata leiust järgmise kvartali ülevaates.

Otsust teeb keerulisemaks kaks juhtu. Privaatsed nimed võivad vajada sisemist resolverit, milleni tunnel ulatub, ja brauser või rakendus oma krüpteeritud DNS-iga võib ruuterist täiesti mööda minna, nii et konfigureeritud resolver ei ole alati see, mida antud rakendus kasutab.

Testi mõlemat teed ja hoia tulemused lahus

Brauseripõhine DNS-test vastab kitsale küsimusele: milliseid resolvereid see brauser selle testi tingimustes kasutas. See ei loetle võrgu seadmeid ega näe päringut, mille ruuter enda jaoks lõi. Käsitle selle väljundit ühe andmepunktina, mitte auditina.

LAN-kliendist küsi ruuterilt avalikku nime ja seejärel privaatset, millele peaks vastama ainult sinu sisemine tsoon. Ebaõnnestumine ainult teisel päringul viitab nimede edastamisele, mitte tunnelile:

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

Seejärel lase tunnel alla ja korda mõlemat päringut. Keeldutud vastused tähendavad, et resolver sulgub rikke korral; edukas vastus viitab varuresolverile ja selle kasutatud teele. Võrdle seda kirjutatud märkusega ja samal minutil WAN-liidesel tehtud jäädvustusega.

Hoia vaatlused protokollis lahus: kliendi ja ruuteri vahetus, ruuteri ja ülesvoolu serveri vahetus ning konfiguratsioon, mis otsustas teise. Hilisem marsruudimuudatus rakendab seda teist vahetust ilma hoiatuseta. Vastus, mis saabub mujalt kui VPN-i lõpp-punkt, ei ole iseenesest leke; lekkeks saab see alles siis, kui konfiguratsioon valis selle tee kogemata.