Proč se název serveru po dial-inu překládá na jeho adresu VPN

Kancelářský souborový server celé dopoledne odpovídá na své adrese v LAN, pak se vzdálený uživatel připojí přes dial-in a název se začne překládat na adresu tunelu. V DNS se ručně nic neupravovalo, a to je stopa: záznam publikoval samotný stroj. Rozhodují tři podmínky, zda opravíte registrátora, záznam, nebo pohled klienta, a špatné pořadí znamená, že se záznam po dalším připojení vrátí.

Dvě adresy, jeden název, tři podmínky

Windows server s více rozhraními může mít adresu v LAN, jednu nebo více dial-in adres a někdy druhou síťovou kartu. Každé rozhraní může registrovat své vlastní adresy v DNS, pokud je pro něj povolena dynamická registrace. Když se adaptér PPP zaregistruje, stejný název hostitele získá adresu, ke které se dostane jen protějšek tunelu, a klienti v LAN ji dostanou jako platnou odpověď.

Opravu rozhodují tři podmínky. Za prvé, je dodatečná adresa dostupná z klientů, kteří ji dostávají? Za druhé, závisí na této registraci ještě nějaký spotřebitel? Za třetí, je záznam dynamický, a tedy schopný se vrátit, nebo statický, a tedy záměrný záznam?

Odpovězte na to, než se čehokoli dotknete. Pokud je adresa nedostupná ze sítě, která se dotazuje, žádné čištění klientské mezipaměti to na dlouho nespraví. Pokud na ní něco závisí, například cesta pro správu, kterou používají sami protějšky tunelu, odstranění místo toho tuto cestu rozbije. A dynamický záznam smazaný bez řešení jeho vydavatele se při další události registrace znovu objeví.

Přečtěte si záznam, než změníte registrátora

Dotážete se na přesné plně kvalifikované jméno ze sítě, která hlásí problém, a porovnejte odpovědi se skutečnými rozhraními a naslouchači serveru. Jeden název vracející několik adres je normální; otázkou je, zda je každá z nich použitelná pro klienta, který ji dostává.

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

První dotaz používá místní resolver, druhý se ptá přímo konkrétního serveru DNS a třetí dělá totéž z PowerShellu ve Windows. Jejich porovnání odděluje zastaralou klientskou mezipaměť od autoritativní odpovědi. Pokud přímý dotaz už vrací adresu tunelu, problém je v publikovaných datech, ne v místním ukládání do mezipaměti.

Zapište časové razítko záznamu a zda jej konzole DNS zobrazuje jako dynamický. Tento jediný atribut vám řekne, která ze tří podmínek výše platí, a to je rozdíl mezi pětiminutovým úklidem a opravou, která vydrží.

Opravte vydavatele, nebo opravte záznam, ale vězte které

Pokud je záznam dynamický a nežádoucí, trvalou opravou je zabránit tomuto rozhraní v registraci. Windows nabízí nastavení registrace pro každé rozhraní a klientská služba DNS znovu publikuje při dalším připojení nebo změně adresy. Vypnutí registrace pro dial-in adaptér ponechá registraci adaptéru LAN nedotčenou, což je obvykle to, co chcete.

Buďte opatrní s přepínači pro celý stroj. Globální nastavení, které zakáže dynamickou aktualizaci, ovlivní každé rozhraní na tomto hostiteli, včetně toho, na jehož registraci spoléhají jiní klienti. Na řadiči domény platí stejná opatrnost důrazněji, protože hostitel může vlastnit i záznamy umístění služeb, na nichž klienti závisí při přihlašování.

Pokud je záznam statický, byl tam umístěn záměrně a rozhovor je s tím, kdo jej umístil. Smazání statického záznamu proto, že je dnes nepohodlný, odstraní jediný důkaz o tom, proč existuje. V obou případech smažte zastaralou odpověď až poté, co je vydavatel vyřešen, a zaznamenejte, co jste změnili, aby další člověk rozeznal záměrný záznam od nehody.

Ověřte ze sítě klienta, která selhala

Ověření patří na síť, která nahlásila příznak, ne na server. Vymažte mezipaměť klientského resolveru jeho podporovaným mechanismem, pak zopakujte původní dotaz a původní připojení ke službě podle názvu.

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

První příkaz vymaže mezipaměť resolveru Windows a druhý ukáže, zda je název znovu v mezipaměti a která adresa byla uložena. Úspěšné připojení serveru k sobě samému nic nedokazuje o klientovi v LAN a odstranění trasy k nežádoucí adrese neopraví to, co DNS publikuje.

Nakonec zopakujte událost, která dříve adresu vnášela: znovu připojte klienta VPN nebo obnovte dial-in relaci. Zkontrolujte publikovaný název znovu po této změně životního cyklu. Oprava, která vydrží jen do dalšího připojení, byla úklidem, ne opravou, a vědět, kterou z nich jste provedli, je rozdíl mezi uzavřením tiketu a jeho opětovným otevřením příští týden.