Názvy hostitelů VPN selhávají, IP adresy fungují: kam se podívat

Sdílený prostředek otevřete podle adresy, a tentýž prostředek podle jména selže, což znamená, že tunel přenáší pakety a vrstva jmen ne. Toto jediné pozorování ušetří objížďku přes změny firewallu a tras. Jména potřebují sufiks, resolver a cestu pro dotaz, a klient VPN může nainstalovat trasu, aniž by nainstaloval cokoli z toho. Projděte čtyři kontroly níže v pořadí a zastavte se u první, která se zlomí.

Jméno klade otázku, kterou adresa neklade

Adresa je cíl, který zásobník může použít okamžitě. Krátké jméno je otázka, kterou je třeba rozšířit sufiksem, poslat resolveru a nechat zodpovědět něčím, co zná zónu. Tunel, který instaluje trasy, ale žádný resolver, nechá první fungovat a druhé rozbité. Proto symptom vypadá tak konzistentně napříč velmi odlišnými produkty VPN.

Pracujte od adresy ven: nejprve plné jméno, pak holé jméno hostitele, a poznamenejte si, které ze tří funguje. Vzor vám řekne, kterou vrstvu prozkoumat, než otevřete jedinou obrazovku nastavení. Hádat trasy, když se plné jméno překládá, je zbytečná práce.

Přečtěte si resolver, který tunel skutečně nainstaloval

Zeptejte se operačního systému který resolver zpracovává dotazy pro interní zónu, ne který inzeruje rozhraní klienta VPN. Server, který vnucuje veřejný resolver bez interní zóny, produkuje přesně toto selhání, a je to chyba konfigurace, nikoli porucha směrování.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

Na klientu Windows připojeném k doméně rozhoduje zásada směrování jmenného prostoru o tom, které dotazy jdou kterému resolveru, a vlastní nastavení DNS adaptéru VPN se objevuje v podrobnostech adaptéru. Čtěte platnou zásadu, nikoli profil, protože uložená zásada může přežít připojení, které ji nainstalovalo. Pokud resolver odpovídá na plné jméno a ne na krátké, problém se už přesunul do seznamu sufiksů.

Get-DnsClientNrptPolicy
ipconfig /all

Zastavte se, pokud se interní zóna překládá přes správný server. Resolver není váš problém.

Sufiksy vysvětlují krátká jména, která selhávají

Jméno s jedním štítkem se před odesláním dotazu rozšíří seznamem sufiksů připojení. Pokud VPN nedodá interní sufiks, fileserver se nikdy nestane fileserver.corp.example a dotaz vyjde jako jméno, které žádný veřejný resolver nezná. Vnucení sufiksu nebo napsání plného jména otestuje hypotézu, aniž by na serveru cokoli změnilo.

nslookup fileserver.corp.example
ping -a 192.168.50.20

V Linuxu služba resolveru váže server DNS na link a sadu směrovacích domén, takže vnucený server, který není přidružen k linku tunelu, se chová, jako by tam nebyl. Kontrolujte stav po linku, nikoli soubor stub, který může ukazovat jen na místní resolver. Stejné rozdělení se objevuje i v opačném směru: doména hledání, která existuje, ale není aplikována na rozhraní tunelu, produkuje selhání krátkých jmen, která vypadají náhodně.

Pokud přidání sufiksu problém vyřeší, zbývá dodat tento sufiks přes profil VPN, místo abyste po každém uživateli chtěli, aby ho psal.

NetBIOS a WINS jsou jiný mechanismus

Starší SMB stále umí vyhledat holé jméno službou jmen NetBIOS, která odpovídá vysíláním nebo přes server WINS. Vysílání zůstává v jedné vysílací doméně a zastaví se na prvním routeru, takže nemůže projít tunelem; WINS funguje, protože klient má jednosměrovou adresu, u níž se registruje a na kterou se ptá. Proto VPN přenášející jen IP může stále podporovat stará jména, když je WINS nakonfigurován a dostupný.

nbtstat -n
nbtstat -R

Pro moderní SMB se spolehněte na DNS a plné jméno a starou cestu pošlete do důchodu. Pokud je skutečně stará, zajistěte WINS nebo aplikaci nahraďte; střední cesta je fronta podpory, která se nikdy nevyprázdní.

Procházka končí, když můžete říci, která vrstva selhala: resolver, sufiks nebo staré zjišťování. Zapište resolver, který odpověděl, a tvar jména, který fungoval, protože další člověk začne u stejného symptomu.