Ĉu la privata DNS de Pritunl malsukcesas? Aldonu mallarĝan itineron por solvilo

Privataj nomoj solviĝas por ĉiuj en la entreprena reto kaj tempolimas por ĉiuj en la VPN. La solvilo respondas la enirejon, la itinero al ĝi ekzistas, kaj la demando tamen neniam ricevas respondon. Mankas ne alia publika solvilo aŭ pli vasta itinero: mankas fonta adreso, al kiu la privata DNS-servilo pretas respondi.

Konfirmu, ke la solvilo rifuzas vian klientan basenon

Komencu per pruvo, ke la fiasko koncernas la fonton, ne la atingeblon. De konektita kliento, demandu la privatan solvilon rekte kaj observu, ĉu la peto tempolimas aŭ revenas kiel rifuzo. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 tempolimanta dum la sama demando de la enirejo sukcesas indikas alirpolitikon ĉe la solvilo. Respondo SERVFAIL indikas tute alian lokon, kutime la zonon aŭ la supran plusendilon.

Notu la adreson de la kliento antaŭ la testado. ip -4 addr show tun0 ĉe la kliento, aŭ la luo montrata en la konzolo, diras al vi, kiun basenon la solvilo vidas.

Poste konfirmu, ke la vojo entute ekzistas. Itinero, kiu sendas la adreson de la solvilo en la tunelon, estas antaŭkondiĉo, ne la solvo; se pakoj neniam alvenas, la fontpolitiko tute ne estas konsultata. Kontrolu tion per ip route get 10.40.0.53 ĉe la kliento.

Aldonu unu gastigan itineron anstataŭ traduki ĉion

La gvidilo de Pritunl pri privata DNS priskribas la mallarĝan rimedon: itinero /32 kun ebligita NAT por la adreso de la solvilo, kun tiu adreso elektita kiel DNS-servilo de la klientoj. La itinero ŝanĝas la fonton, kiun la solvilo vidas, nur por DNS-trafiko. Aplikaĵa trafiko konservas la fontkonservan dezajnon, kiun vi elektis por ĝi.

Agordu ĝin per la subtenata itinposedanto de la servilo, post revizio de ekzistantaj itineroj por interkovro. En la supra ekzemplo la celo estas 10.40.0.53/32 kun ebligita NAT, kaj la klienta baseno restas 10.90.0.0/24. Ne traduku la tutan privatan gamon por ripari unu servon, ĉar ĉiu malsupra politiko, kiu fidas la realan adreson de la kliento, komencos vidi la enirejon anstataŭe. Konfirmu la adreson, kiun la solvilo efektive ricevas, observante ĝian demandoprotokolon dum testa serĉo. Gastiga itinero sola pruvas nenion pri tradukado aŭ permeso.

La solvilo ankoraŭ devas permesi la tradukitan fonton sur UDP kaj TCP, kaj ĝiaj respondoj devas povi reveni. Ŝanĝi la fonton ne povas krei mankantan zonon aŭ rikordon.

Decidu, ĉu la servilo aŭ la kliento sendas la demandon

Pritunl ankaŭ dokumentas DNS-prokuran aranĝon ligitan al VPN Client DNS Mapping, kie la servilo plusendas suprajn demandojn por klientoj. En tiu modelo la supra fonto apartenas al la propra reta kunteksto de la servilo, kaj escepto ĉe la klienta flanko estas la malĝusta solvo.

Identigu, kiu modelo aktivas, antaŭ ol aldoni ion ajn. Tri interkovrantaj riparoj, prokuro, anstataŭigo de la solvilo ĉe la kliento kaj mana NAT-skripto kutime signifas, ke neniu establis: kiu komponanto devas sendi la demandon. Kontrolu ankaŭ bootstrap: nur-privata solvilo ne povas esti la sola maniero trovi la finpunkton antaŭ ol la tunelo ekzistas, kaj daŭra ŝanĝo de la solvilo ne devus postvivi la konekton.

Testu privatan serĉon, ne publikan retpaĝon

Post apliki la ŝanĝon kaj rekonekti, inspektu la efektivan solvilan agordon de la kliento, poste solvu nomon, pri kiu vi scias, ke ĝi ekzistas nur en la privata zono. dig intranet.example.net sen eksplicita servilo montras, kion la kliento efektive uzas. Sekvu tion per peto al la adreso, kiun tiu serĉo redonis, ĉar solvado kaj serva aliro estas apartaj paŝoj. Retumilo, kiu ŝargas publikajn retejojn per DNS-over-HTTPS, pruvas nenion pri la privata solvila vojo de la operaciumo. Ankaŭ publika sekundara solvilo ne estas aŭtoritato por interna zono.

Notu la adreson de la solvilo, la itineron /32 kaj la DNS-agordon de la kliento kune en la servilaj notoj. Duono de tiu agordo, restarigita sola, reproduktas la originalan fiaskon.

Fine, konfirmu, ke la tunelo ankoraŭ enkursigas la aplikaĵan celon post kiam DNS sukcesas. Itinero, serva aliro kaj aŭtentikigo restas sendependaj de nomosolvado, kaj funkcianta serĉo diras nenion pri trairo. Se la privata paĝo estas malrapida sed solviĝas, la solvilo faris sian laboron kaj la problemo moviĝis al la vojo.