Kinontrol ng VPN ang DNS at sinira ang mga lokal na pangalan: ayusin ang listahan

Bumangon ang tunnel, nag-load ang intranet, at tumigil sa pagresolba ang pangalan ng printer. O kabaliktaran: gumagana pa rin ang mga lokal na pangalan habang nauubos ang oras ng lahat sa loob ng corporate network. Ang dalawang sintomas ay galing sa isang lugar, isang listahan ng mga resolver na muling isinulat ng kliyenteng VPN nang kumonekta ito.

Ayusin ang listahan nang sinasadya, pagkatapos ay hiwalay na harapin ang push mechanism. Ang mga ruta ay ikatlong paksa at hindi ang inaayos dito.

Aling listahan ang talagang ginagamit ng mga aplikasyon

Nagresolba ang Windows sa pamamagitan ng mga setting sa antas ng interface at hindi sa kung ano ang ipinapakita ng isang dialog, kaya simulan sa mga epektibong listahan ng bawat interface. Mas mahalaga ang alias kaysa ipinapakitang pangalan, dahil bawat utos sa ibaba ay tumutukoy sa isang interface. Magkamali sa alias at mapupunta ang pag-aayos sa maling adapter. Mukhang gagana ito hanggang sa susunod na pagkonekta muli, kapag bumalik ang entry ng tunnel mismo.

Ang tanong ay aling mga server ang napunta sa unahan, at kung dumating sila bilang mga static na entry o bilang DHCP lease. Ang dalawang katotohanan ang nagtatakda kung aling pag-aayos ang makukuha mo.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Basahin ang output para sa adapter ng tunnel at para sa pisikal na adapter, at itala ang bawat address sa bawat isa. Ang static na entry ay maaaring tanggalin ng patakaran o script; ang entry na ibinigay ng DHCP ay nakatali sa lease at babalik, na nagbabago sa pag-aayos na dapat mong piliin. Ang mga pangalan sa malayong network ay niresolba ng inanunsyong resolver, ang mga pangalan sa lokal na LAN ng pisikal na adapter, at ang query ay pumupunta sa listahang unang sinasangguni.

Alisin ang mga itinulak na server, o ilagay sila nang mas mababa

Burahin ang mga itinulak na server kapag wala sa loob ng tunnel ang nangangailangan sa kanila, dahil muling kumukuha ng trabaho ang sariling resolver ng pisikal na adapter. Itago lamang sila kung ang malayong network ay may mga zone na tanging mga server nito ang makakasagot, at sa ganoong kaso maglagay ng lokal na resolver sa harap nila. Ang dalawang utos sa ibaba ay sumasaklaw sa parehong pagpipilian, kaya piliin ang bagay sa sitwasyon sa halip na patakbuhin ang dalawa.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

Ang index 1 ay unang sinasangguni, kaya nananatiling magagamit ang mga itinulak na address ngunit hindi na sila ang default na sagot sa bawat query. Nilalaktawan ng flag na validate=no ang isang pagsubok sa maabot na kadalasang nabibigo habang nagiging matatag pa ang tunnel, kaya tiyakin ang resulta gamit ang utos na show sa halip na magtiwala sa exit code.

Dalawang limitasyon ang dapat malaman bago umasa dito. Hindi buburahin ng Windows ang mga server na dumating sa pamamagitan ng DHCP sa pamamagitan ng netsh, at ang mga halagang iyon ay nananatili bilang DhcpNameServer sa ilalim ng registry key ng interface, kaya ang pag-edit ng registry ay huling paraan na kailangang muling suriin pagkatapos ng susunod na lease. Ang pagkakasunod-sunod ng pagbinding ng adapter ay hindi rin mapagkakatiwalaang mekanismo ng ranggo, dahil maaaring magpasok ang kliyenteng VPN ng sariling entry sa tuktok ng listahan.

Saan maaaring salain ang push

Ang mas mahusay na pag-aayos ay nag-aalis ng opsyon bago ito ilapat. Maaaring salain ng kliyenteng Community OpenVPN ang itinulak na direktiba ayon sa pangalan, na iniiwan ang configuration ng server na hindi nagalaw.

pull-filter ignore "dhcp-option DNS "

Ang espasyo sa dulo ay bahagi ng pagtutugma at pinangalanan ng filter ang opsyon at hindi ang address ng server. Kung ang profile ay naglalaman din ng direktibang block-outside-dns, ang pag-alis nito ay nagbabago ng proteksyon sa pagtagas at hindi ang pagresolba ng pangalan, kaya pagpasyahan iyon nang hiwalay sa halip na pagsamahin ang dalawang pag-edit.

Para sa isang matigas ang ulong hostname, ang isang linya sa hosts file ng Windows ay mas matatag kaysa muling pag-aayos ng mga resolver para sa buong makina. Hindi rin ito nakikita ng susunod na tao, kaya itala ito kung saan nakadokumento ang configuration ng makina.

Gawing nakakaligtas ang pag-aayos sa pagkonekta muli

Kailangang subukan ang pagresolba ng pangalan nang dalawang beses, isang beses laban sa piniling server at isang beses sa anyo na ginagamit ng isang aplikasyon. Hinihiwalay ng pares na iyon ang problema sa pagkakasunod-sunod ng resolver mula sa server na hindi sumasagot talaga. Kapag nilaktawan ang unang pagsubok, nananatiling magkabuhol ang dalawang dahilan.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Kumonekta muli sa tunnel at ulitin ang dalawang utos. Ang binago mo nang manwal ay tumatagal lamang hanggang sa susunod na koneksyon, dahil muling binubuo ng kliyente ang estado ng resolver habang itinataas ang adapter. Ilagay ang mga linya ng netsh sa sinusuportahang script ng koneksyon ng iyong kliyente, hayaan ang script na iyon na matapos nang matagumpay, at magdagdag ng maikling paghihintay bago ito tumakbo. Ang kliyenteng naglalapat ng DNS pagkatapos ng script ay magpapatong pa rin sa resulta.

Kung niresolba ang mga pampublikong pangalan at nabibigo pa rin ang mga panloob pagkatapos ng pag-aayos, hindi na suspect ang listahan ng resolver. Malamang na hindi na umaabot ang query sa server, na tumutukoy sa routing o patakaran ng firewall at hindi sa isa pang setting ng DNS. Itala ang alias ng interface at ang mga address na napagkasunduan mo, dahil magkaiba ang dalawa sa bawat makina at wala sa kanila ang nakakaligtas nang mag-isa sa muling pagbuo.