Pse një emër serveri zgjidhet në adresën e tij VPN pas lidhjes me telefon

Një server skedarësh zyre përgjigjet në adresën e tij LAN gjithë mëngjesin, pastaj një përdorues në distancë lidhet me telefon dhe emri fillon të zgjidhet në një adresë tuneli në vend të kësaj. Asgjë nuk u redaktua me dorë në DNS, dhe ky është indici: rekordin e publikoi vetë makina. Tre kushte vendosin nëse rregulloni regjistruesin, rekordin apo pamjen e klientit, dhe rendi i gabuar do të thotë që rekordi kthehet pas lidhjes tjetër.

Dy adresa, një emër, tre kushte

Një server Windows me shumë ndërfaqe mund të ketë një adresë LAN, një ose më shumë adresa lidhjeje me telefon dhe ndonjëherë një kartë të dytë rrjeti. Çdo ndërfaqe mund të regjistrojë adresat e veta në DNS nëse regjistrimi dinamik lejohet për të. Kur përshtatësi PPP regjistrohet, i njëjti emër hosti fiton një adresë që vetëm partneri i tunelit mund ta arrijë, dhe klientët e LAN e marrin si përgjigje të vlefshme.

Tre kushte vendosin riparimin. Së pari, a është adresa shtesë e arritshme nga klientët që e marrin? Së dyti, a varet ende ndonjë konsumator nga ai regjistrim? Së treti, a është rekordi dinamik dhe për këtë arsye mund të kthehet, apo statik dhe për këtë arsye një hyrje e qëllimshme?

Përgjigjuni kësaj përpara se të prekni ndonjë gjë. Nëse adresa nuk është e arritshme nga rrjeti që pyet, asnjë pastrim i cache-së së klientit nuk e rregullon atë për një kohë të gjatë. Nëse diçka varet prej saj, si një rrugë administrimi që përdorin vetë partnerët e tunelit, heqja e saj në vend të kësaj thyen atë rrugë. Dhe një rekord dinamik i fshirë pa u marrë me publikuesin e tij do të rishfaqet në ngjarjen tjetër të regjistrimit.

Lexoni rekordin përpara se të ndryshoni regjistruesin

Pyetni emrin e saktë plotësisht të kualifikuar nga rrjeti që raporton problemin dhe krahasoni përgjigjet me ndërfaqet dhe dëgjuesit aktualë të serverit. Një emër i vetëm që kthen disa adresa është normal; pyetja është nëse secila është e përdorshme nga klienti që e merr.

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

Pyetja e parë përdor zgjidhësin lokal, e dyta pyet drejtpërdrejt një server DNS të caktuar, dhe e treta bën të njëjtën gjë nga PowerShell në Windows. Krahasimi i tyre ndan një cache klienti të vjetëruar nga një përgjigje autoritative. Nëse pyetja e drejtpërdrejtë tashmë kthen adresën e tunelit, problemi është në të dhënat e publikuara dhe jo në cache-n lokal.

Shkruani vulën kohore të rekordit dhe nëse konsola DNS e shfaq si dinamik. Ai atribut i vetëm ju tregon se cili nga tre kushtet më sipër zbatohet, dhe është ndryshimi midis një pastrimi pesëminutësh dhe një riparimi që zgjat.

Rregulloni publikuesin ose rekordin, por dijeni cilin

Nëse rekordi është dinamik dhe i padëshiruar, rregullimi i qëndrueshëm është të pengoni atë ndërfaqe të regjistrohet. Windows ofron cilësime regjistrimi për secilën ndërfaqe, dhe shërbimi i klientit DNS publikon përsëri në lidhjen ose ndryshimin e adresës tjetër. Fikja e regjistrimit për përshtatësin e lidhjes me telefon e lë të paprekur regjistrimin e përshtatësit LAN, që zakonisht është ajo që dëshironi.

Kini kujdes me çelsat që vlejnë për të gjithë makinën. Një cilësim global që çaktivizon përditësimin dinamik prek çdo ndërfaqe në atë host, duke përfshirë atë nga regjistrimi i së cilës varen klientët e tjerë. Në një kontrollues domeni i njëjti kujdes zbatohet me më shumë forcë, sepse hosti mund të zotërojë edhe regjistrime vendndodhjeje shërbimi nga të cilat klientët varen për t’u identifikuar.

Nëse rekordi është statik, ai u vendos atje me qëllim dhe biseda është me atë që e vendosi. Fshirja e një rekordi statik sepse sot është i papërshtatshëm heq provën e vetme se pse ekziston. Në të dyja rastet, fshini përgjigjen e vjetëruar vetëm pasi publikuesi të jetë trajtuar, dhe shënoni çfarë ndryshuat që personi tjetër të mund të dallojë një hyrje të qëllimshme nga një aksident.

Verifikoni nga rrjeta e klientit që dështoi

Verifikimi i takon rrjetit që raportoi simptomën, jo serverit. Pastroni cache-n e zgjidhësit të klientit përmes mekanizmit të tij të mbështetur, pastaj përsëritni kërkimin origjinal dhe lidhjen origjinale me shërbimin sipas emrit.

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

Komanda e parë pastron cache-n e zgjidhësit të Windows, dhe e dyta tregon nëse emri është cache-uar përsëri dhe cila adresë u ruajt. Një lidhje e suksesshme e serverit me vetveten nuk provon asgjë për një klient LAN, dhe heqja e një rrugë drejt adresës së padëshiruar nuk e korrigjon atë që publikon DNS.

Së fundi, përsëritni ngjarjen që më parë sillte adresën: rilidhni klientin VPN ose rinovoni sesionin e lidhjes me telefon. Kontrolloni përsëri emrin e publikuar pas asaj ndryshimi të ciklit të jetës. Një riparim që zgjat vetëm deri në lidhjen tjetër ishte pastrim, jo riparim, dhe të dish se cilën nga të dyja kryet është ndryshimi midis mbylljes së tiketit dhe rihapjes së tij javën tjetër.