De ce DNS-ul propriu al routerului ocolește tunelul VPN?

Interogările clienților urmează tunelul, în timp ce interogările proprii ale routerului ies prin WAN, iar regula de firewall care o guvernează pe una nu are niciun efect asupra celeilalte. Motivul nu este un defect: o cerere redirecționată și o cerere pe care routerul o generează singur sunt două fluxuri separate, iar fiecare este comparată cu o altă parte a configurației. Dacă capturați doar jumătatea clientului, obțineți un răspuns sigur despre o cale pe care cealaltă jumătate nu o folosește niciodată. Remedierea este să îndreptați în mod deliberat resolverul routerului și apoi să testați cele două căi separat.

Cărui flux îi aparține de fapt captura de pachete

O interogare implică două schimburi. Un client din LAN trimite o interogare către resolverul routerului, iar aceasta ajunge ca trafic redirecționat pe interfața LAN, așa că o regulă de rutare politică sau NAT scrisă pentru pachete redirecționate o poate potrivi. Apoi routerul răspunde din cache sau, la lipsă, deschide propria interogare către un server aflat mai sus.

Acea a doua interogare are routerul ca sursă și ca destinație proprie, iar platforma îi alege calea dintr-un alt bloc de configurație. Ambele schimburi poartă același nume și niciunul nu este o copie a celuilalt. De aceea, o captură făcută pe partea LAN demonstrează unde a mers pachetul clientului și nu spune nimic despre pachetul care iese.

Verificarea practică este să observați ambele părți simultan. Pe router, listați socketul resolverului, interogați-l local și capturați interfața WAN:

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

Dacă lista de socketuri arată un ascultător legat de adresa loopback sau LAN, routerul răspunde local în loc să redirecționeze către alt gazdă. Atunci captura arată dacă interogarea ascendentă rezultată iese prin interfața tunelului sau prin WAN, și acesta este răspunsul pe care regula de rutare politică nu l-ar fi dat niciodată.

De ce rutarea politică nu vede niciodată a doua interogare

Regulile de firewall se scriu pentru o interfață, o sursă, o destinație și un port, și sunt evaluate pentru pachetele care trec prin echipament. O interogare pe care o generează routerul nu trece prin nimic, pentru că un proces local o predă direct tabelului de rutare. Rutare politică și NAT se aplică deci doar căii redirecționate, și de aceea un set de reguli poate părea complet și totuși poate lăsa DNS-ul routerului în afara tunelului.

Această distincție supraviețuiește fiecărei rescrieri de firmware pentru că decurge din calea pachetului, nu dintr-o funcție. Tot ce generează echipamentul pentru sine, fie interogări ale resolverului, sincronizare a timpului, verificări de actualizare sau acces la oglinzi de pachete, este de origine locală și cade în același punct orb. De aceea, un test făcut de pe un laptop nu dovedește nimic despre router.

Unde resolverul pfSense își decide propria cale ascendentă

pfSense face separarea vizibilă. Traficul clienților poate fi rutat politic printr-o poartă VPN, în timp ce traficul propriu al firewallului urmează setarea de ieșire a resolverului, nu regulile LAN. În interfața web, acea setare se află sub Services > DNS Resolver > Outgoing Network Interfaces, iar valoarea ei este lista de interfețe pe care resolverul le poate folosi pentru interogările ascendente.

Numirea interfeței tunelului acolo, și doar a acelei interfețe, este ceea ce face interogările proprii ale routerului să urmeze tunelul. Lăsată la valoarea implicită, setarea alege o ieșire din tabelul de rutare, care pe un host cu WAN dublu sau VPN este adesea WAN.

Alte firmwareuri expun aceeași decizie sub altă etichetă: o listă de servere ascendente legată de o adresă sursă, un mod doar de redirecționare sau o politică de rute documentată. Setarea pe care trebuie să o căutați este întotdeauna cea care alege o ieșire sau o sursă pentru interogările generate local. Referința pentru configurația resolverului documentează această opțiune pentru pfSense și merită citită înainte de modificare.

Alegeți comportamentul la eșec înaintea setării

Când tunelul cade, două comportamente sunt de apărat: oprirea interogărilor ascendente ca să nu scape nimic, sau revenirea la un resolver aprobat pe o cale cunoscută. Ambele sunt politici, și niciunul nu este ceea ce se obține implicit. Decideți de care are nevoie rețeaua înainte de a atinge lista de interfețe.

Închiderea la eșec este mai ușor de apărat, dar transformă căderea tunelului într-o cădere a rezolvării numelor pentru fiecare dispozitiv din spatele routerului. Revenirea menține biroul utilizabil, cu prețul unui schimb ascendent în afara tunelului care trebuie să fie acceptabil intenționat, nu întâmplător. Notați alegerea, pentru că următoarea persoană care vede o adresă de resolver în afara VPN o va citi ca o scurgere, dacă o notă nu spune altceva. Acea notă este ce separă o revenire documentată de o constatare neexplicată în revizuirea trimestrului următor.

Două cazuri complică decizia. Numele private pot avea nevoie de un resolver intern pe care tunelul îl atinge, iar un browser sau o aplicație cu DNS criptat propriu poate ocoli complet routerul, așa că resolverul configurat nu este întotdeauna cel pe care îl folosește o anumită aplicație.

Testați ambele căi și păstrați rezultatele separat

Un test DNS în browser răspunde la o întrebare îngustă: ce resolveri a folosit acel browser, în condițiile acelui test. Nu inventariază dispozitivele din rețea și nu poate vedea o interogare pe care routerul a generat-o pentru sine. Tratați rezultatul ca pe un punct de date, nu ca pe un audit.

De pe un client din LAN, cereți routerului un nume public și apoi unul privat la care ar trebui să răspundă doar zona internă. Un eșec doar la a doua interogare indică redirecționarea numelor, nu tunelul:

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

Apoi coborâți tunelul și repetați ambele interogări. Răspunsurile refuzate înseamnă că resolverul se închide la eșec; un răspuns reușit indică un resolver de rezervă și calea folosită. Comparați asta cu nota pe care ați scris-o și cu o captură pe interfața WAN făcută în același minut.

Păstrați observațiile separat în registru: schimbul clientului cu routerul, schimbul routerului cu serverul ascendent și configurația care a decis al doilea. O modificare ulterioară de rutare va exercita acel al doilea schimb fără avertisment. Un răspuns care sosește din alt loc decât punctul final al VPN nu este în sine o scurgere; devine scurgere doar când configurația a ales acea cale din întâmplare.