Kwa nini jina la seva hutatuliwa kwenye anwani yake ya VPN baada ya dial-in

Seva ya faili ya ofisi hujibu kwenye anwani yake ya LAN asubuhi yote, kisha mtumiaji wa mbali hupiga simu na kuingia, na jina huanza kutatuliwa kwenye anwani ya handaki badala yake. Hakuna kilichohaririwa kwa mkono katika DNS, na hilo ndilo kidokezo: rekodi ilichapishwa na mashine yenyewe. Masharti matatu huamua ikiwa utarekebisha msajili, rekodi au mtazamo wa mteja, na mpangilio mbaya unamaanisha rekodi itarudi baada ya muunganisho unaofuata.

Anwani mbili, jina moja, masharti matatu

Seva ya Windows yenye violesura kadhaa inaweza kuwa na anwani ya LAN, anwani moja au zaidi za dial-in na wakati mwingine kadi ya pili ya mtandao. Kila kiolesura kinaweza kusajili anwani zake mwenyewe katika DNS ikiwa usajili unaobadilika unaruhusiwa kwa ajili yake. Adapta ya PPP inaposajili, jina lile lile la mwenyeji hupata anwani ambayo mwenzi wa handaki pekee anaweza kufikia, na wateja wa LAN wanaipokea kama jibu halali.

Masharti matatu huamua ukarabati. Kwanza, anwani ya ziada inafikika kutoka kwa wateja wanaoipokea? Pili, mtumiaji yeyote bado anategemea usajili huo? Tatu, rekodi inabadilika na kwa hivyo inaweza kurudi, au ni thabiti na kwa hivyo ni ingizo la makusudi?

Jibu hilo kabla ya kugusa chochote. Ikiwa anwani haifikiki kutoka kwenye mtandao unaouliza, kusafisha akiba ya mteja hakutarekebisha hilo kwa muda mrefu. Ikiwa kitu kinategemea, kama vile njia ya usimamizi inayotumiwa na wenzi wa handaki wenyewe, kuiondoa kunavunja njia hiyo badala yake. Na rekodi inayobadilika iliyofutwa bila kushughulikia mchapishaji wake itaonekana tena kwenye tukio la usajili linalofuata.

Soma rekodi kabla ya kubadilisha msajili

Uliza jina kamili linalostahili kwa usahihi kutoka kwenye mtandao unaoripoti tatizo, na linganisha majibu na violesura halisi vya seva na wasikilizaji wake. Jina moja kurudisha anwani kadhaa ni kawaida; swali ni ikiwa kila moja inaweza kutumiwa na mteja anayeipokea.

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

Swali la kwanza hutumia kitatuzi cha ndani, la pili huuliza seva mahususi ya DNS moja kwa moja, na la tatu hufanya vivyo hivyo kutoka PowerShell kwenye Windows. Kuyalinganisha hutenganisha akiba chakavu ya mteja na jibu lenye mamlaka. Ikiwa swali la moja kwa moja tayari linarejesha anwani ya handaki, tatizo liko kwenye data iliyochapishwa na si kwenye akiba ya ndani.

Andika muhuri wa muda wa rekodi na ikiwa konsoli ya DNS inaionyesha kama inayobadilika. Sifa hiyo moja hukuambia ni sharti gani kati ya matatu hapo juu linalotumika, na ndiyo tofauti kati ya usafishaji wa dakika tano na ukarabati unaodumu.

Rekebisha mchapishaji au rekodi, lakini ujue ipi

Ikiwa rekodi inabadilika na haitakiwi, suluhisho la kudumu ni kuzuia kiolesura hicho kusajili. Windows hutoa mipangilio ya usajili kwa kila kiolesura, na huduma ya mteja wa DNS huchapisha tena kwenye muunganisho au mabadiliko ya anwani yanayofuata. Kuzima usajili kwa adapta ya dial-in kunaacha usajili wa adapta ya LAN ukiwa sawa, ambayo kwa kawaida ndiyo unayotaka.

Kuwa mwangalifu na swichi zinazotumika kwa mashine nzima. Mpangilio wa kimataifa unaozima sasisho linalobadilika huathiri kila kiolesura kwenye mwenyeji huyo, ikiwa ni pamoja na kile ambacho wateja wengine wanategemea usajili wake. Kwenye kidhibiti cha kikoa tahadhari hiyo hiyo inatumika kwa nguvu zaidi, kwa sababu mwenyeji anaweza pia kumiliki rekodi za mahali pa huduma ambazo wateja wanategemea kuingia.

Ikiwa rekodi ni thabiti, iliwekwa hapo kwa makusudi na mazungumzo ni na yule aliyeiweka. Kufuta rekodi thabiti kwa sababu leo haifai huondoa ushahidi pekee wa kwa nini ipo. Katika hali zote mbili, futa jibu chakavu tu baada ya mchapishaji kushughulikiwa, na andika ulichobadilisha ili mtu anayefuata aweze kutofautisha ingizo la makusudi na ajali.

Thibitisha kutoka kwenye mtandao wa mteja ulioshindwa

Uthibitishaji ni wa mtandao ulioripoti dalili, si wa seva. Safisha akiba ya kitatuzi cha mteja kupitia mbinu yake inayotumika, kisha rudia utafutaji wa awali na muunganisho wa awali wa huduma kwa jina.

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

Amri ya kwanza husafisha akiba ya kitatuzi cha Windows, na ya pili inaonyesha ikiwa jina limehifadhiwa tena na ni anwani gani iliyohifadhiwa. Muunganisho uliofaulu wa seva na yenyewe hauthibitishi chochote kuhusu mteja wa LAN, na kuondoa njia kuelekea anwani isiyotakiwa hakurekebishi kile DNS inachapisha.

Mwisho, rudia tukio ambalo hapo awali liliingiza anwani: unganisha tena mteja wa VPN, au huisha upya kipindi cha dial-in. Angalia tena jina lililochapishwa baada ya mabadiliko hayo ya mzunguko wa maisha. Ukarabati unaodumu hadi muunganisho unaofuata tu ulikuwa usafishaji, si ukarabati, na kujua ni upi uliofanya ndiyo tofauti kati ya kufunga tikiti na kuifungua tena wiki ijayo.