Pritunl privatni DNS ne radi? Dodajte usku rutu rezolvera

Privatna imena se razreš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 nikada ne dobija odgovor. Ne nedostaje drugi javni rezolver ni šira ruta: nedostaje izvorna adresa na koju je privatni DNS server spreman da odgovori.

Potvrdite da rezolver odbija vaš klijentski pool

Počnite dokazom da je kvar vezan za izvor, a ne za dostupnost. Sa povezanog klijenta upitajte privatni rezolver direktno i gledajte da li zahtev 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 sa gatewaya uspeva, što ukazuje na politiku pristupa na rezolveru. Odgovor SERVFAIL ukazuje na nešto sasvim drugo, obično na zonu ili upstream prosleđivač.

Zabeležite adresu klijenta pre 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 rešenje; ako paketi nikada ne stignu, politika izvora se uopšte ne razmatra. Proverite to sa ip route get 10.40.0.53 na klijentu.

Dodajte jednu host rutu umesto da prevedete sve

Pritunlovo uputstvo za privatni DNS opisuje usko rešenje: ruta /32 sa uključenim NAT-om za adresu rezolvera, sa tom adresom izabranom kao DNS server klijenata. Ruta menja izvor koji rezolver vidi samo za DNS saobraćaj. Aplikacijski saobraćaj zadržava dizajn koji čuva izvor, a koji ste izabrali za njega.

Konfigurišite je preko podržanog vlasnika ruta na serveru, nakon što pregledate postojeće rute zbog preklapanja. U primeru iznad odredište je 10.40.0.53/32 sa uključenim NAT-om, a klijentski pool ostaje 10.90.0.0/24. Ne prevodite ceo privatni opseg da biste popravili jednu uslugu, jer će svaka nizvodna politika koja se oslanja na stvarnu adresu klijenta početi da vidi gateway umesto 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 da dopusti prevedeni izvor na UDP i TCP, a njegovi odgovori moraju moći da se vrate. Promena izvora ne može da stvori 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, gde server prosleđuje upstream upite u ime klijenata. U tom modelu upstream izvor pripada sopstvenom mrežnom kontekstu servera, a izuzetak na strani klijenta je pogrešno rešenje.

Utvrdite koji je model aktivan pre nego što bilo šta dodate. Tri preklapajuće popravke, proxy, zamena rezolvera na klijentu i ručna NAT skripta obično znače da niko nije ustanovio: koja komponenta treba da šalje upit. Proverite i bootstrap: samo-privatni rezolver ne može biti jedini način da se pronađe krajnja tačka pre nego što tunel postoji, a trajna izmena rezolvera ne bi trebalo da nadživi vezu.

Testirajte privatnu pretragu, a ne javnu web stranicu

Nakon primene promene i ponovnog povezivanja pregledajte efektivnu konfiguraciju rezolvera na klijentu, zatim razrešite ime za koje znate da postoji samo u privatnoj zoni. dig intranet.example.net bez izričitog servera pokazuje šta klijent zaista koristi. Zatim uputite zahtev na adresu koju je ta pretraga vratila, jer su razreš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 beleške servera. Polovina te konfiguracije, vraćena sama, reprodukuje prvobitni kvar.

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