Kial servila nomo post telefona ensaluto solviĝas al sia VPN-adreso

Oficeja dosierservilo respondas sur sia LAN-adreso la tutan matenon, poste fora uzanto ensalutas telefone kaj la nomo komencas solviĝi al tunea adreso anstataŭe. Nenio estis permane redaktita en DNS, kaj tio estas la indico: la rikordon publikigis la maŝino mem. Tri kondiĉoj decidas ĉu vi ripari la registranton, la rikordon aŭ la vidon de la kliento, kaj malĝusta ordo signifas ke la rikordo revenos post la sekva konekto.

Du adresoj, unu nomo, tri kondiĉoj

Windows-servilo kun pluraj retinterfacoj povas havi LAN-adreson, unu aŭ plurajn telefonajn adresojn kaj foje duan retkarton. Ĉiu interfaco povas registri siajn proprajn adresojn en DNS se dinamika registrado estas permesita por ĝi. Kiam la PPP-adaptilo registriĝas, la sama gastiga nomo akiras adreson kiun nur la tunela kunulo povas atingi, kaj LAN-klientoj ricevas ĝin kiel validan respondon.

Tri kondiĉoj decidas la riparon. Unue, ĉu la plia adreso estas atingebla de la klientoj kiuj ricevas ĝin? Due, ĉu iu konsumanto ankoraŭ dependas de tiu registrado? Trie, ĉu la rikordo estas dinamika kaj do povas reveni, aŭ statika kaj do intenca enskribo?

Respondu tion antaŭ ol tuŝi ion ajn. Se la adreso ne atingeblas de la demandanta reto, nenia purigado de la klienta kaŝmemoro riparas ĝin longe. Se io dependas de ĝi, ekzemple administra vojo kiun uzas la tunelaj kunuloj mem, forigo anstataŭe rompas tiun vojon. Kaj dinamika rikordo forigita sen trakti ĝian publikiganton reaperos ĉe la sekva registrada evento.

Legu la rikordon antaŭ ol ŝanĝi la registranton

Demandu la precizan plene kvalifikitan nomon el la reto kiu raportas la problemon, kaj komparu la respondojn kun la realaj interfacoj kaj aŭskultantoj de la servilo. Unu nomo redonanta plurajn adresojn estas normala; la demando estas ĉu ĉiu el ili estas uzebla por la kliento kiu ricevas ĝin.

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

La unua demando uzas la lokan solvilon, la dua demandas rekte specifan DNS-servilon, kaj la tria faras la samon el PowerShell en Windows. Ilia komparo apartigas malnoviĝintan klientan kaŝmemoron de aŭtoritata respondo. Se la rekta demando jam redonas la tunean adreson, la problemo estas publikigitaj datumoj, ne loka kaŝmemorigo.

Notu la tempomarkon de la rikordo kaj ĉu la DNS-konzolo montras ĝin kiel dinamikan. Tiu sola atributo diras al vi kiun el la tri kondiĉoj supre aplikas, kaj ĝi estas la diferenco inter kvinminuta purigado kaj riparo kiu daŭras.

Riparu la publikiganton aŭ la rikordon, sed sciu kiun

Se la rikordo estas dinamika kaj nedezirata, la daŭra riparo estas malhelpi tiun interfacon registriĝi. Windows liveras registradajn agordojn por ĉiu interfaco, kaj la DNS-klienta servo republikigas ĉe la sekva konekto aŭ adresŝanĝo. Malŝalti registradon por la telefona adaptilo lasas la registradon de la LAN-adaptilo sendifekta, kio kutime estas tio kion vi volas.

Estu singarda pri ŝaltiloj por la tuta maŝino. Tutmonda agordo kiu malŝaltas dinamikan ĝisdatigon efikas al ĉiu interfaco sur tiu gastiganto, inkluzive tiun kies registradon aliaj klientoj fidas. Sur domajna reganto la sama singardo aplikiĝas pli forte, ĉar la gastiganto eble ankaŭ posedas servolokajn rikordojn de kiuj klientoj dependas por ensaluti.

Se la rikordo estas statika, ĝi estis metita tie intence kaj la konversacio estas kun tiu kiu metis ĝin. Forigi statikan rikordon ĉar ĝi estas hodiaŭ maloportuna forigas la solan pruvon pri kial ĝi ekzistas. En ambaŭ kazoj, forigu la malnoviĝintan respondon nur post kiam la publikiganto estas traktita, kaj notu kion vi ŝanĝis por ke la sekva persono povu distingi intencan enskribon de akcidento.

Kontrolleru el la klienta reto kiu malsukcesis

Kontrolado apartenas al la reto kiu raportis la simptomon, ne al la servilo. Purigu la kaŝmemoron de la klienta solvilo per ĝia subtenata mekanismo, poste ripetu la originan serĉon kaj la originan servan konekton laŭ nomo.

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

La unua komando purigas la kaŝmemoron de la Windows-solvilo, kaj la dua montras ĉu la nomo denove kaŝmemoriĝis kaj kiu adreso estis konservita. Sukcesa konekto de la servilo al si mem pruvas nenion pri LAN-kliento, kaj forigo de vojo al la nedezirata adreso ne korektas tion kion DNS publikigas.

Fine, ripetu la eventon kiu antaŭe enkondukis la adreson: rekonektu la VPN-klienton, aŭ renovigu la telefonsesian. Kontrolu la publikigitan nomon denove post tiu vivcikla ŝanĝo. Riparo kiu daŭras nur ĝis la sekva konekto estis purigado, ne riparo, kaj scii kiun vi faris estas la diferenco inter fermi la bileton kaj remalfermi ĝin venontsemajne.