Prečo sa názov servera po dial-ine prekladá na jeho adresu VPN

Kancelársky súborový server celé dopoludnie odpovedá na svojej adrese v LAN, potom sa vzdialený používateľ pripojí cez dial-in a názov sa začne prekladať na adresu tunela. V DNS sa ručne nič neupravovalo, a to je stopa: záznam publikoval samotný stroj. Rozhodujú tri podmienky, či opravíte registrátora, záznam alebo pohľad klienta, a nesprávne poradie znamená, že záznam sa po ďalšom pripojení vráti.

Dve adresy, jeden názov, tri podmienky

Windows server s viacerými rozhraniami môže mať adresu v LAN, jednu alebo viac dial-in adries a niekedy druhú sieťovú kartu. Každé rozhranie môže registrovať svoje vlastné adresy v DNS, ak je preň povolená dynamická registrácia. Keď sa adaptér PPP zaregistruje, rovnaký názov hostiteľa získa adresu, ku ktorej sa dostane len partner tunela, a klienti v LAN ju dostanú ako platnú odpoveď.

Opravu rozhodujú tri podmienky. Po prvé, je dodatočná adresa dostupná z klientov, ktorí ju dostávajú? Po druhé, závisí od tejto registrácie ešte nejaký spotrebiteľ? Po tretie, je záznam dynamický, a teda schopný vrátiť sa, alebo statický, a teda zámerný záznam?

Odpovedzte na to, skôr než sa čohokoľvek dotknete. Ak je adresa nedostupná zo siete, ktorá sa dopytuje, žiadne čistenie klientskej medzipamäte to na dlho nespraví. Ak na nej niečo závisí, napríklad cesta na správu, ktorú používajú sami partneri tunela, odstránenie namiesto toho túto cestu pokazí. A dynamický záznam zmazaný bez riešenia jeho vydavateľa sa pri ďalšej udalosti registrácie znova objaví.

Prečítajte si záznam, skôr než zmeníte registrátora

Dopýtajte sa na presné plne kvalifikované meno zo siete, ktorá hlási problém, a porovnajte odpovede so skutočnými rozhraniami a naslúchačmi servera. Jeden názov vracajúci niekoľko adries je normálny; otázkou je, či je každá z nich použiteľná pre klienta, ktorý ju dostáva.

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

Prvý dopyt používa miestny resolver, druhý sa pýta priamo konkrétneho servera DNS a tretí robí to isté z PowerShellu vo Windows. Ich porovnanie oddeľuje zastaranú klientsku medzipamäť od autoritatívnej odpovede. Ak priamy dopyt už vracia adresu tunela, problém je v publikovaných údajoch, nie v miestnom ukladaní do medzipamäte.

Zapíšte časovú pečiatku záznamu a to, či ho konzola DNS zobrazuje ako dynamický. Ten jediný atribút vám povie, ktorá z troch podmienok vyššie platí, a je to rozdiel medzi päťminútovým upratovaním a opravou, ktorá vydrží.

Opravte vydavateľa alebo záznam, ale vedzte ktorý

Ak je záznam dynamický a nežiaduci, trvalou opravou je zabrániť tomuto rozhraniu v registrácii. Windows ponúka nastavenia registrácie pre každé rozhranie a klientska služba DNS znova publikuje pri ďalšom pripojení alebo zmene adresy. Vypnutie registrácie pre dial-in adaptér ponechá registráciu adaptéra LAN nedotknutú, čo je zvyčajne to, čo chcete.

Buďte opatrní s prepínačmi pre celý stroj. Globálne nastavenie, ktoré vypne dynamickú aktualizáciu, ovplyvní každé rozhranie na tomto hostiteľovi, vrátane toho, na ktorého registráciu sa spoliehajú iní klienti. Na radiči domény platí rovnaká opatrnosť silnejšie, pretože hostiteľ môže vlastniť aj záznamy umiestnenia služieb, od ktorých klienti závisia pri prihlasovaní.

Ak je záznam statický, bol tam umiestnený zámerne a rozhovor je s tým, kto ho umiestnil. Zmazanie statického záznamu preto, že je dnes nepohodlný, odstráni jediný dôkaz o tom, prečo existuje. V oboch prípadoch zmažte zastaranú odpoveď až po vyriešení vydavateľa a zaznamenajte, čo ste zmenili, aby ďalší človek rozoznal zámerný záznam od nehody.

Overte zo siete klienta, ktorá zlyhala

Overenie patrí sieti, ktorá nahlásila príznak, nie serveru. Vymažte medzipamäť klientskeho resolvera jeho podporovaným mechanizmom, potom zopakujte pôvodný dopyt a pôvodné pripojenie k službe podľa názvu.

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

Prvý príkaz vymaže medzipamäť resolvera Windows a druhý ukáže, či je názov znova v medzipamäti a ktorá adresa bola uložená. Úspešné pripojenie servera k sebe samému nič nedokazuje o klientovi v LAN a odstránenie trasy k nežiaducej adrese neopraví to, čo DNS publikuje.

Nakoniec zopakujte udalosť, ktorá predtým vnášala adresu: znova pripojte klienta VPN alebo obnovte dial-in reláciu. Skontrolujte publikovaný názov znova po tejto zmene životného cyklu. Oprava, ktorá vydrží len do ďalšieho pripojenia, bola upratovaním, nie opravou, a vedieť, ktorú z nich ste vykonali, je rozdiel medzi uzavretím tiketu a jeho opätovným otvorením budúci týždeň.