Název hostitele v síti LAN nefunguje přes VPN: sufix, mDNS, nebo zóna?
Krátký název se může opírat o vyhledávací sufix, název .local o multicast a název firmy o privátní zónu. Samotná trasa žádnou službu pojmenování neposkytuje.
Vedle zařízení tiskárna odpovídá na krátký název a souborový server na přezdívku. Přes tunel oba názvy vyprší, zatímco jejich adresy stále fungují. Trasa dělá svou práci; cesta pojmenování, která ty krátké názvy zprovozňovala, nikdy tunel nepřešla. Toto chování vytvářejí tři mechanismy a každý z nich potřebuje jinou opravu.
Začněte tím, že určíte, na kterém mechanismu název závisí.
Tři druhy názvů, které se chovají odlišně
Název s jediným popiskem, jako je fileserver, se obvykle opírá o vyhledávací sufix DNS, který připojuje resolver. Tento sufix často přichází s místním DHCP pronájmem, takže vzdálený klient, který adresu získává z VPN, nemá důvod ho znát. Přidání trasy sufix nedoručí. Krátký název prostě přestane existovat jako název, i když adresa za ním je dostupná.
Název končící na .local se obvykle překládá pomocí multicast DNS na místním spoji, jak popisuje RFC 6762. Multicast nepřekračuje směrovaný tunel, pokud ho něco záměrně nemostí nebo neproxyuje, takže název přestane překládat ve chvíli, kdy opustíte segment.
Plně kvalifikovaný název firmy patří interní zóně obsluhované resolvery organizace. Ten funguje na dálku, když VPN tyto resolvery posílá a klient je nakonfigurován je používat. A localhost má zvláštní určení podle RFC 6761: odkazuje na počítač před vámi, nikdy na vzdálenou službu.
Přečtěte resolver dřív, než změníte trasu
Zeptejte se, který jmenný server odpověděl a který sufix byl připojen. Stejný dotaz přes různé resolvery dává různé odpovědi a ten rozdíl je důkaz, který potřebujete.
getent hosts fileserver getent hosts fileserver.corp.example.com nslookup fileserver.corp.example.com dig +search fileserver A resolvectl query fileserver.corp.example.com scutil --dns | head -30
Pokud se plně kvalifikovaný dotaz přeloží, ale krátký ne, závada je v sufixu, ne v serveru. Pokud se nepřeloží ani jeden a adresa funguje, klient interní resolver vůbec nepoužívá. Porovnejte seznam resolverů s tím, co VPN má posílat, protože klient, který si pro každý dotaz ponechává místní resolver, interní zónu nikdy neuvidí.
Přineste správný název klientovi
Požádejte správce o dokumentovaný název pro vzdálený přístup, celý, a použijte ho v profilu místo hádání sufixů. Pokud nasazení podporuje split DNS, nakonfigurujte interní doménu, aby ji překládaly interní servery, zatímco vše ostatní si ponechá místní resolver. Posílejte vyhledávací doménu přes konfiguraci VPN tam, kde ji klient podporuje.
Ověřte výsledek na klientovi, ne na bráně. Nastavení použité na serveru, které se ke klientovi nikdy nedostane, nic nezmění.
Zachovejte identitu certifikátu nedotčenou
Test založený na adrese, který ignoruje chybu certifikátu, dokazuje jen to, že se socket otevřel. Certifikát služby je vydán pro název a klient bude nesoulad dál oprávněně odmítat. Pokud certifikát uvádí jen interní název, použijte tento název a opravte překlad, nebo si opatřete certifikát, který pokrývá adresu, kterou hodláte používat.
Zaznamenejte název, resolver a sufix, které vedly k úspěšnému spojení. Ten záznam ušetří dalšímu člověku opakování adresního obchvatu, který skrývá skutečný problém.