Zakaj lastni DNS usmerjevalnika obide tunel VPN?
Poizvedba odjemalca in poizvedba usmerjevalnika navzgor sta dva različna toka. Zajemite oba, izberite izhod razreševalnika in nato preizkusite primer izpada tunela.
Poizvedbe odjemalcev sledijo tunelu, medtem ko lastne poizvedbe usmerjevalnika odhajajo skozi WAN, in pravilo požarnega zidu, ki ureja eno, ne vpliva na drugo. Vzrok ni napaka: posredovana zahteva in zahteva, ki jo usmerjevalnik ustvari sam, sta dva ločena toka, in vsak se primerja z drugim delom konfiguracije. Če zajamete le odjemalčevo polovico, dobite samozavesten odgovor o poti, ki je druga polovica nikoli ne uporabi. Popravek je zavestno usmeriti razreševalnik usmerjevalnika in nato obe poti preizkusiti ločeno.
Kateremu toku dejansko pripada zajem paketov
Ena poizvedba vključuje dve izmenjavi. Odjemalec v LAN pošlje poizvedbo razreševalniku usmerjevalnika, ta pa prispe kot posredovani promet na vmesniku LAN, zato jo pravilo političnega usmerjanja ali NAT, napisano za posredovane pakete, lahko ujame. Nato usmerjevalnik odgovori iz predpomnilnika ali ob zgrešitvi odpre svojo poizvedbo do strežnika višje.
Ta druga poizvedba ima usmerjevalnik kot vir in kot svoj cilj, platforma pa ji izbere pot iz drugega bloka konfiguracije. Obe izmenjavi nosita isto ime in nobena ni kopija druge. Zato zajem, posnet na strani LAN, dokazuje, kam je šel odjemalčev paket, in ne pove ničesar o odhodnem paketu.
Praktično preverjanje je opazovanje obeh strani hkrati. Na usmerjevalniku izpišite vtičnico razreševalnika, ga vprašajte lokalno in zajemite vmesnik WAN:
sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53Če seznam vtičnic pokaže poslušalca, vezanega na naslov loopback ali LAN, usmerjevalnik odgovarja lokalno, namesto da bi posredoval drugemu gostitelju. Zajem nato pokaže, ali dobljena poizvedba navzgor odhaja skozi vmesnik tunela ali skozi WAN, in to je odgovor, ki ga pravilo političnega usmerjanja ne bi nikoli dalo.
Zakaj politično usmerjanje nikoli ne vidi druge poizvedbe
Pravila požarnega zidu se pišejo za vmesnik, vir, cilj in vrata, in se ocenjujejo za pakete, ki gredo skozi napravo. Poizvedba, ki jo ustvari usmerjevalnik, ne gre skozi nič, ker jo lokalni proces preda neposredno usmerjevalni tabeli. Politično usmerjanje in NAT zato veljata le za posredovano pot, in prav zato je lahko nabor pravil videti popoln, a DNS usmerjevalnika vseeno pusti zunaj tunela.
Ta razlika preživi vsako prepisovanje vdelane programske opreme, ker izhaja iz poti paketa, ne iz funkcije. Vse, kar naprava ustvari zase, naj bodo to poizvedbe razreševalnika, sinhronizacija časa, preverjanja posodobitev ali dostop do zrcal paketov, je lokalnega izvora in pade v isto slepo pego. Zato tudi preizkus s prenosnika ničesar ne dokaže o usmerjevalniku.
Kje razreševalnik pfSense odloči o svoji poti navzgor
pfSense naredi delitev vidno. Odjemalčev promet se lahko usmerja politično skozi prehod VPN, medtem ko lastni promet požarnega zidu sledi izhodni nastavitvi razreševalnika namesto pravilom LAN. V spletnem vmesniku je ta nastavitev pod Services > DNS Resolver > Outgoing Network Interfaces, njena vrednost pa je seznam vmesnikov, ki jih razreševalnik sme uporabiti za poizvedbe navzgor.
Navesti tam vmesnik tunela, in samo ta vmesnik, je tisto, kar doseže, da lastne poizvedbe usmerjevalnika sledijo tunelu. Če ostane privzeto, razreševalnik izbere izhod iz usmerjevalne tabele, kar je na gostitelju z dvema WAN ali VPN pogosto WAN.
Druga vdelana programska oprema razkrije isto odločitev pod drugo oznako: seznam strežnikov navzgor, vezan na naslov vira, način samo posredovanja ali dokumentirana usmerjevalna politika. Nastavitev, ki jo je treba iskati, je vedno tista, ki izbere izhod ali vir za lokalno ustvarjene poizvedbe. Referenca za konfiguracijo razreševalnika dokumentira to možnost za pfSense in jo je vredno prebrati pred spremembo.
Izberite vedenje ob napaki pred nastavitvijo
Ko tunel pade, sta dve vedenji branljivi: ustaviti poizvedbe navzgor, da nič ne uide, ali se vrniti na odobreni razreševalnik po znani poti. Oboje je politika in nobeno ni tisto, kar dobite privzeto. Odločite se, katero omrežje potrebuje, preden se dotaknete seznama vmesnikov.
Zaprtje ob napaki je lažje braniti, vendar izpad tunela spremeni v izpad razreševanja imen za vsako napravo za usmerjevalnikom. Vrnitev ohrani pisarno uporabno, a za ceno izmenjave navzgor zunaj tunela, ki mora biti sprejemljiva namenoma in ne po naključju. Zapišite izbiro, ker bo naslednja oseba, ki bo videla naslov razreševalnika zunaj VPN, to prebrala kot uhajanje, razen če opomba ne pove drugače. Ta opomba je tisto, kar loči dokumentirano vrnitev od nerazložene najdbe v pregledu naslednjega četrtletja.
Dva primera zapletata odločitev. Zasebna imena lahko potrebujejo notranji razreševalnik, do katerega tunel doseže, brskalnik ali aplikacija z lastnim šifriranim DNS pa lahko usmerjevalnik povsem obide, zato konfigurirani razreševalnik ni vedno tisti, ki ga uporablja določena aplikacija.
Preizkusite obe poti in rezultate hranite ločeno
Preizkus DNS v brskalniku odgovori na ozko vprašanje: katere razreševalnike je uporabil ta brskalnik v pogojih tega preizkusa. Ne popisuje naprav v omrežju in ne vidi poizvedbe, ki jo je usmerjevalnik ustvaril zase. Njegov izhod obravnavajte kot eno podatkovno točko in ne kot revizijo.
Z odjemalca v LAN vprašajte usmerjevalnik za javno ime in nato za zasebno, na katero bi morala odgovarjati le vaša notranja cona. Neuspeh samo pri drugi poizvedbi kaže na posredovanje imen in ne na tunel:
dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lanNato spustite tunel in ponovite obe poizvedbi. Zavrnjeni odgovori pomenijo, da se razreševalnik ob napaki zapre; uspešen odgovor kaže na nadomestni razreševalnik in pot, ki jo je uporabil. Primerjajte to z opombo, ki ste jo napisali, in z zajemom na vmesniku WAN, posnetim v isti minuti.
Opažanja hranite ločeno v zapisu: izmenjavo odjemalca z usmerjevalnikom, izmenjavo usmerjevalnika s strežnikom navzgor in konfiguracijo, ki je odločila o drugi. Kasnejša sprememba usmerjanja bo to drugo izmenjavo izvedla brez opozorila. Odgovor, ki prispe od drugod kot s končne točke VPN, sam po sebi ni uhajanje; uhajanje postane le, ko je konfiguracija to pot izbrala po naključju.