Pritunli privaatne DNS ei tööta? Lisage kitsas resolveri marsruut
VPN-i basseini eirav privaatne resolver vajab allika erandit, mitte laiemat marsruuti. Lisage NAT-iga /32 ja testige tõelist privaatset otsingut.
Privaatsed nimed lahendatakse ettevõttevõrgus kõigi jaoks ja VPN-is aeguvad kõigi jaoks. Resolver vastab lüüsile, marsruut sinna on olemas, ja päring ei saa ikkagi kunagi vastust. Puudu ei ole teine avalik resolver ega laiem marsruut: puudu on allikaaadress, millele privaatne DNS-server on valmis vastama.
Kinnitage, et resolver keeldub teie kliendibasseinist
Alustage tõestusest, et tõrge on seotud allikaga, mitte kättesaadavusega. Ühendatud kliendist pärige privaatset resolverit otse ja jälgige, kas päring aegub või tuleb tagasi keeldumisena. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 aegumine, samal ajal kui sama päring lüüsist õnnestub, viitab resolveri juurdepääsupoliitikale. SERVFAILi vastus viitab hoopis mujale, tavaliselt tsoonile või ülemvoolu edastajale.
Enne testimist pange kliendi aadress kirja. ip -4 addr show tun0 kliendis või konsoolis näidatud liising ütleb, millist basseini resolver näeb.
Seejärel kinnitage, et tee üldse olemas on. Marsruut, mis saadab resolveri aadressi tunnelisse, on eeldus, mitte lahendus; kui paketid kunagi kohale ei jõua, ei konsulteerita allikapoliitikaga üldse. Kontrollige seda kliendis käsuga ip route get 10.40.0.53.
Lisage üks host-marsruut selle asemel, et kõike tõlkida
Pritunli privaatse DNS-i juhis kirjeldab kitsast lahendust: NAT-iga /32 marsruut resolveri aadressile, kusjuures see aadress on valitud klientide DNS-serveriks. Marsruut muudab allikat, mida resolver näeb, ainult DNS-liikluse jaoks. Rakenduste liiklus säilitab allikat säilitava disaini, mille te selle jaoks valisite.
Seadistage see serveri toetatud marsruudiomaniku kaudu pärast olemasolevate marsruutide ülekatte kontrollimist. Ülaltoodud näites on sihtkohaks NAT-iga 10.40.0.53/32 ja kliendibassein jääb 10.90.0.0/24. Ärge tõlkige kogu privaatset vahemikku ühe teenuse parandamiseks, sest iga allavoolu poliitika, mis tugineb kliendi tegelikule aadressile, hakkab selle asemel nägema lüüsi. Kinnitage aadress, mille resolver tegelikult saab, jälgides selle päringulogi testotsingu ajal. Üks host-marsruut iseenesest ei tõesta midagi tõlkimise ega loa kohta.
Resolver peab ikkagi lubama tõlgitud allikat UDP ja TCP kaudu ning selle vastused peavad saama tagasi tulla. Allika muutmine ei saa luua puuduvat tsooni ega kirjet.
Otsustage, kas päringu saadab server või klient
Pritunl dokumenteerib ka DNS-proxy lahenduse, mis on seotud VPN Client DNS Mappinguga, kus server edastab klientide eest ülemvoolu päringuid. Selles mudelis kuulub ülemvoolu allikas serveri enda võrgukonteksti, ja kliendipoolne erand on vale lahendus.
Enne millegi lisamist tehke kindlaks, milline mudel on aktiivne. Kolm kattuvat parandust, proxy, kliendi resolveri ülekirjutus ja käsitsi NAT-skript tähendavad tavaliselt, et keegi ei ole tuvastanud: milline komponent peaks päringu saatma. Kontrollige ka bootstrapi: ainult privaatne resolver ei saa olla ainus viis lõpp-punkti leidmiseks enne tunneli olemasolu, ja püsiv resolveri muudatus ei tohiks ühendust üle elada.
Testige privaatset otsingut, mitte avalikku veebilehte
Pärast muudatuse rakendamist ja uuesti ühendamist kontrollige kliendi kehtivat resolveri konfiguratsiooni ja lahendage seejärel nimi, mis teie teada eksisteerib ainult privaatses tsoonis. dig intranet.example.net ilma selge serverita näitab, mida klient tegelikult kasutab. Järgnevalt saatke päring aadressile, mille see otsing tagastas, sest lahendamine ja teenusele juurdepääs on eraldi sammud. Brauser, mis laadib avalikke saite DNS-over-HTTPSi kaudu, ei tõesta midagi operatsioonisüsteemi privaatse resolveri tee kohta. Ka avalik teisene resolver ei ole sisemise tsooni autoriteet.
Kirjutage resolveri aadress, /32 marsruut ja kliendi DNS-seade koos serveri märkmetesse. Pool sellest konfiguratsioonist üksi taastatuna taastoodab algse tõrke.
Lõpuks kinnitage, et tunnel suunab pärast DNS-i õnnestumist endiselt rakenduse sihtkohta. Marsruut, teenusele juurdepääs ja autentimine jäävad nimelahendusest sõltumatuks ning töötav otsing ei ütle läbilaskevõime kohta midagi. Kui privaatne leht on aeglane, kuid laheneb, tegi resolver oma töö ja probleem liikus teele.