Pse DNS i vetë routerit e anashkalon tunelin VPN?

Kërkimet e klientëve ndjekin tunelin, ndërsa kërkimet e vetë routerit dalin përmes WAN, dhe rregulli i murit të zjarrit që drejton njërin nuk ka asnjë efekt mbi tjetrin. Arsyeja nuk është defekt: një kërkesë e përçuar dhe një kërkesë që routeri e gjeneron vetë janë dy rrjedha të veçanta, dhe secila krahasohet me një pjesë tjetër të konfigurimit. Kapja vetëm e gjysmës së klientit jep një përgjigje të sigurt për një rrugë që gjysma e dytë nuk e përdor kurrë. Rregullimi është të drejtohet me qëllim zgjidhësi i routerit, dhe më pas të provohen dy rrugët veçmas.

Cilës rrjedhë i përket në të vërtetë kapja e paketave

Një kërkim përfshin dy shkëmbime. Një klient LAN dërgon një kërkesë te zgjidhësi i routerit, dhe ajo arrin si trafik i përçuar në ndërfaqen LAN, kështu që një rregull i politikës së rrugëtimit ose NAT i shkruar për paketa të përçuara mund ta përputhë atë. Më pas routeri përgjigjet nga cache ose, kur nuk ka, hap kërkimin e tij drejt një serveri lart.

Ajo kërkesë e dytë e ka routerin si burim dhe si destinacion të vetin, dhe platforma zgjedh rrugën e saj nga një bllok tjetër konfigurimi. Të dy shkëmbimet mbajnë të njëjtin emër, dhe asnjë nuk është kopje e tjetrit. Prandaj një kapje e marrë në anën LAN dëshmon ku shkoi paketa e klientit dhe nuk thotë asgjë për paketën që del.

Kontrolli praktik është të vëzhgohen të dyja anët njëkohësisht. Në router, renditni socketin e zgjidhësit, pyesni atë lokalisht dhe kapni ndërfaqen WAN:

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

Nëse lista e socketeve tregon një dëgjues të lidhur me adresën loopback ose LAN, routeri përgjigjet lokalisht në vend që të përçojë te një host tjetër. Kapja atëherë tregon nëse kërkesa lart që rezulton del përmes ndërfaqes së tunelit apo përmes WAN, dhe ky është përgjigjja që rregulli i politikës së rrugëtimit nuk do ta kishte dhënë kurrë.

Pse politika e rrugëtimit nuk e sheh kurrë kërkesën e dytë

Rregullat e murit të zjarrit shkruhen për një ndërfaqe, një burim, një destinacion dhe një port, dhe vlerësohen për paketat që kalojnë nëpër pajisje. Një kërkesë që routeri e krijon nuk kalon nëpër asgjë, sepse një proces lokal ia dorëzon drejtpërdrejt tabelës së rrugëtimit. Rrugëtimi me politikë dhe NAT prandaj vlejnë vetëm për rrugën e përçuar, dhe pikërisht për këtë një grup rregullash mund të duket i plotë dhe gjithsesi ta lërë DNS-në e routerit jashtë tunelit.

Ky dallim i mbijeton çdo rishkrimi të firmware-it sepse rrjedh nga rruga e paketës dhe jo nga një funksion. Gjithçka që pajisja krijon për vete, qofshin kërkesat e zgjidhësit, sinkronizimi i kohës, kontrollet e përditësimit apo aksesi te pasqyrat e paketave, është me origjinë lokale dhe bie në të njëjtën pikë të verbër. Për këtë arsye edhe një test nga një laptop nuk provon asgjë për routerin.

Ku zgjidhësi i pfSense vendos rrugën e tij lart

pfSense e bën të dukshëm këtë ndarje. Trafiku i klientëve mund të rrugëtohet me politikë përmes një portali VPN, ndërsa trafiku i vetë murit të zjarrit ndjek cilësimin e daljes së zgjidhësit dhe jo rregullat e LAN. Në ndërfaqen web ai cilësim ndodhet nën Services > DNS Resolver > Outgoing Network Interfaces, dhe vlera e tij është lista e ndërfaqeve që zgjidhësi mund të përdorë për kërkesat lart.

