Zašto vlastiti DNS rutera zaobilazi VPN tunel?

Upiti klijenata idu kroz tunel, dok vlastiti upiti rutera izlaze preko WAN-a, a pravilo vatrozida koje uređuje jedno ne utječe na drugo. Razlog nije greška: proslijeđeni zahtjev i zahtjev koji ruter sam stvori dva su odvojena toka i svaki se uparuje s drugim dijelom konfiguracije. Ako snimite samo klijentsku polovinu, dobit ćete uvjeren odgovor o putu koji druga polovina nikad ne koristi. Popravak je svjesno usmjeriti ruterov razrješivač, a zatim odvojeno testirati oba puta.

Kojem toku snimanje paketa zapravo pripada

Jedan upit uključuje dvije razmjene. LAN klijent šalje upit ruterovom razrješivaču i on stiže kao proslijeđeni promet na LAN sučelju, pa ga pravilo politike usmjeravanja ili NAT pravilo napisano za proslijeđene pakete može upariti. Zatim ruter odgovara iz predmemorije ili, kad nema zapisa, otvara vlastiti upit prema uzvodnom poslužitelju.

Taj drugi upit ima ruter kao izvor i kao vlastito odredište, a platforma mu bira put iz drugog bloka konfiguracije. Obje razmjene nose isti naziv i nijedna nije kopija one druge. Zato snimka uzeta na LAN strani dokazuje kamo je otišao klijentov paket i ne govori ništa o odlaznom paketu.

Praktična provjera je promatrati obje strane istodobno. Na ruteru popišite utičnicu razrješivača, upitajte je lokalno i snimite WAN sučelje:

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

Ako popis utičnica pokaže slušatelja vezanog na loopback ili LAN adresu, ruter odgovara lokalno umjesto da prosljeđuje drugom hostu. Snimka tada pokazuje izlazi li dobiveni uzvodni upit kroz sučelje tunela ili kroz WAN, a to je odgovor koji pravilo politike usmjeravanja nikad ne bi dalo.

Zašto politika usmjeravanja nikad ne vidi drugi upit

Pravila vatrozida pišu se prema sučelju, izvoru, odredištu i portu i ocjenjuju se za pakete koji prolaze kroz uređaj. Upit koji ruter stvori ne prolazi ni kroz što, jer ga lokalni proces predaje izravno tablici usmjeravanja. Politika usmjeravanja i NAT zato se primjenjuju samo na proslijeđeni put i upravo zato skup pravila može izgledati potpun, a ipak ostaviti ruterov DNS izvan tunela.

Ta razlika preživljava svako prepisivanje firmvera jer proizlazi iz puta paketa, a ne iz značajke. Sve što uređaj stvori za sebe, bilo upiti razrješivača, sinkronizacija vremena, provjere ažuriranja ili pristup zrcalima paketa, lokalnog je podrijetla i pada u istu slijepu točku. Zato i test koji radi s prijenosnog računala ne dokazuje ništa o ruteru.

Gdje pfSense razrješivač odlučuje o vlastitom uzvodnom putu

pfSense tu podjelu čini vidljivom. Klijentski promet može se usmjeravati politikom kroz VPN pristupnik, dok vlastiti promet vatrozida slijedi odlaznu postavku razrješivača umjesto LAN pravila. U web sučelju ta postavka stoji pod Services > DNS Resolver > Outgoing Network Interfaces, a njezina je vrijednost popis sučelja koja razrješivač smije koristiti za uzvodne upite.

Navesti ondje sučelje tunela, i samo to sučelje, čini da vlastiti upiti rutera slijede tunel. Ostavljena na zadanoj vrijednosti, postavka bira izlaz iz tablice usmjeravanja, što je na hostu s dva WAN-a ili VPN-om često WAN.

Drugi firmveri istu odluku izlažu pod drugom oznakom: popis uzvodnih poslužitelja vezan uz izvornu adresu, način samo prosljeđivanja ili dokumentirana politika usmjeravanja. Postavka koju treba tražiti uvijek je ona koja bira izlaz ili izvor za lokalno stvorene upite. Referenca za konfiguraciju razrješivača dokumentira tu mogućnost za pfSense i vrijedi je pročitati prije promjene.

Odaberite ponašanje pri kvaru prije postavke

Kad tunel padne, dva su ponašanja obranjiva: zaustaviti uzvodne upite da ništa ne iscuri ili se vratiti na odobreni razrješivač na poznatom putu. Oba su politike i nijedno se ne dobiva zadano. Odlučite koje mreži treba prije nego dotaknete popis sučelja.

Zatvaranje pri kvaru lakše je braniti, ali prekid tunela pretvara u prekid razrješavanja naziva za svaki uređaj iza rutera. Rezervni put održava ured upotrebljivim, ali po cijeni uzvodne razmjene izvan tunela koja mora biti prihvatljiva namjerno, a ne slučajno. Zapišite odabir, jer sljedeća osoba koja vidi adresu razrješivača izvan VPN-a pročitat će to kao curenje, osim ako bilješka ne kaže drukčije. Ta bilješka dijeli dokumentirani rezervni put od neobjašnjenog nalaza u pregledu sljedećeg kvartala.

Dva slučaja kompliciraju odluku. Privatna imena mogu zahtijevati interni razrješivač do kojeg tunel dopire, a preglednik ili aplikacija s vlastitim šifriranim DNS-om može posve zaobići ruter, pa razrješivač koji ste konfigurirali nije uvijek onaj koji određena aplikacija koristi.

Testirajte oba puta i držite rezultate odvojeno

DNS test u pregledniku odgovara na usko pitanje: koje je razrješivače taj preglednik koristio, u uvjetima tog testa. On ne popisuje uređaje na mreži i ne vidi upit koji je ruter stvorio za sebe. Njegov rezultat tretirajte kao jednu točku podataka, a ne kao reviziju.

S LAN klijenta zatražite od rutera javno ime, a zatim privatno koje bi trebala odgovarati samo vaša interna zona. Neuspjeh samo na drugom upitu upućuje na prosljeđivanje naziva, a ne na tunel:

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

Zatim srušite tunel i ponovite oba upita. Odbijeni odgovori znače da se razrješivač zatvara pri kvaru; uspješan odgovor upućuje na rezervni razrješivač i put koji je koristio. Usporedite to s bilješkom koju ste napisali i sa snimkom na WAN sučelju uzetom u istoj minuti.

Držite opažanja odvojeno u zapisu: razmjenu klijenta s ruterom, razmjenu rutera s uzvodnim poslužiteljem i konfiguraciju koja je odlučila o drugoj. Kasnija promjena usmjeravanja pokrenut će tu drugu razmjenu bez upozorenja. Odgovor koji stiže s mjesta izvan VPN krajnje točke nije sam po sebi curenje; curenjem postaje samo kad je konfiguracija taj put odabrala slučajno.