Pse dështojnë emrat privatë DNS në klientët VPN dhe ku duhet kontrolluar

Hapni një laptop në një dhomë hoteli, nisni klientin, shkruani emrin e serverit të skedarëve të brendshëm dhe nuk merrni asgjë. Tuneli raporton i lidhur, dhe një ping drejt një adrese brenda të njëjtës nënrrjet përgjigjet ende, pra transporti në vetvete është në rregull. Vetëm emri dështon, dhe ai boshllëk e ngushton problemin në dy vende: cilit resolver i kërkoi klienti dhe nëse përgjigja që mori mund të kthehet përmes tunelit. Zgjidhni njërën dhe harroni tjetrën, dhe defekti thjesht zhvendoset.

Përpara se të modifikoni ndonjë profil, konfirmoni çfarë bën klienti me emrin. Në Linux, resolvectl query files.corp.example tregon cila lidhje dhe cili resolver e prodhuan përgjigjen. Në Windows, Resolve-DnsName files.corp.example tregon serverin që u përgjigj dhe adresën që ktheu.

Lexoni përgjigjen para se të ndryshoni ndonjë gjë

Nëse emri kthehet si NXDOMAIN në pak milisekonda, kërkesa nuk arriti kurrë në zonën tuaj dhe u përgjigj ndonjë resolver publik ose i hotelit. Nëse kthehet pas një pauze të gjatë, diçka po e hedh poshtë portin UDP 53 gjatë rrugës dhe klienti përfundimisht ra prapa. Nëse përgjigjet me adresën e saktë por lidhja ngec ende, zgjidhja është në rregull dhe problemi juaj është rrugëtimi ose vetë shërbimi.

Ai ndarje në tre kursen një orë hamendjeje. Ju tregon gjithashtu nëse duhet ta prekni fare VPN-në: një emër që zgjidhet në adresën e saktë private e ka vërtetuar tashmë rrugën e resolverit, pra puna që mbetet është në rrugën e të dhënave.

Shpërndani resolverin nga brenda tunelit

Klientët ndahen në dy grupe. Njërit mund t’i jepet një resolver nga serveri gjatë vendosjes së lidhjes; tjetri e mban cilësimin në një skedar lokal që asnjë portë nuk mund ta ndryshojë në distancë.

OpenVPN është në grupin e parë. Në server, push "dhcp-option DNS 10.8.0.53" dhe push "dhcp-option DOMAIN corp.example" zbresin përmes kanalit të kontrollit, por vetëm nëse konfigurimi i klientit ka ende pull të aktivizuar. Një klient i modifikuar me dorë që mban pull-filter ignore "dhcp-option" nuk do t’i shohë kurrë, dhe ajo rresht i vetëm shpjegon një numër befasues rastesh të tipit «serveri e shtyn, por laptopi im nuk pajtohet».

WireGuard është në grupin e dytë, sepse protokolli nuk ka fare negociim opsionesh. Resolveri dhe domeni i kërkimit shkojnë në bllokun [Interface] të vetë klientit si DNS = 10.8.0.53, corp.example. wg-quick e zbaton atë përmes resolvconf ose systemd-resolved, dhe në Windows klienti zyrtar instalon rregulla NRPT që ekzistojnë vetëm sa kohë tuneli është i ngritur: Get-DnsClientNrptPolicy i liston ato, gjë që e bën një mënyrë të shpejtë për të parë nëse klienti e ka zbatuar ndonjëherë skedarin tuaj.

IPsec/IKEv2 qëndron në mes. Shtojca attr e strongSwan mund të kthejë një server DNS të nxjerrë nga një grup, dhe një klient Windows normalisht e pranon, por një profil që fikson serverin e vet të emrave fiton mbi çdo gjë që ofron porta. Në një klient Linux hapi manual ekuivalent është resolvectl dns wg0 10.8.0.53 i ndjekur nga resolvectl domain wg0 '~corp.example'; të dyja zhduken së bashku me ndërfaqen, gjë që është pikërisht ajo që dëshironi për një cilësim të kufizuar në tunel.

Kufizoni prapashtesën në vend që të gëlltitni çdo kërkesë

Të drejtosh të gjithë listën e resolerëve të klientit drejt serverit tuaj të brendshëm është e lehtë dhe zakonisht e gabuar. Atëherë çdo emër publik zgjidhet nga dalja e qendrës tuaj të të dhënave, CDN-të kthejnë adresa të largëta, dhe një ndërprerje e resolverit e merr me vete shfletimin e përdoruesit.