Përmendja e ndërfaqes së tunelit atje, dhe vetëm e asaj ndërfaqeje, është ajo që i bën kërkimet e vetë routerit të ndjekin tunelin. Nëse lihet në vlerën e parazgjedhur, zgjidhësi zgjedh një dalje nga tabela e rrugëtimit, e cila në një host me dy WAN ose VPN shpesh është WAN.

Firmware të tjerë e shfaqin të njëjtin vendim nën një etiketë tjetër: një listë serverësh lart e lidhur me një adresë burimi, një modalitet vetëm përçimi, ose një politikë rrugëtimi e dokumentuar. Cilësimi që duhet kërkuar është gjithmonë ai që zgjedh një dalje ose një burim për kërkesat e krijuara lokalisht. Referenca e konfigurimit të zgjidhësit dokumenton atë opsion për pfSense dhe ia vlen të lexohet para ndryshimit.

Zgjidhni sjelljen në dështim para cilësimit

Kur tuneli bie, dy sjellje janë të mbrojtshme: ndaloni kërkesat lart që asgjë të mos rrjedhë, ose kthehuni te një zgjidhës i miratuar në një rrugë të njohur. Të dyja janë politikë, dhe asnjëra nuk është ajo që merret si parazgjedhje. Vendosni se cilën i nevojitet rrjetit përpara se të prekni listën e ndërfaqeve.

Mbyllja në dështim mbrohet më lehtë, por e kthen ndërprerjen e tunelit në ndërprerje të zgjidhjes së emrave për çdo pajisje pas routerit. Kthimi mbrapa e mban zyrën të përdorshme, me koston e një shkëmbimi lart jashtë tunelit që duhet të jetë i pranueshëm me qëllim dhe jo rastësisht. Shkruajeni zgjedhjen, sepse personi tjetër që do të shohë një adresë zgjidhësi jashtë VPN-së do ta lexojë si rrjedhje, përveç nëse një shënim thotë ndryshe. Pikërisht ai shënim ndan një kthim të dokumentuar nga një gjetje e pashpjeguar në rishikimin e tremujorit të ardhshëm.

Dy raste e ndërlikojnë vendimin. Emrat privatë mund të kenë nevojë për një zgjidhës të brendshëm që tuneli e arrin, dhe një shfletues ose aplikacion me DNS të vetë enkriptuar mund ta anashkalojë plotësisht routerin, prandaj zgjidhësi që konfiguruat nuk është gjithmonë ai që përdor një aplikacion i caktuar.

Provoji të dyja rrugët dhe mbaji rezultatet veçmas

Një test DNS në shfletues përgjigjet një pyetjeje të ngushtë: cilët zgjidhës përdori ai shfletues, në kushtet e atij testi. Ai nuk bën inventar të pajisjeve në rrjet dhe nuk mund të shohë një kërkesë që routeri e krijoi për vete. Trajtoje daljen e tij si një pikë të dhënash dhe jo si auditim.

Nga një klient LAN, kërkoni routerit një emër publik dhe më pas një emër privat të cilin vetëm zona juaj e brendshme duhet ta përgjigjet. Dështimi vetëm në kërkesën e dytë tregon përçim emrash dhe jo tunelin:

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

Më pas ulni tunelin dhe përsëritni të dyja kërkesat. Përgjigjet e refuzuara nënkuptojnë që zgjidhësi mbyllet në dështim; një përgjigje e suksesshme tregon një zgjidhës rezervë dhe rrugën që përdori. Krahasojeni atë me shënimin që shkruat dhe me një kapje në ndërfaqen WAN të marrë në të njëjtën minutë.

Mbajini vëzhgimet veçmas në regjistër: shkëmbimin e klientit me routerin, shkëmbimin e routerit me serverin lart, dhe konfigurimin që vendosi të dytin. Një ndryshim i mëvonshëm i rrugëtimit do ta ushtrojë atë shkëmbim të dytë pa paralajmërim. Një përgjigje që vjen nga një vend tjetër përveç pikës fundore të VPN nuk është në vetvete rrjedhje; ajo bëhet rrjedhje vetëm kur konfigurimi e zgjodhi atë rrugë rastësisht.