De ce un nume de server se rezolvă la adresa sa VPN după conectarea prin dial-in

Un server de fișiere de birou răspunde pe adresa sa LAN toată dimineața, apoi un utilizator la distanță se conectează prin dial-in și numele începe să se rezolve la o adresă de tunel în schimb. Nimic nu a fost editat manual în DNS, și acesta este indiciul: înregistrarea a fost publicată de mașina însăși. Trei condiții decid dacă reparați registratorul, înregistrarea sau viziunea clientului, iar ordinea greșită înseamnă că înregistrarea revine după următoarea conexiune.

Două adrese, un nume, trei condiții

Un server Windows cu mai multe interfețe poate avea o adresă LAN, una sau mai multe adrese de dial-in și uneori o a doua placă de rețea. Fiecare interfață își poate înregistra propriile adrese în DNS dacă înregistrarea dinamică este permisă pentru ea. Când adaptorul PPP se înregistrează, același nume de gazdă primește o adresă pe care doar partenerul tunelului o poate atinge, iar clienții din LAN o primesc ca răspuns valid.

Trei condiții decid reparația. În primul rând, adresa suplimentară este accesibilă din clienții care o primesc? În al doilea rând, mai depinde vreun consumator de acea înregistrare? În al treilea rând, înregistrarea este dinamică și prin urmare poate reveni, sau statică și prin urmare o intrare deliberată?

Răspundeți la asta înainte de a atinge ceva. Dacă adresa nu este accesibilă din rețeaua care întreabă, nicio curățare a memoriei cache a clientului nu o repară pentru mult timp. Dacă ceva depinde de ea, cum ar fi o cale de administrare folosită de partenerii tunelului înșiși, eliminarea sparge acea cale. Și o înregistrare dinamică ștearsă fără a-i trata editorul va reapărea la următorul eveniment de înregistrare.

Citiți înregistrarea înainte de a schimba registratorul

Interogați numele complet calificat exact din rețeaua care raportează problema și comparați răspunsurile cu interfețele și ascultătorii reali ai serverului. Un singur nume care returnează mai multe adrese este normal; întrebarea este dacă fiecare este utilizabilă de clientul care o primește.

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

Prima interogare folosește rezolvatorul local, a doua întreabă direct un server DNS anume, iar a treia face același lucru din PowerShell pe Windows. Compararea lor separă un cache de client învechit de un răspuns autoritativ. Dacă interogarea directă returnează deja adresa tunelului, problema sunt datele publicate, nu cache-ul local.

Notați marca temporală a înregistrării și dacă consola DNS o arată ca dinamică. Acel singur atribut vă spune care dintre cele trei condiții de mai sus se aplică, și este diferența dintre o curățenie de cinci minute și o reparație care ține.

Reparați editorul sau înregistrarea, dar știți care

Dacă înregistrarea este dinamică și nedorită, reparația durabilă este să împiedicați acea interfață să se înregistreze. Windows expune setări de înregistrare pentru fiecare interfață, iar serviciul client DNS publică din nou la următoarea conexiune sau schimbare de adresă. Dezactivarea înregistrării pentru adaptorul de dial-in lasă intactă înregistrarea adaptorului LAN, ceea ce de obicei este ceea ce doriți.

Fiți atenți la comutatoarele valabile pentru întreaga mașină. O setare globală care dezactivează actualizarea dinamică afectează fiecare interfață de pe acea gazdă, inclusiv cea pe a cărei înregistrare se bazează alți clienți. Pe un controler de domeniu aceeași prudență se aplică cu mai multă forță, deoarece gazda poate deține și înregistrări de locație a serviciilor de care clienții depind pentru autentificare.

Dacă înregistrarea este statică, a fost plasată acolo intenționat și conversația este cu cel care a plasat-o. Ștergerea unei înregistrări statice pentru că astăzi este incomodă elimină singura dovadă a motivului pentru care există. În ambele cazuri, ștergeți răspunsul învechit doar după ce editorul a fost tratat, și notați ce ați schimbat pentru ca următoarea persoană să poată distinge o intrare deliberată de un accident.

Verificați din rețeaua clientului care a eșuat

Verificarea aparține rețelei care a raportat simptomul, nu serverului. Goliți cache-ul rezolvatorului clientului prin mecanismul său acceptat, apoi repetați căutarea inițială și conexiunea inițială la serviciu după nume.

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

Prima comandă golește cache-ul rezolvatorului Windows, iar a doua arată dacă numele este din nou în cache și ce adresă a fost stocată. O conexiune reușită a serverului cu el însuși nu dovedește nimic despre un client din LAN, iar eliminarea unei rute către adresa nedorită nu corectează ceea ce publică DNS.

În final, repetați evenimentul care introducea anterior adresa: reconectați clientul VPN sau reînnoiți sesiunea de dial-in. Verificați din nou numele publicat după acea schimbare de ciclu de viață. O reparație care ține doar până la următoarea conexiune a fost o curățenie, nu o reparație, iar faptul de a ști pe care dintre ele ați făcut-o este diferența dintre închiderea tichetului și redeschiderea lui săptămâna viitoare.