Pse kërkesat e dnsmasq dalin jashtë VPN-së pas një ridrejtimi DNS

Klienti i LAN-it e arrin saktë VPN-në e vet dhe megjithatë kërkesat e tij DNS shfaqen në lidhjen e sipërme të gabuar. Kjo nuk është rrjedhje në kuptimin e zakonshëm; është ajo që ndodh kur ruteri ndalon së përcjelli një kërkesë dhe i përgjigjet vetë. Ndërhyrja e rishkruan destinacionin drejt një socket lokal, dhe pastaj zgjidhësi hap një bisedë të dytë, të palidhur, me adresën e vet burimore dhe vendimin e vet të rrugëtimit. Shenjat e vendosura në rrjedhën e klientit përshkruajnë bisedën e parë dhe absolutisht asgjë për të dytën.

Shenja nuk udhëton bashkë me kërkesën

Shënjat e paketës jetojnë në një zë conntrack dhe në paketën në fluturim. Një rregull REDIRECT e përfundon atë fluturim: ngarkesa i dorëzohet një socket lokal, dhe zëri origjinal e ka kryer punën e vet. Ajo që del më pas nga ruteri është një socket i ri i krijuar nga procesi i zgjidhësit, me adresën e vetë ruterit si burim.

Prandaj një rrugë politike e lidhur me adresën e klientit të LAN-it nuk përputhet kurrë me kërkesën drejt upstream-it. Socket-i i ri i përket dnsmasq dhe jo klientit, dhe kerneli e vlerëson rrugën për trafikun e vetë ruterit. Rregullat e burimit, rregullat e ndërfaqes dhe rregullat e shenjave shohin të gjitha një tuple tjetër. Të supozosh se shenja përhapet është gabimi më i zakonshëm në këtë konfigurim dhe është i padukshëm në një kapje nga ana e klientit.

Të dyja bisedat ndajnë vërtet një emër dhe një kohë, dhe pikërisht kjo i bën të duken si një rrjedhë e vetme kur shfleton shpejt një kapje.

Ku përcjellja kthehet në zgjidhje lokale

Filloni duke zbuluar nëse porta 53 ridrejtohet, përkthehet drejt një hosti tjetër apo lihet e paprekur, sepse të tre rastet sillen ndryshe. Një ridrejtim drejt një porte lokale e përfundon përcjelljen, ndërsa një përkthim drejt një makine tjetër e mban paketën në lëvizje dhe e mban kuptimplotë tuple-in e klientit.

Shikoni të dy protokollet. Një zgjidhës i arritshëm përmes UDP dhe TCP do të testohet përmes të dyjave, dhe një grup rregullash që mbulon vetëm UDP lë një vrimë të qetë për përgjigjet e mëdha. Rregullat që gjeneron vetë menaxheri i konfigurimit të ruterit gjithashtu numërohen, dhe redaktimi i një skedari të gjeneruar zakonisht humbet ndaj ringarkimit të radhës.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

Këto dalje u përgjigjen me radhë tre pyetjeve: çfarë e rishkruan kërkesën, çfarë e pranon atë dhe cili proces zotëron socket-in që dëgjon. Pasi zotëruesi të njihet, politika drejt upstream-it ka ku të banojë.

Jepini zgjidhësit politikën e vet të daljes

Një upstream specifik për domenin është mjeti më i pastër kur vetëm disa emra kanë nevojë për tunelin. dnsmasq pranon një rresht server të kufizuar në një domen, me një ndërfaqe ose adresë burimore opsionale që e drejton kërkesën jashtë një pajisjeje të zgjedhur. Pikërisht ai drejtim e bën bisedën e dytë të ndjekë VPN-në.

server=/corp.example/10.30.0.53@tun_work
log-queries

Domeni, adresa dhe ndërfaqja më sipër janë vendmbajtëse për vlerat tuaja. Zgjedhja e domenit dhe kontrolli i daljes mbeten vendime të ndara: rruga duhet të ekzistojë, adresa burimore duhet të lejohet nga zgjidhësi i upstream-it dhe muri i zjarrit duhet të lejojë përgjigjen. Vetëm drejtimi përmes ndërfaqes nuk është fail-closed, sepse një tunel i zhdukur mund ta lërë zgjidhësin të bjerë mbi një rrugë tjetër. Mbani çdo alternativë publike larg një hapësire emrash që duhet të mbetet private.

Vendosni rreshtin te zotëruesi i konfigurimit që mbështet ruteri dhe jo në një skedar të gjeneruar, përndryshe ringarkimi i radhës e fshin rregullimin.

Çfarë nuk mund të ruajë një cache e përbashkët

Një përcjellës me një cache i shërben çdo klienti të LAN-it, dhe kjo rrëzon një dallim që disa rrjete e kanë të nevojshëm. Nëse dy klientë duhet ta zgjidhin të njëjtin emër në mënyra të ndryshme, socket-i i përbashkët nuk ka mënyrë për të rikuperuar cili klient pyeti. Politika për çdo klient duhet të jetojë në instanca të veçanta të zgjidhësit ose në një veçori përcjelljeje që ruan identitetin.

Një përgjigje e ruajtur nuk është as provë për rrugën e re. Përgjigja mund të vijë nga kujtesa ndërsa rruga drejt upstream-it mbetet e thyer.

Rregullat e portës 53 nuk thonë asgjë për aplikacionet që e flasin DNS përmes HTTPS ose përmes TLS. Ato kërkesa nuk arrijnë kurrë te ridrejtimi, prandaj një politikë e ndërtuar vetëm mbi portën 53 përshkruan një nëngrup të trafikut dhe duhet dokumentuar si nëngrup.

Verifikoni bisedën e dytë, jo të parën

Testoni me një emër që ju e kontrolloni dhe vështroni të dyja anët. Një kapje nga ana e klientit provon se kërkesa e la LAN-in; vetëm ana e ruterit provon ku shkoi më pas.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

Zbrazni cache-in para çdo prove, sepse një përgjigje e ngrohtë fsheh një upstream të thyer. Përsëritni përmes TCP dhe pastaj përsëritni me tunelin poshtë për të parë çfarë bën zgjidhësi kur rruga e tij e preferuar ka ikur. Pikërisht sjellja e fundit vendos nëse dizajni është fail-closed apo thjesht me fat.