DNS-ul privat Pritunl eșuează? Adăugați o rută îngustă pentru resolver

Numele private se rezolvă pentru toți în rețeaua corporativă și expiră pentru toți în VPN. Resolverul răspunde gateway-ului, ruta către el există, iar interogarea tot nu primește niciodată răspuns. Ce lipsește nu este un alt resolver public sau o rută mai largă: este o adresă de sursă la care serverul DNS privat este dispus să răspundă.

Confirmați că resolverul refuză pool-ul de clienți

Începeți prin a demonstra că defecțiunea ține de sursă, nu de accesibilitate. Dintr-un client conectat, interogați direct resolverul privat și observați dacă cererea expiră sau revine ca refuz. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 care expiră în timp ce aceeași interogare de la gateway reușește indică o politică de acces pe resolver. Un răspuns SERVFAIL indică un cu totul alt loc, de obicei zona sau forwarder-ul superior.

Notați adresa clientului înainte de test. ip -4 addr show tun0 pe client, sau lease-ul afișat în consolă, vă spune ce pool vede resolverul.

Apoi confirmați că traseul există. O rută care trimite adresa resolverului în tunel este o condiție prealabilă, nu soluția; dacă pachetele nu ajung niciodată, politica de sursă nu este niciodată consultată. Verificați cu ip route get 10.40.0.53 pe client.

Adăugați o rută de gazdă în loc să traduceți totul

Ghidul Pritunl pentru DNS privat descrie remediul îngust: o rută /32 cu NAT pentru adresa resolverului, cu acea adresă aleasă ca server DNS al clienților. Ruta schimbă sursa pe care o vede resolverul doar pentru traficul DNS. Traficul aplicațiilor păstrează designul care păstrează sursa ales de dumneavoastră.

Configurați-o prin proprietarul de rute acceptat al serverului, după ce ați verificat rutele existente pentru suprapuneri. În exemplul de mai sus destinația este 10.40.0.53/32 cu NAT activat, iar pool-ul de clienți rămâne 10.90.0.0/24. Nu traduceți întregul interval privat pentru a repara un singur serviciu, deoarece fiecare politică din aval care se bazează pe adresa reală a clientului va începe să vadă gateway-ul în schimb. Confirmați adresa pe care resolverul o primește efectiv urmărind jurnalul de interogări în timpul unei căutări de test. O rută de gazdă singură nu dovedește nimic despre traducere sau permisiune.

Resolverul trebuie încă să permită sursa tradusă pe UDP și TCP, iar răspunsurile sale trebuie să poată reveni. Schimbarea sursei nu poate crea o zonă sau o înregistrare lipsă.

Decideți dacă serverul sau clientul trimite interogarea

Pritunl documentează și o configurație de proxy DNS legată de VPN Client DNS Mapping, în care serverul redirecționează interogările superioare pentru clienți. În acel model sursa superioară aparține contextului de rețea propriu al serverului, iar o excepție pe partea clientului este soluția greșită.

Identificați care model este activ înainte de a adăuga ceva. Trei reparații suprapuse, un proxy, o suprascriere a resolverului pe client și un script NAT manual înseamnă de obicei că nimeni nu a stabilit: care componentă ar trebui să trimită interogarea. Verificați și bootstrap: un resolver doar privat nu poate fi singura cale de a găsi punctul final înainte ca tunelul să existe, iar o modificare permanentă a resolverului nu ar trebui să supraviețuiască conexiunii.

Testați o căutare privată, nu o pagină web publică

După aplicarea modificării și reconectare, inspectați configurația efectivă a resolverului clientului, apoi rezolvați un nume despre care știți că există doar în zona privată. dig intranet.example.net fără un server explicit arată ce folosește clientul efectiv. Urmați cu o cerere către adresa returnată de acea căutare, deoarece rezolvarea și accesul la serviciu sunt pași separați. Un browser care încarcă site-uri publice prin DNS-over-HTTPS nu dovedește nimic despre calea resolverului privat al sistemului de operare. Un resolver secundar public nu este nici autoritate pentru o zonă internă.

Notați adresa resolverului, ruta /32 și setarea DNS a clientului împreună în notele serverului. Jumătate din acea configurație restaurată singură reproduce defecțiunea inițială.

În final, confirmați că tunelul rutează în continuare destinația aplicației după ce DNS reușește. Ruta, accesul la serviciu și autentificarea rămân independente de rezolvarea numelor, iar o căutare funcțională nu spune nimic despre debit. Dacă pagina privată este lentă dar se rezolvă, resolverul și-a făcut treaba și problema s-a mutat pe traseu.