Pritunlen DNS pribatuak huts egiten du? Gehitu resolver bide estu bat
VPN igerilekua baztertzen duen resolver pribatu batek jatorrizko salbuespena behar du, ez bide zabalago bat. Gehitu NAT gaituta duen /32 bat eta probatu benetako bilaketa pribatu bat.
Izen pribatuak sare korporatiboan guztientzat ebazten dira eta VPNan guztientzat iraungitzen dira. Resolverrak atebideari erantzuten dio, hara doan bidea existitzen da, eta kontsultak hala ere ez du inoiz erantzunik jasotzen. Faltan dagoena ez da beste resolver publiko bat ez eta bide zabalago bat ere: zerbitzari DNS pribatuak erantzuteko prest dagoen jatorrizko helbide bat da.
Baieztatu resolverrak zure bezero igerilekua ukatzen duela
Hasi hutsegitea jatorriari dagokiola frogatzen, ez irisgarritasunari. Konektatuta dagoen bezero batetik, galdetu resolver pribatuari zuzenean eta ikusi eskaerak denbora-muga gainditzen duen edo ukatze gisa itzultzen den. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 denbora-muga gainditzean, atebidetik egindako kontsulta berak arrakasta izateak resolverraren sarbide-politika bat adierazten du. SERVFAIL erantzunak erabat beste leku batera adierazten du, normalean gunera edo goiko birbidaltzailera.
Probatu aurretik bezeroaren helbidea idatz ezazu. Bezeroan ip -4 addr show tun0, edo kontsolak erakusten duen errentamenduak, resolverrak zein igerileku ikusten duen esaten dizu.
Ondoren baieztatu bidea existitzen dela. Resolverraren helbidea tunelera bidaltzen duen bideak aldez aurreko baldintza da, ez konponbidea; paketeak inoiz iristen ez badira, jatorrizko politikari ez zaio inoiz kontsultatzen. Egiaztatu bezeroan ip route get 10.40.0.53 erabiliz.
Gehitu ostalari-bide bat dena itzultzen aritu beharrean
Pritunlen DNS pribatuari buruzko gidak erremedio estua deskribatzen du: NAT gaituta duen /32 bidea resolverraren helbiderako, helbide hori bezeroen DNS zerbitzari gisa hautatuta. Bideak resolverrak ikusten duen jatorria aldatzen du DNS trafikoan soilik. Aplikazioen trafikoak zuk harentzat aukeratutako jatorria zaintzen duen diseinua mantentzen du.
Konfiguratu zerbitzariak onartzen duen bide-jabearen bidez, lehendik dauden bideak gainjartzeen bila berrikusi ondoren. Goiko adibidean helmuga NAT gaituta duen 10.40.0.53/32 da, eta bezeroen igerilekua 10.90.0.0/24 izaten jarraitzen du. Ez itzuli barruti pribatu osoa zerbitzu bat konpontzeko, bezeroaren benetako helbidearen mende dagoen beheragoko politika bakoitzak atebidea ikusten hasiko baita haren ordez. Baieztatu resolverrak benetan jasotzen duen helbidea proba-bilaketa batean zehar bere kontsulta-erregistroa behatuz. Ostalari-bide bakar batek ez du ezer frogatzen itzulpenari edo baimenari buruz.
Resolverrak itzulitako jatorria UDP eta TCPn onartu behar du oraindik, eta bere erantzunek itzuli ahal izan behar dute. Jatorria aldatzeak ezin du falta den gune edo erregistro bat sortu.
Erabaki zerbitzariak edo bezeroak bidaltzen duen kontsulta
Pritunlek VPN Client DNS Mapping-ekin lotutako DNS proxy antolamendu bat ere dokumentatzen du, non zerbitzariak bezeroen izenean goiko kontsultak birbidaltzen dituen. Eredu horretan goiko jatorria zerbitzariaren berezko sare-testuinguruarena da, eta bezeroaren aldeko salbuespena konponbide okerra da.
Identifikatu zein eredu dagoen aktibo ezer gehitu aurretik. Hiru konponketa gainjarri, proxy bat, bezeroaren resolverraren ordezkapena eta NAT script eskuzko bat normalean esan nahiko du inork ez duela ezarri: zein osagai den kontsulta bidaltzeko arduraduna. Egiaztatu bootstrapa ere: resolver pribatu soil bat ezin da izan tunela existitu aurretik amaiera-puntua aurkitzeko modu bakarra, eta resolverraren aldaketa iraunkor batek ez luke konexioa biziraun behar.
Probatu bilaketa pribatu bat, ez web orri publiko bat
Aldaketa aplikatu eta berriz konektatu ondoren, aztertu bezeroaren resolver konfigurazio eraginkorra, eta gero ebatzi guneari pribatuan soilik badagoela dakizun izen bat. Berariazko zerbitzaririk gabe dig intranet.example.net erakusten du bezeroak benetan zer erabiltzen duen. Jarraitu bilaketa horrek itzulitako helbidera egindako eskaera batekin, ebazpena eta zerbitzuaren sarbidea urrats bereiziak baitira. DNS-over-HTTPS bidez gune publikoak kargatzen dituen nabigatzaileak ez du ezer frogatzen sistema eragilearen resolver pribatuaren bideari buruz. Resolver sekundario publiko bat ere ez da barne-gune baten autoritatea.
Idatzi resolverraren helbidea, /32 bidea eta bezeroaren DNS ezarpena elkarrekin zerbitzariaren oharretan. Konfigurazio horren erdia bakarrik leheneratuta, hasierako hutsegitea berregiten du.
Azkenik, baieztatu tunelak aplikazioaren helmugara bideratzen jarraitzen duela DNSak arrakasta izan ondoren. Bideak, zerbitzuaren sarbideak eta autentifikazioak izen-ebazpenarekiko independente izaten jarraitzen dute, eta funtzionatzen duen bilaketa batek ez du ezer esaten transmisio-abiaduraz. Orri pribatua motela baina ebazten bada, resolverrak bere lana egin du eta arazoa bidera mugitu da.