Dërgoni nga brenda vetëm prapashtesën private. Në systemd-resolved, një domen që fillon me ~ është vetëm për rrugëtim, pra ~corp.example do të thotë që kërkesat nën atë prapashtesë shkojnë te serverët e asaj lidhjeje, ndërsa gjithçka tjetër vazhdon të përdorë rrjetin fizik. Windows bën të njëjtën gjë me rregulla NRPT të kufizuara në një hapësirë emrash, dhe macOS me një skedar resolver shtesë nën /etc/resolver/.

Emrat multicast meritojnë përgjigjen e tyre. Emrat .local janë link-local sipas ndërtimit (RFC 6762) dhe një ndërfaqe tun pikë-për-pikë nuk e transporton atë grup multicast, pra shtimi i një resolveri publik nuk i publikon ata, dhe pyetja e një resolveri të brendshëm unicast rreth tyre kthen NXDOMAIN. Një reflektor si avahi në modalitetin reflektor mund të lidhë dy segmente, por ai është një vendim në anën e serverit që asnjë klient nuk mund ta kërkojë. Nëse një printer ose një NAS duhet të arrihet me emër, jepini atij një regjistrim A në zonën tuaj.

Vërtetoni se përgjigja mund të kthehet

Një përgjigje e saktë që tregon një adresë të paarritshme duket saktësisht si një problem resolveri derisa të kontrolloni rrugën. Pyetni kernelin se ku do të shkonte përgjigja: ip route get 10.20.5.20 emërton ndërfaqen dhe, më e dobishme, adresën burimore që do të përdorte.

Vëzhgoni vetë adresën e resolverit. Një klient me DNS = 10.8.0.53 pranë AllowedIPs = 10.20.0.0/16 i dërgon kërkesat e tij përmes NIC-it fizik, ku vdesin në heshtje, sepse resolveri nuk ndodhet brenda asnjë prefiksi që tuneli pretendon. Ai mospërputhje është dështimi më i zakonshëm me shkak të vetëm në gjithë këtë fushë, dhe mbetet i padukshëm nëse nuk e krahason cilësimin e DNS me prefikset e lejuara rresht për rresht.

Intervalet e mbivendosura shkaktojnë dështimin e kundërt. Përgjigja është e saktë, rruga ekziston dhe tregon nikoqirin e gabuar, sepse 192.168.0.0/24 në shtëpi është më specifik se rruga e tunelit drejt të njëjtit interval. Rinumëroni njërën anë ose shtyni një rrugë më të ngushtë, më pas konfirmoni firewalin dhe rrugën e kthimit të nikoqirit të shërbimit; shënimet e strongSwan rreth përcjelljes mbulojnë anën sysctl të asaj rruge.

Certifikatat janë një kontroll identiteti më vete që njerëzit ia hedhin DNS-së. Nëse shfletuesi raporton një mospërputhje emri në vend të një gabimi zgjidhjeje, kërkimi tashmë ka funksionuar dhe ajo që duhet rregulluar është SAN-i në certifikatë. Testoni HTTPS kundër emrit, kurrë kundër IP-së të zhveshur.

Ritestoni nga klienti, jo nga porta

Testoni brenda aplikacionit për të cilin ankohet përdoruesi, sepse një kërkim në rreshtin e komandave nuk provon që shfletuesi ndjek të njëjtën rrugë. DNS-i i sigurt i Chrome dhe network.trr.mode i Firefox mund ta anashkalojnë plotësisht resolverin e sistemit, dhe kur e bëjnë këtë, një emër privat dështon ose rrjedh drejt një resolveri publik. Krahasimi i resolvectl query me një dig @10.8.0.53 files.corp.example të ekzekutuar me dorë ju tregon se cila nga të dyja ndodhi.

Më pas shkëputni dhe rilidhni përpara se ta shpallni të rregulluar. Cilësimet e aplikuara me dorë në një ndërfaqe zhduken me ndërfaqen, dhe një profil që dukej i saktë vetëm për shkak të një modifikimi lokal të mbetur do të dështojë në nisjen tjetër.

Një listë e shkurtër për makinën tjetër: emri zgjidhet përmes resolverit të tunelit, prapashtesa është e kufizuar në vend të globale, adresa e resolverit ndodhet brenda prefikseve të lejuara, nikoqiri i përgjigjes përgjigjet në portin e shërbimit, dhe certifikata mbulon emrin që shkroi përdoruesi.