Bigo ang pribadong DNS ng Pritunl? Magdagdag ng makitid na ruta ng resolver

Ang mga pribadong pangalan ay niresolba para sa lahat sa corporate network at nag-eexpire para sa lahat sa VPN. Sumasagot ang resolver sa gateway, may ruta papunta roon, at hindi pa rin kailanman nakakakuha ng sagot ang query. Ang kulang ay hindi isa pang pampublikong resolver o mas malawak na ruta: isang source address na handang sagutin ng pribadong DNS server.

Kumpirmahin na tinatanggihan ng resolver ang iyong pool ng kliyente

Magsimula sa pagpapatunay na ang pagkasira ay tungkol sa pinagmulan, hindi sa maabot. Mula sa konektadong kliyente, tanungin nang direkta ang pribadong resolver at panoorin kung nag-eexpire ang kahilingan o bumabalik bilang pagtanggi. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 na nag-eexpire habang ang parehong query mula sa gateway ay nagtatagumpay ay nagtuturo sa isang patakaran ng pag-access sa resolver. Ang sagot na SERVFAIL ay nagtuturo sa ibang lugar, karaniwang sa zone o sa upstream forwarder.

Itala ang address ng kliyente bago subukan. ip -4 addr show tun0 sa kliyente, o ang lease na ipinapakita sa console, ay nagsasabi kung aling pool ang nakikita ng resolver.

Pagkatapos ay kumpirmahin na umiiral ang landas. Ang rutang nagpapadala ng address ng resolver sa tunnel ay paunang kondisyon, hindi ang solusyon; kung hindi kailanman dumarating ang mga packet, hindi isinasaalang-alang ang patakaran ng pinagmulan. Suriin ito gamit ang ip route get 10.40.0.53 sa kliyente.

Magdagdag ng isang ruta ng host sa halip na isalin ang lahat

Inilalarawan ng gabay ng Pritunl sa pribadong DNS ang makitid na lunas: isang rutang /32 na may NAT para sa address ng resolver, na ang address na iyon ay pinili bilang DNS server ng mga kliyente. Binabago ng ruta ang pinagmulan na nakikita ng resolver para sa trapik ng DNS lamang. Pinapanatili ng trapik ng aplikasyon ang disenyong nagpapanatili ng pinagmulan na pinili mo para dito.

I-configure ito sa pamamagitan ng sinusuportahang may-ari ng ruta ng server, pagkatapos suriin ang mga umiiral na ruta para sa overlap. Sa halimbawa sa itaas ang destinasyon ay 10.40.0.53/32 na may NAT, at ang pool ng kliyente ay nananatiling 10.90.0.0/24. Huwag isalin ang buong pribadong saklaw para ayusin ang isang serbisyo, dahil bawat patakaran sa ibaba na umaasa sa tunay na address ng kliyente ay magsisimulang makita ang gateway sa halip. Kumpirmahin ang address na aktwal na natatanggap ng resolver sa pamamagitan ng panonood ng log ng query nito sa isang pagsubok na paghahanap. Ang ruta ng host lamang ay walang pinapatunayan tungkol sa pagsasalin o pahintulot.

Kailangan pa rin ng resolver na payagan ang isinaling pinagmulan sa UDP at TCP, at ang mga sagot nito ay dapat makabalik. Ang pagbabago ng pinagmulan ay hindi makakagawa ng nawawalang zone o record.

Magpasya kung ang server o ang kliyente ang nagpapadala ng query

Idinodokumento rin ng Pritunl ang isang kaayusan ng DNS proxy na nakatali sa VPN Client DNS Mapping, kung saan ipinapasa ng server ang mga upstream query para sa mga kliyente. Sa modelong iyon ang upstream na pinagmulan ay kabilang sa sariling konteksto ng network ng server, at ang eksepsiyon sa panig ng kliyente ay maling lunas.

Tukuyin kung aling modelo ang aktibo bago magdagdag ng anuman. Tatlong magkakapatong na pag-aayos, isang proxy, isang pag-override ng resolver sa kliyente at isang manu-manong NAT script ay karaniwang nangangahulugan na walang nagtatag: aling bahagi ang dapat magpadala ng query. Suriin din ang bootstrap: ang pribado-lamang resolver ay hindi maaaring maging tanging paraan upang mahanap ang endpoint bago umiral ang tunnel, at ang permanenteng pagbabago ng resolver ay hindi dapat tumagal nang higit sa koneksiyon.

Subukan ang pribadong paghahanap, hindi isang pampublikong web page

Pagkatapos ilapat ang pagbabago at muling kumonekta, siyasatin ang epektibong konfigurasyon ng resolver ng kliyente, pagkatapos ay resolbahin ang isang pangalan na alam mong umiiral lamang sa pribadong zone. dig intranet.example.net na walang tahasang server ay nagpapakita kung ano ang aktwal na ginagamit ng kliyente. Sundan ito ng kahilingan sa address na ibinalik ng paghahanap na iyon, dahil ang resolusyon at pag-access sa serbisyo ay magkahiwalay na hakbang. Ang browser na naglo-load ng mga pampublikong site sa pamamagitan ng DNS-over-HTTPS ay walang pinapatunayan tungkol sa pribadong landas ng resolver ng operating system. Ang pampublikong pangalawang resolver ay hindi rin awtoridad para sa isang panloob na zone.

Itala ang address ng resolver, ang rutang /32 at ang setting ng DNS ng kliyente nang magkasama sa mga tala ng server. Ang kalahati ng konfigurasyong iyon na ibinalik nang mag-isa ay muling gumagawa ng orihinal na pagkasira.

Sa wakas, kumpirmahin na ang tunnel ay nagruruta pa rin sa destinasyon ng aplikasyon pagkatapos magtagumpay ang DNS. Ang ruta, pag-access sa serbisyo at pagpapatotoo ay nananatiling independyente sa resolusyon ng pangalan, at ang gumaganang paghahanap ay walang sinasabi tungkol sa throughput. Kung mabagal ang pribadong pahina ngunit niresolba, ginawa ng resolver ang trabaho nito at lumipat ang problema sa landas.