Prečo vlastný DNS routera obchádza tunel VPN?

Dopyty klientov idú cez tunel, zatiaľ čo vlastné dopyty routera vychádzajú cez WAN, a pravidlo firewallu, ktoré riadi jedno, nemá na druhé žiadny vplyv. Príčina nie je chyba: preposlaná požiadavka a požiadavka, ktorú router vytvorí sám, sú dva oddelené toky a každý sa porovnáva s inou časťou konfigurácie. Ak zachytíte len klientsku polovicu, dostanete sebavedomú odpoveď o ceste, ktorú druhá polovica nikdy nepoužíva. Náprava spočíva v tom, že resolver routera vedome nasmerujete, a potom obe cesty otestujete oddelene.

Ku ktorému toku záznam paketov vlastne patrí

Jeden dopyt zahŕňa dve výmeny. Klient v LAN pošle dopyt resolveru routera a ten príde ako preposlaná premávka na rozhraní LAN, takže ho pravidlo politického smerovania alebo NAT napísané pre preposlané pakety môže zachytiť. Potom router odpovie z vyrovnávacej pamäte alebo pri minutí otvorí vlastný dopyt na server vyššie.

Druhý dopyt má ako zdroj samotný router a ako cieľ tiež jeho, a platforma mu vyberá cestu z iného bloku konfigurácie. Obe výmeny nesú rovnaké meno a ani jedna nie je kópiou tej druhej. Záznam urobený na strane LAN preto dokazuje, kam odišiel paket klienta, a o odchádzajúcom pakete nehovorí nič.

Praktická kontrola spočíva v tom, že sledujete obe strany súčasne. Na routeri vypíšte socket resolvera, opýtajte sa ho lokálne a zachyťte rozhranie WAN:

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

Ak zoznam socketov ukáže poslucháča naviazaného na adresu loopback alebo LAN, router odpovedá lokálne, namiesto toho aby preposielal inému hostiteľovi. Záznam potom ukáže, či výsledný dopyt nahor odchádza cez rozhranie tunela alebo cez WAN, a to je odpoveď, ktorú pravidlo politického smerovania nikdy nedalo.

Prečo politické smerovanie nikdy nevidí druhý dopyt

Pravidlá firewallu sa píšu pre rozhranie, zdroj, cieľ a port a vyhodnocujú sa pre pakety, ktoré prechádzajú zariadením. Dopyt, ktorý router vytvorí, neprechádza ničím, pretože lokálny proces ho odovzdá priamo smerovacej tabuľke. Politické smerovanie a NAT sa preto týkajú len preposlanej cesty, a práve preto môže sada pravidiel vyzerať úplne, a napriek tomu nechať DNS routera mimo tunela.

Toto rozlíšenie prežíva každé prepísanie firmvéru, pretože vyplýva z cesty paketu, nie z funkcie. Všetko, čo zariadenie vytvára pre seba, či už dopyty resolvera, synchronizácia času, kontroly aktualizácií alebo prístup k zrkadlám paketov, má lokálny pôvod a padá do toho istého slepého miesta. Preto ani test z notebooku nič nedokazuje o routeri.

Kde si resolver pfSense volí vlastnú cestu nahor

pfSense to rozdelenie ukazuje. Klientsku premávku možno poslať politickým smerovaním cez bránu VPN, zatiaľ čo vlastná premávka firewallu sa riadi odchádzajúcim nastavením resolvera, nie pravidlami LAN. Vo webovom rozhraní je to nastavenie pod Services > DNS Resolver > Outgoing Network Interfaces a jeho hodnotou je zoznam rozhraní, ktoré resolver smie použiť na dopyty nahor.

Práve uvedenie rozhrania tunela tam, a len tohto rozhrania, spôsobí, že vlastné dopyty routera pôjdu tunelom. Ponechané predvolenej hodnote, nastavenie si vyberá výstup zo smerovacej tabuľky, čo je na hostiteľovi s dvoma WAN alebo VPN často WAN.

Iné firmvéry vystavujú rovnaké rozhodnutie pod iným označením: zoznam serverov vyššie naviazaný na zdrojovú adresu, režim iba preposielania alebo zdokumentovaná smerovacia politika. Nastavenie, ktoré treba hľadať, je vždy to, ktoré volí výstup alebo zdroj pre lokálne vytvorené dopyty. Referencia ku konfigurácii resolvera dokumentuje túto možnosť pre pfSense a pred zmenou ju stojí za to prečítať.

Zvoľte správanie pri výpadku skôr než nastavenie

Keď tunel padne, obhájiteľné sú dve správania: zastaviť dopyty nahor, aby nič neuniklo, alebo prejsť na schválený resolver po známej ceste. Obe sú politikou a ani jedno nie je to, čo dostanete predvolene. Rozhodnite, ktoré sieť potrebuje, skôr než sa dotknete zoznamu rozhraní.

Uzavretie pri výpadku sa obhajuje ľahšie, ale mení výpadok tunela na výpadok prekladu mien pre každé zariadenie za routerom. Návrat udrží kanceláriu použiteľnú, no za cenu výmeny nahor mimo tunela, ktorá musí byť prijateľná zámerne, nie náhodou. Zapíšte voľbu, pretože ďalší človek, ktorý uvidí adresu resolvera mimo VPN, to bude čítať ako únik, ak poznámka nehovorí inak. Práve táto poznámka oddeľuje zdokumentovaný návrat od nevysvetleného zistenia v revízii budúceho štvrťroka.

Rozhodnutie komplikujú dva prípady. Súkromné mená môžu potrebovať interný resolver, na ktorý sa tunel dostane, a prehliadač alebo aplikácia s vlastným šifrovaným DNS môže router úplne obísť, takže resolver, ktorý ste nastavili, nie je vždy ten, ktorý daná aplikácia používa.

Otestujte obe cesty a výsledky držte oddelene

DNS test v prehliadači odpovedá na úzku otázku: ktoré resolvery ten prehliadač použil v podmienkach daného testu. Nevytvára inventár zariadení v sieti a nevidí dopyt, ktorý router vytvoril pre seba. Berte jeho výstup ako jeden dátový bod, nie ako audit.

Z klienta v LAN požiadajte router o verejné meno a potom o súkromné, na ktoré má odpovedať len vaša interná zóna. Zlyhanie iba pri druhom dopyte ukazuje na preposielanie mien, nie na tunel:

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

Potom tunel zhoďte a oba dopyty zopakujte. Odmietnuté odpovede znamenajú, že resolver sa pri výpadku uzatvára; úspešná odpoveď ukazuje na záložný resolver a cestu, ktorú použil. Porovnajte to s poznámkou, ktorú ste napísali, a so záznamom na rozhraní WAN urobeným v tej istej minúte.

Pozorovania držte oddelene v zázname: výmenu klienta s routerom, výmenu routera so serverom vyššie a konfiguráciu, ktorá rozhodla o druhej. Neskoršia zmena smerovania túto druhú výmenu precvičí bez varovania. Odpoveď, ktorá prichádza odinakiaľ než z koncového bodu VPN, sama o sebe nie je únik; únikom sa stáva až vtedy, keď si konfigurácia tú cestu vybrala náhodou.