Miért kerüli meg a router saját DNS-e a VPN-alagutat?

A kliensek lekérdezései az alagutat követik, míg a router saját lekérdezései a WAN felé hagyják el a hálózatot, és a tűzfalszabály, amely az egyiket szabályozza, nincs hatással a másikra. Az ok nem hiba: a továbbított kérés és a router által maga generált kérés két külön folyam, és mindegyiket a konfiguráció más részével vetik össze. Ha csak a kliens felét rögzíti, magabiztos választ kap egy olyan útvonalról, amelyet a második fél soha nem használ. A javítás az, hogy a router feloldóját szándékosan átirányítsa, majd a két útvonalat külön tesztelje.

Melyik folyamhoz tartozik valójában a csomagrögzítés

Egy lekérdezés két cserét tartalmaz. Egy LAN-kliens lekérdezést küld a router feloldójának, és az továbbított forgalomként érkezik a LAN-interfészre, így a továbbított csomagokra írt házirend-útvonal vagy NAT-szabály egyezhet vele. Ezután a router a gyorsítótárból válaszol, vagy találat hiányában saját lekérdezést nyit egy felfelé irányuló kiszolgáló felé.

A második lekérdezés forrása maga a router, és a célja is ő maga, a platform pedig egy másik konfigurációs blokkból választja ki az útvonalát. Mindkét csere ugyanazt a nevet viseli, és egyik sem a másik másolata. Ezért a LAN oldalán vett rögzítés bizonyítja, hová ment a kliens csomagja, és semmit nem mond a kimenő csomagról.

A gyakorlati ellenőrzés az, hogy egyszerre figyeli mindkét oldalt. A routeren listázza a feloldó socketjét, kérdezze le helyben, és rögzítse a WAN-interfészt:

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

Ha a socketlista a loopback vagy a LAN címhez kötött figyelőt mutat, a router helyben válaszol, ahelyett hogy továbbítana egy másik gazdagépnek. A rögzítés ekkor megmutatja, hogy a keletkező felfelé irányuló lekérdezés az alagút interfészén vagy a WAN-on keresztül lép-e ki, és ez az a válasz, amelyet a házirend-útvonal szabály soha nem adott volna meg.

Miért nem látja soha a házirend-útvonal a második lekérdezést

A tűzfalszabályokat interfész, forrás, cél és port szerint írják, és az eszközön áthaladó csomagokra értékelik ki őket. A router által létrehozott lekérdezés semmin sem halad át, mert egy helyi folyamat közvetlenül a forgalomirányító táblának adja át. Házirend-alapú forgalomirányítás és NAT ezért csak a továbbított útvonalra vonatkoznak, és éppen ezért tűnhet egy szabálykészlet teljesnek, miközben a router DNS-e mégis az alagúton kívül marad.

Ez a megkülönböztetés minden firmware-újraírást túlél, mert a csomag útvonalából következik, nem egy funkcióból. Minden, amit az eszköz magának létrehoz, legyen az feloldó-lekérdezés, időszinkronizálás, frissítésellenőrzés vagy csomagtükör-hozzáférés, helyi eredetű, és ugyanabba a vakfoltba esik. Ezért nem bizonyít semmit a routerről egy laptopról indított teszt.

Hol dönti el a pfSense feloldója a saját felfelé irányuló útvonalát

A pfSense láthatóvá teszi a szétválasztást. A kliensforgalom házirend-útvonalon haladhat át egy VPN-átjárón, miközben a tűzfal saját forgalma a feloldó kimenő beállítását követi a LAN-szabályok helyett. A webes felületen ez a beállítás a Services > DNS Resolver > Outgoing Network Interfaces alatt található, értéke pedig azon interfészek listája, amelyeket a feloldó a felfelé irányuló lekérdezésekhez használhat.

Az alagút interfészének megnevezése ott, és csak azé az interfészé, az, ami a router saját lekérdezéseit az alagút után vezeti. Alapértelmezésen hagyva a feloldó a forgalomirányító táblából választ kimenetet, ami két WAN-nal vagy VPN-nel rendelkező gazdagépen gyakran a WAN.

Más firmware-ek ugyanezt a döntést más címke alatt teszik közzé: forrás-címhez kötött felfelé irányuló kiszolgálólista, csak továbbító mód, vagy dokumentált útvonalházirend. A keresendő beállítás mindig az, amely a helyben létrehozott lekérdezésekhez kimenetet vagy forrást választ. A feloldó konfigurációjának referenciája dokumentálja ezt a lehetőséget a pfSense-hez, és érdemes elolvasni a változtatás előtt.

Válassza ki a hiba viselkedését a beállítás előtt

Amikor az alagút leesik, két viselkedés védhető: leállítani a felfelé irányuló lekérdezéseket, hogy semmi ne szivárogjon, vagy visszaesni egy jóváhagyott feloldóra egy ismert útvonalon. Mindkettő házirend, és egyik sem az, amit alapértelmezésben kap. Döntse el, melyikre van szüksége a hálózatnak, mielőtt hozzányúl az interfészlistához.

A hiba esetén való lezárás könnyebben védhető, de az alagút kiesését névfeloldási kieséssé teszi a router mögötti minden eszköz számára. A visszaesés használhatóan tartja az irodát, de az alagúton kívüli felfelé irányuló csere árán, amelynek szándékosan elfogadhatónak kell lennie, nem véletlenül. Írja le a választást, mert a következő ember, aki a VPN-en kívül feloldó-címet lát, szivárgásként fogja olvasni, hacsak egy megjegyzés nem mond mást. Ez a megjegyzés választja el a dokumentált visszaesést a következő negyedév értékelésében szereplő megmagyarázatlan lelettől.

Két eset bonyolítja a döntést. A privát nevekhez olyan belső feloldóra lehet szükség, amelyet az alagút elér, és egy saját titkosított DNS-sel rendelkező böngésző vagy alkalmazás teljesen megkerülheti a routert, így a beállított feloldó nem mindig az, amelyet egy adott alkalmazás használ.

Tesztelje mindkét útvonalat, és tartsa külön az eredményeket

A böngészőalapú DNS-teszt szűk kérdésre válaszol: mely feloldókat használta az a böngésző, az adott teszt körülményei között. Nem veszi számba a hálózat eszközeit, és nem látja azt a lekérdezést, amelyet a router magának generált. Kezelje a kimenetét egyetlen adatpontként, nem auditként.

Egy LAN-kliensről kérjen a routertől egy nyilvános nevet, majd egy privátot, amelyre csak a belső zónájának kellene válaszolnia. A csak a második lekérdezésnél jelentkező hiba névtovábbításra utal, nem az alagútra:

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

Ezután ejtse le az alagutat, és ismételje meg mindkét lekérdezést. Az elutasított válaszok azt jelentik, hogy a feloldó hiba esetén lezár; a sikeres válasz visszaesési feloldóra és az általa használt útvonalra utal. Hasonlítsa össze ezt a leírt megjegyzéssel és egy ugyanabban a percben a WAN-interfészen vett rögzítéssel.

Tartsa külön a megfigyeléseket a feljegyzésben: a kliens és a router közötti cserét, a router és a felfelé irányuló kiszolgáló közötti cserét, és azt a konfigurációt, amely a másodikról döntött. Egy későbbi forgalomirányítási változás figyelmeztetés nélkül gyakorolja majd ezt a második cserét. Az a válasz, amely nem a VPN végpontjától érkezik, önmagában nem szivárgás; csak akkor válik szivárgássá, ha a konfiguráció véletlenül azt az útvonalat választotta.