Pritunl privātais DNS neizdodas? Pievienojiet šauru resolver maršrutu

Privātie nosaukumi tiek atrisināti visiem uzņēmuma tīklā un beidzas pēc laika visiem VPN. Resolveris atbild vārtejai, maršruts uz to pastāv, un vaicājums tomēr nekad nesaņem atbildi. Trūkst nevis cita publiska resolvera vai plašāka maršruta: trūkst avota adreses, kurai privātais DNS serveris ir gatavs atbildēt.

Pārliecinieties, ka resolveris atsaka jūsu klientu baseinu

Sāciet ar pierādījumu, ka kļūme attiecas uz avotu, nevis sasniedzamību. No pievienota klienta vaicājiet privāto resolveri tieši un vērojiet, vai pieprasījums beidzas pēc laika vai atgriežas kā atteikums. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 beidzoties pēc laika, kamēr tas pats vaicājums no vārtejas izdodas, norāda uz piekļuves politiku resolverī. SERVFAIL atbilde norāda uz pavisam citu vietu, parasti zonu vai augšupējo pārsūtītāju.

Pirms testēšanas pierakstiet klienta adresi. ip -4 addr show tun0 klientā vai konsolē redzamā noma pasaka, kuru baseinu resolveris redz.

Pēc tam pārliecinieties, ka ceļš vispār pastāv. Maršruts, kas sūta resolvera adresi tunelī, ir priekšnoteikums, nevis risinājums; ja paketes nekad neierodas, avota politika netiek aplūkota. Pārbaudiet to klientā ar ip route get 10.40.0.53.

Pievienojiet vienu resursdatora maršrutu, nevis tulkojiet visu

Pritunl privātā DNS norādes apraksta šauro risinājumu: /32 maršruts ar NAT resolvera adresei, un šī adrese tiek izvēlēta kā klientu DNS serveris. Maršruts maina avotu, ko resolveris redz, tikai DNS trafikam. Lietojumprogrammu trafiks saglabā jūsu izvēlēto avotu saglabājošo dizainu.

Konfigurējiet to ar servera atbalstīto maršrutu īpašnieku, pirms tam pārbaudot esošos maršrutus attiecībā uz pārklāšanos. Iepriekšējā piemērā galamērķis ir 10.40.0.53/32 ar ieslēgtu NAT, un klientu baseins paliek 10.90.0.0/24. Netulkojiet visu privāto diapazonu, lai salabotu vienu pakalpojumu, jo katra lejupējā politika, kas paļaujas uz klienta reālo adresi, sāks redzēt tās vietā vārteju. Pārliecinieties par adresi, ko resolveris faktiski saņem, pārbaudes meklējuma laikā vērojot tā vaicājumu žurnālu. Viens resursdatora maršruts pats par sevi neko nepierāda par tulkošanu vai atļauju.

Resolvers joprojām ir jāatļauj tulkotais avots UDP un TCP, un tā atbildēm ir jāspēj atgriezties. Avota maiņa nevar radīt trūkstošu zonu vai ierakstu.

Izlemiet, vai vaicājumu sūta serveris vai klients

Pritunl dokumentē arī DNS starpniekservera izkārtojumu, kas saistīts ar VPN Client DNS Mapping, kur serveris pārsūta augšupējos vaicājumus klientu vietā. Šajā modelī augšupējais avots pieder paša servera tīkla kontekstam, un izņēmums klienta pusē ir nepareizais risinājums.

Pirms kaut ko pievienojat, nosakiet, kurš modelis ir aktīvs. Trīs pārklājoši labojumi, starpniekserveris, resolvera aizstāšana klientā un manuāls NAT skripts parasti nozīmē, ka neviens nav noteicis: kuram komponentam jāsūta vaicājums. Pārbaudiet arī bootstrap: tikai privāts resolver nevar būt vienīgais veids, kā atrast galapunktu pirms tuneļa pastāvēšanas, un pastāvīgai resolvera izmaiņai nevajadzētu pārdzīvot savienojumu.

Pārbaudiet privātu meklējumu, nevis publisku tīmekļa lapu

Pēc izmaiņu piemērošanas un atkārtotas pievienošanas pārbaudiet klienta faktisko resolver konfigurāciju, pēc tam atrisiniet nosaukumu, kas, jūsu zināšanai, pastāv tikai privātajā zonā. dig intranet.example.net bez skaidra servera parāda, ko klients faktiski izmanto. Pēc tam nosūtiet pieprasījumu uz adresi, ko atgrieza šis meklējums, jo atrisināšana un piekļuve pakalpojumam ir atsevišķi soļi. Pārlūks, kas ielādē publiskas vietnes caur DNS-over-HTTPS, neko nepierāda par operētājsistēmas privāto resolver ceļu. Arī publisks sekundārais resolvers nav autoritāte iekšējai zonai.

Pierakstiet resolvera adresi, /32 maršrutu un klienta DNS iestatījumu kopā servera piezīmēs. Puse no šīs konfigurācijas, atjaunota atsevišķi, atkārto sākotnējo kļūmi.

Visbeidzot, pārliecinieties, ka tunelis joprojām maršrutē lietojumprogrammas galamērķi pēc tam, kad DNS izdodas. Maršruts, piekļuve pakalpojumam un autentifikācija paliek neatkarīgi no nosaukumu atrisināšanas, un strādājošs meklējums neko nepasaka par caurlaidspēju. Ja privātā lapa ir lēna, bet tiek atrisināta, resolveris izdarīja savu darbu, un problēma pārcēlās uz ceļu.