Privatna imena razrješavaju se za sve na korporativnoj mreži i istječu za sve na VPN-u. Rezolver odgovara gatewayu, ruta do njega postoji, a upit ipak nikad ne dobije odgovor. Ne nedostaje drugi javni rezolver ni šira ruta: nedostaje izvorna adresa na koju je privatni DNS poslužitelj spreman odgovoriti.

Potvrdite da rezolver odbija vaš klijentski pool

Počnite dokazom da je kvar vezan uz izvor, a ne uz dostupnost. S povezanog klijenta upitajte privatni rezolver izravno i gledajte istječe li zahtjev ili se vraća kao odbijanje. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 istječe dok isti upit s gatewaya uspijeva, što upućuje na politiku pristupa na rezolveru. Odgovor SERVFAIL upućuje na nešto posve drugo, obično na zonu ili upstream prosljeđivač.

Zabilježite adresu klijenta prije testiranja. ip -4 addr show tun0 na klijentu, ili najam prikazan u konzoli, govori vam koji pool rezolver vidi.

Zatim potvrdite da put uopće postoji. Ruta koja šalje adresu rezolvera u tunel preduvjet je, a ne rješenje; ako paketi nikad ne stignu, politika izvora uopće se ne razmatra. Provjerite to s ip route get 10.40.0.53 na klijentu.

Dodajte jednu host rutu umjesto da prevedete sve

Pritunlovo uputstvo za privatni DNS opisuje usko rješenje: ruta /32 s uključenim NAT-om za adresu rezolvera, s tom adresom odabranom kao DNS poslužitelj klijenata. Ruta mijenja izvor koji rezolver vidi samo za DNS promet. Aplikacijski promet zadržava dizajn koji čuva izvor, a koji ste odabrali za njega.

Konfigurirajte je preko podržanog vlasnika ruta na poslužitelju, nakon što pregledate postojeće rute zbog preklapanja. U primjeru iznad odredište je 10.40.0.53/32 s uključenim NAT-om, a klijentski pool ostaje 10.90.0.0/24. Ne prevodite cijeli privatni raspon da biste popravili jednu uslugu, jer će svaka nizvodna politika koja se oslanja na stvarnu adresu klijenta početi viđati gateway umjesto nje. Potvrdite adresu koju rezolver zapravo prima gledajući njegov dnevnik upita tijekom probne pretrage. Sama host ruta ne dokazuje ništa o prevođenju ili dopuštenju.

Rezolver i dalje mora dopustiti prevedeni izvor na UDP i TCP, a njegovi odgovori moraju moći vratiti se. Promjena izvora ne može stvoriti zonu ili zapis koji nedostaje.

Odlučite šalje li upit poslužitelj ili klijent

Pritunl dokumentira i DNS-proxy aranžman vezan uz VPN Client DNS Mapping, gdje poslužitelj prosljeđuje upstream upite u ime klijenata. U tom modelu upstream izvor pripada vlastitom mrežnom kontekstu poslužitelja, a izuzetak na strani klijenta pogrešno je rješenje.

Utvrdite koji je model aktivan prije nego što bilo što dodate. Tri preklapajuća popravka, proxy, zamjena rezolvera na klijentu i ručna NAT skripta obično znače da nitko nije ustanovio: koja komponenta treba slati upit. Provjerite i bootstrap: samo-privatni rezolver ne može biti jedini način pronalaženja krajnje točke prije nego tunel postoji, a trajna izmjena rezolvera ne bi trebala nadživjeti vezu.

Testirajte privatnu pretragu, a ne javnu web stranicu

Nakon primjene promjene i ponovnog povezivanja pregledajte efektivnu konfiguraciju rezolvera na klijentu, zatim razriješite ime za koje znate da postoji samo u privatnoj zoni. dig intranet.example.net bez izričitog poslužitelja pokazuje što klijent zapravo koristi. Zatim uputite zahtjev na adresu koju je ta pretraga vratila, jer su razrješavanje i pristup usluzi odvojeni koraci. Preglednik koji učitava javne stranice preko DNS-over-HTTPS ne dokazuje ništa o putu privatnog rezolvera operacijskog sustava. Ni javni sekundarni rezolver nije autoritet za internu zonu.

Zapišite adresu rezolvera, rutu /32 i DNS postavku klijenta zajedno u bilješke poslužitelja. Polovica te konfiguracije, vraćena sama, reproducira izvorni kvar.

Na kraju potvrdite da tunel i dalje usmjerava odredište aplikacije nakon što DNS uspije. Ruta, pristup usluzi i autentifikacija ostaju neovisni o razrješavanju imena, a pretraga koja radi ne govori ništa o propusnosti. Ako je privatna stranica spora ali se razrješava, rezolver je obavio svoj posao i problem se preselio na put.

Povezani članci