Pritunl privatni DNS ne radi? Dodajte usku rutu rezolvera

Privatna imena se razrješavaju za sve na korporativnoj mreži i istič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 server spreman odgovoriti.

Potvrdite da rezolver odbija vaš klijentski pool

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

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

Zatim potvrdite da put uopšte postoji. Ruta koja šalje adresu rezolvera u tunel je preduslov, a ne rješenje; ako paketi nikad ne stignu, politika izvora se uopšte ne konsultuje. 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 server klijenata. Ruta mijenja izvor koji rezolver vidi samo za DNS saobraćaj. Aplikacijski saobraćaj zadržava dizajn koji čuva izvor, a koji ste odabrali za njega.

Konfigurišite je preko podržanog vlasnika ruta na serveru, 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 opseg 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 zaista prima gledajući njegov dnevnik upita tokom probne pretrage. Sama host ruta ne dokazuje ništa o prevođenju ili dozvoli.

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

Odlučite da li upit šalje server ili klijent

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

Utvrdite koji je model aktivan prije nego što bilo šta dodate. Tri preklapajuće popravke, proxy, zamjena rezolvera na klijentu i ručna NAT skripta obično znače da niko nije ustanovio: koja komponenta treba da šalje upit. Provjerite i bootstrap: samo-privatni rezolver ne može biti jedini način da se pronađe endpoint prije nego tunel postoji, a trajna izmjena rezolvera ne treba da nadživi 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 eksplicitnog servera pokazuje šta klijent zaista koristi. Zatim uputite zahtjev na adresu koju je ta pretraga vratila, jer su razrješavanje i pristup usluzi odvojeni koraci. Pretraživač koji učitava javne stranice preko DNS-over-HTTPS ne dokazuje ništa o putu privatnog rezolvera operativnog sistema. Ni javni sekundarni rezolver nije autoritet za internu zonu.

Zapišite adresu rezolvera, rutu /32 i DNS postavku klijenta zajedno u bilješke servera. Polovina te konfiguracije, vraćena sama, reprodukuje prvobitni kvar.

Na kraju potvrdite da tunel i dalje rutira odredište aplikacije nakon što DNS uspije. Ruta, pristup usluzi i autentifikacija ostaju nezavisni od razrješavanja 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.