DNS privat i Pritunl dështon? Shtoni një rrugë të ngushtë për resolver

Emrat privatë zgjidhen për të gjithë në rrjetin korporativ dhe skadojnë për të gjithë në VPN. Resolver-i i përgjigjet gateway-t, rruga drejt tij ekziston, dhe kërkesa prapë nuk merr kurrë përgjigje. Ajo që mungon nuk është një resolver tjetër publik ose një rrugë më e gjerë: është një adresë burimi të cilën serveri DNS privat është i gatshëm ta përgjigjë.

Konfirmoni që resolver-i po refuzon grupin tuaj të klientëve

Filloni duke provuar që dështimi ka të bëjë me burimin, jo me arritshmërinë. Nga një klient i lidhur, pyesni resolver-in privat drejtpërdrejt dhe vëzhgoni nëse kërkesa skadon ose kthehet si refuzim. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 që skadon ndërsa e njëjta kërkesë nga gateway kalon me sukses tregon një politikë aksesi në resolver. Një përgjigje SERVFAIL tregon një vend krejt tjetër, zakonisht zonën ose përcjellësin e sipërm.

Shënoni adresën e klientit përpara testit. ip -4 addr show tun0 në klient, ose qiraja e shfaqur në konsolë, ju tregon se cilin grup sheh resolver-i.

Më pas konfirmoni që rruga ekziston fare. Një rrugë që dërgon adresën e resolver-it në tunel është parakusht, jo zgjidhja; nëse paketat nuk arrijnë kurrë, politika e burimit nuk konsultohet fare. Kontrollojeni me ip route get 10.40.0.53 në klient.

Shtoni një rrugë të vetme hosti në vend që të përktheni gjithçka

Udhëzimi i Pritunl për DNS privat përshkruan ilaçin e ngushtë: një rrugë /32 me NAT për adresën e resolver-it, me atë adresë të zgjedhur si server DNS i klientëve. Rruga ndryshon burimin që sheh resolver-i vetëm për trafikun DNS. Trafiku i aplikacioneve ruan modelin që ruan burimin që keni zgjedhur për të.

Konfigurojeni përmes pronarit të rrugëve të mbështetur të serverit, pasi të keni shqyrtuar rrugët ekzistuese për mbivendosje. Në shembullin më sipër destinacioni është 10.40.0.53/32 me NAT të aktivizuar, dhe grupi i klientëve mbetet 10.90.0.0/24. Mos e përktheni të gjithë gamën private për të rregulluar një shërbim, sepse çdo politikë e mëposhtme që mbështetet në adresën reale të klientit do të fillojë të shohë gateway-in në vend të saj. Konfirmoni adresën që resolver-i merr në të vërtetë duke vëzhguar regjistrin e kërkesave gjatë një kërkimi testues. Një rrugë e vetme hosti nuk provon asgjë për përkthimin ose lejen.

Resolver-i ende duhet të lejojë burimin e përkthyer në UDP dhe TCP, dhe përgjigjet e tij duhet të mund të kthehen. Ndryshimi i burimit nuk mund të krijojë një zonë ose regjistrim që mungon.

Vendosni nëse serveri apo klienti e dërgon kërkesën

Pritunl dokumenton gjithashtu një rregullim proxy DNS të lidhur me VPN Client DNS Mapping, ku serveri përcjell kërkesat e sipërme për klientët. Në atë model burimi i sipërm i përket kontekstit të rrjetit të vetë serverit, dhe një përjashtim në anën e klientit është zgjidhja e gabuar.

Identifikoni cili model është aktiv përpara se të shtoni diçka. Tre riparime që mbivendosen, një proxy, një zëvendësim i resolver-it në klient dhe një skript manual NAT zakonisht nënkuptojnë që askush nuk ka përcaktuar: cili komponent duhet ta dërgojë kërkesën. Kontrolloni edhe bootstrap: një resolver vetëm-privat nuk mund të jetë mënyra e vetme për të gjetur pikën fundore përpara se tuneli të ekzistojë, dhe një ndryshim i përhershëm i resolver-it nuk duhet t’i mbijetojë lidhjes.

Testoni një kërkim privat, jo një faqe web publike

Pasi të aplikoni ndryshimin dhe të rilidheni, inspektoni konfigurimin efektiv të resolver-it të klientit, pastaj zgjidhni një emër që e dini se ekziston vetëm në zonën private. dig intranet.example.net pa një server të qartë tregon çfarë përdor në të vërtetë klienti. Vazhdoni me një kërkesë drejt adresës që ktheu ai kërkim, sepse zgjidhja dhe aksesi në shërbim janë hapa të veçantë. Një shfletues që ngarkon sajte publike përmes DNS-over-HTTPS nuk provon asgjë për rrugën e resolver-it privat të sistemit operativ. As një resolver dytësor publik nuk është autoritet për një zonë të brendshme.

Regjistroni adresën e resolver-it, rrugën /32 dhe cilësimin DNS të klientit së bashku në shënimet e serverit. Gjysma e atij konfigurimi e rikthyer vetëm riprodhon dështimin origjinal.

Së fundi, konfirmoni që tuneli ende e drejton destinacionin e aplikacionit pasi DNS ka sukses. Rruga, aksesi në shërbim dhe vërtetimi mbeten të pavarura nga zgjidhja e emrave, dhe një kërkim që funksionon nuk thotë asgjë për fuqinë e transmetimit. Nëse faqja private është e ngadaltë por zgjidhet, resolver-i e bëri punën e tij dhe problemi u zhvendos në rrugë.