Bakit nagre-resolve ang pangalan ng server sa address ng VPN nito pagkatapos ng dial-in

Isang file server sa opisina ang sumasagot sa LAN address nito buong umaga, tapos may malayong user na nag-dial-in at ang pangalan ay nagsisimulang mag-resolve sa isang tunnel address sa halip. Walang na-edit sa DNS nang manu-mano, at iyon ang palatandaan: ang record ay inilathala ng makina mismo. Tatlong kondisyon ang nagpapasya kung aayusin mo ang registrar, ang record, o ang pananaw ng kliyente, at ang maling pagkakasunod-sunod ay nangangahulugang babalik ang record pagkatapos ng susunod na koneksyon.

Dalawang address, isang pangalan, tatlong kondisyon

Ang Windows server na may maraming interface ay maaaring may LAN address, isa o higit pang dial-in address, at kung minsan ay pangalawang network card. Maaaring irehistro ng bawat interface ang sarili nitong mga address sa DNS kung pinapayagan ito ng dynamic na pagpaparehistro. Kapag nagrehistro ang PPP adapter, ang parehong host name ay nakakakuha ng address na tanging ang kapares ng tunnel ang maaaring maabot, at natatanggap ito ng mga kliyente ng LAN bilang valid na sagot.

Tatlong kondisyon ang nagpapasya sa pag-aayos. Una, naaabot ba ang karagdagang address mula sa mga kliyenteng tumatanggap nito? Pangalawa, may consumer pa bang umaasa sa pagpaparehistrong iyon? Pangatlo, dynamic ba ang record at kaya ay maaaring bumalik, o static at kaya ay sinadyang entry?

Sagutin iyon bago hawakan ang anuman. Kung hindi naaabot ang address mula sa network na nagtatanong, walang paglilinis ng cache ng kliyente ang makakaayos nito nang matagal. Kung may isang bagay na umaasa rito, tulad ng management path na ginagamit ng mga kapares ng tunnel mismo, ang pag-alis nito ay sisirain ang path na iyon sa halip. At ang dynamic na record na binura nang hindi inaayos ang naglathala nito ay muling lilitaw sa susunod na kaganapan ng pagpaparehistro.

Basahin ang record bago baguhin ang registrar

Itanong ang eksaktong ganap na kwalipikadong pangalan mula sa network na nag-uulat ng problema, at ihambing ang mga sagot sa aktwal na interface at listener ng server. Normal lang na isang pangalan ang nagbabalik ng maraming address; ang tanong ay kung ang bawat isa ay magagamit ng kliyenteng tumatanggap nito.

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

Ang unang query ay gumagamit ng lokal na resolver, ang pangalawa ay direktang nagtatanong sa isang partikular na DNS server, at ang pangatlo ay ganoon din mula sa PowerShell sa Windows. Ang paghahambing sa kanila ay naghihiwalay ng lumang cache ng kliyente mula sa awtoritatibong sagot. Kung ang direktang query ay nagbabalik na ng tunnel address, ang problema ay ang na-publish na data at hindi ang lokal na caching.

Isulat ang timestamp ng record at kung ipinapakita ito ng DNS console bilang dynamic. Ang nag-iisang katangiang iyon ay nagsasabi kung alin sa tatlong kondisyon sa itaas ang naaangkop, at iyon ang pagkakaiba ng limang minutong paglilinis at ng pag-aayos na tumatagal.

Ayusin ang naglathala o ang record, pero alamin kung alin

Kung ang record ay dynamic at hindi kanais-nais, ang matibay na pag-aayos ay pigilan ang interface na iyon sa pagpaparehistro. Nag-aalok ang Windows ng mga setting ng pagpaparehistro kada interface, at muling naglalathala ang serbisyo ng kliyente ng DNS sa susunod na koneksyon o pagbabago ng address. Ang pag-off ng pagpaparehistro para sa dial-in adapter ay iniiwan ang pagpaparehistro ng LAN adapter na buo, na karaniwang iyon ang gusto mo.

Mag-ingat sa mga switch na para sa buong makina. Ang global na setting na nagpapawalang-bisa sa dynamic na update ay nakakaapekto sa bawat interface sa host na iyon, kabilang ang isa na inaasahan ng ibang kliyente ang pagpaparehistro. Sa domain controller, ang parehong pag-iingat ay mas malakas ang bisa, dahil maaaring nagmamay-ari rin ang host ng mga service location record na inaasahan ng mga kliyente para makapasok.

Kung ang record ay static, sadyang inilagay ito roon at ang usapan ay sa taong naglagay nito. Ang pagbura ng static na record dahil hindi ito komportable ngayon ay nag-aalis ng tanging ebidensya kung bakit ito umiiral. Sa dalawang kaso, burahin ang lumang sagot pagkatapos lamang maayos ang naglathala, at itala ang binago mo para makilala ng susunod na tao ang sinadyang entry mula sa aksidente.

I-verify mula sa network ng kliyenteng nabigo

Ang verification ay para sa network na nag-ulat ng sintomas, hindi para sa server. Linisin ang cache ng resolver ng kliyente sa pamamagitan ng sinusuportahang mekanismo nito, pagkatapos ulitin ang orihinal na paghahanap at ang orihinal na koneksyon sa serbisyo ayon sa pangalan.

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

Nililinis ng unang command ang cache ng resolver ng Windows, at ang pangalawa ay nagpapakita kung naka-cache muli ang pangalan at aling address ang na-save. Ang matagumpay na koneksyon ng server sa sarili nito ay walang pinapatunayan tungkol sa isang kliyente ng LAN, at ang pag-alis ng ruta patungo sa hindi kanais-nais na address ay hindi nagwawasto sa inilalathala ng DNS.

Sa huli, ulitin ang kaganapang dating nagpapasok ng address: muling ikonekta ang kliyente ng VPN, o i-renew ang sesyon ng dial-in. Suriin muli ang na-publish na pangalan pagkatapos ng pagbabagong iyon sa lifecycle. Ang pag-aayos na tumatagal lamang hanggang sa susunod na koneksyon ay paglilinis, hindi pag-aayos, at ang pag-alam kung alin sa dalawa ang ginawa mo ay ang pagkakaiba ng pagsasara ng ticket at ng muling pagbubukas nito sa susunod na linggo.