Proč vlastní DNS routeru obchází VPN tunel?

Klientské dotazy jdou přes tunel, zatímco vlastní dotazy routeru odcházejí přes WAN, a pravidlo firewallu, které řídí jedno, nemá na druhé žádný vliv. Příčina není chyba: přesměrovaný požadavek a požadavek, který router vytvoří sám, jsou dva oddělené toky a každý se porovnává s jinou částí konfigurace. Zachytíte-li jen klientskou polovinu, dostanete sebejistou odpověď o cestě, kterou druhá polovina nikdy nepoužívá. Náprava spočívá v tom, že resolver routeru vědomě nasměrujete, a potom obě cesty otestujete odděleně.

Ke kterému toku zachycená komunikace vlastně patří

Jeden dotaz zahrnuje dvě výměny. Klient v LAN pošle dotaz resolveru routeru a ten dorazí jako přesměrovaný provoz na rozhraní LAN, takže jej pravidlo policy routingu nebo NAT napsané pro přesměrované pakety může zachytit. Poté router odpoví z cache, nebo při minutí otevře vlastní dotaz na nadřazený server.

Druhý dotaz má jako zdroj router a jako cíl jeho samotného a platforma mu vybírá cestu z jiného bloku konfigurace. Obě výměny nesou stejné jméno a ani jedna není kopií té druhé. Zachycení pořízené na straně LAN proto dokazuje, kam paket klienta odešel, a o odchozím paketu neříká nic.

Praktická kontrola spočívá v tom, že sledujete obě strany současně. Na routeru vypište socket resolveru, zeptejte se ho lokálně a zachyťte rozhraní WAN:

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

Pokud seznam socketů ukáže posluchače navázaného na adresu loopback nebo LAN, router odpovídá lokálně, místo aby přeposílal jinému hostiteli. Zachycení pak ukáže, zda výsledný dotaz nahoru odchází přes rozhraní tunelu, nebo přes WAN, což je odpověď, kterou pravidlo policy routingu nikdy nedalo.

Proč policy routing druhý dotaz nikdy nevidí

Pravidla firewallu se píší pro rozhraní, zdroj, cíl a port a vyhodnocují se pro pakety, které procházejí zařízením. Dotaz, který router vytvoří, neprochází ničím, protože ho lokální proces předá přímo směrovací tabulce. Policy routing a NAT se proto týkají jen přesměrované cesty, a právě proto může sada pravidel vypadat úplně, a přesto nechat DNS routeru mimo tunel.

Toto rozlišení přežívá každé přepsání firmwaru, protože vyplývá z cesty paketu, nikoli z funkce. Vše, co zařízení vytvoří pro sebe, ať už dotazy resolveru, synchronizace času, kontroly aktualizací nebo přístup ke zrcadlům balíčků, má lokální původ a padá do stejného slepého místa. Proto také test, který funguje z notebooku, o routeru nic nedokazuje.

Kde si resolver pfSense volí vlastní cestu nahoru

pfSense to rozdělení ukazuje. Klientský provoz lze policy routingem poslat přes bránu VPN, zatímco vlastní provoz firewallu se řídí odchozím nastavením resolveru, nikoli pravidly LAN. Ve webovém rozhraní to nastavení najdete pod Services > DNS Resolver > Outgoing Network Interfaces a jeho hodnotou je seznam rozhraní, která resolver smí použít pro dotazy nahoru.

Právě uvedení rozhraní tunelu na tomto místě, a jen tohoto rozhraní, způsobí, že vlastní dotazy routeru půjdou tunelem. Ponecháno výchozí hodnotě vybírá resolver výstup ze směrovací tabulky, což je na hostiteli se dvěma WAN nebo s VPN často WAN.

Jiné firmwary vystavují stejné rozhodnutí pod jiným označením: seznam nadřazených serverů vázaný na zdrojovou adresu, režim pouze přeposílání nebo zdokumentovaná směrovací politika. Nastavení, které je třeba hledat, je vždy to, které volí výstup nebo zdroj pro lokálně vytvořené dotazy. Reference ke konfiguraci resolveru tuto možnost pro pfSense dokumentuje a stojí za přečtení před změnou.

Zvolte chování při výpadku dřív než nastavení

Když tunel spadne, obhajitelná jsou dvě chování: zastavit dotazy nahoru, aby nic neuniklo, nebo přejít na schválený resolver po známé cestě. Obojí je politika a ani jedno není to, co dostanete výchozím nastavením. Rozhodněte, které síť potřebuje, než se dotknete seznamu rozhraní.

Uzavření při výpadku se obhajuje snáz, ale mění výpadek tunelu ve výpadek překladu jmen pro každé zařízení za routerem. Záložní cesta udrží kancelář použitelnou, ovšem za cenu výměny nahoru mimo tunel, která musí být přijatelná záměrně, ne náhodou. Svou volbu zapište, protože další člověk, který uvidí adresu resolveru mimo VPN, to bude číst jako únik, pokud poznámka neřekne jinak. Právě tato poznámka odděluje zdokumentovanou záložní cestu od nevysvětleného zjištění v revizi příštího čtvrtletí.

Rozhodnutí komplikují dva případy. Soukromá jména mohou potřebovat interní resolver, na který se tunel dostane, a prohlížeč nebo aplikace s vlastním šifrovaným DNS může router úplně obejít, takže resolver, který jste nastavili, není vždy ten, který daná aplikace používá.

Otestujte obě cesty a výsledky držte odděleně

DNS test v prohlížeči odpovídá na úzkou otázku: které resolvery ten prohlížeč použil, za podmínek daného testu. Neinventarizuje zařízení v síti a nevidí dotaz, který router vytvořil pro sebe. Berte jeho výstup jako jeden datový bod, ne jako audit.

Z klienta v LAN požádejte router o veřejné jméno a potom o soukromé, na které má odpovídat jen vaše interní zóna. Selhání pouze u druhého dotazu ukazuje na přeposílání jmen, nikoli na tunel:

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

Potom tunel shodte a oba dotazy zopakujte. Odmítnuté odpovědi znamenají, že resolver se při výpadku uzavírá; úspěšná odpověď ukazuje na záložní resolver a na cestu, kterou použil. Porovnejte to s poznámkou, kterou jste napsali, a se zachycením na rozhraní WAN pořízeným ve stejné minutě.

Záznam veďte tak, aby pozorování zůstala oddělená: výměnu klienta s routerem, výměnu routeru s nadřazeným serverem a konfiguraci, která rozhodla o druhé z nich. Pozdější změna směrování tuto druhou výměnu bez varování procvičí. Odpověď, která přichází odjinud než z koncového bodu VPN, sama o sobě únik není; únikem se stává jen tehdy, když si konfigurace tu cestu vybrala náhodou.