LAN-Hostname funktioniert über VPN nicht: Suffix, mDNS oder Zone?

Neben dem Gerät antwortet der Drucker auf einen Kurznamen und der Dateiserver auf einen Spitznamen. Durch den Tunnel laufen beide Namen ab, während ihre Adressen weiterhin funktionieren. Die Route erledigt ihre Aufgabe; der Namenspfad, der diese Kurznamen funktionsfähig machte, hat den Tunnel nie überquert. Drei Mechanismen erzeugen dieses Verhalten, und jeder davon braucht eine andere Korrektur.

Beginnen Sie damit, festzustellen, von welchem Mechanismus der Name abhängt.

Drei Arten von Namen, die sich unterschiedlich verhalten

Ein Name mit einer einzigen Bezeichnung wie fileserver beruht meist auf einem DNS-Suchsuffix, das der Resolver anhängt. Dieses Suffix kommt oft mit dem lokalen DHCP-Lease, sodass ein entfernter Client, der seine Adressierung vom VPN bezieht, keinen Grund hat, es zu kennen. Eine Route hinzuzufügen liefert das Suffix nicht. Der Kurzname hört einfach auf, als Name zu existieren, obwohl die dahinterliegende Adresse erreichbar ist.

Ein Name, der auf .local endet, wird normalerweise per Multicast-DNS auf dem lokalen Link aufgelöst, wie RFC 6762 beschreibt. Multicast überquert keinen gerouteten Tunnel, es sei denn, etwas überbrückt oder proxyt ihn absichtlich, sodass der Name in dem Moment nicht mehr aufgelöst wird, in dem Sie das Segment verlassen.

Ein vollständig qualifizierter Firmenname gehört zu einer internen Zone, die von den Resolvern der Organisation bedient wird. Dieser funktioniert aus der Ferne, wenn das VPN diese Resolver überträgt und der Client dafür konfiguriert ist, sie zu verwenden. Und localhost ist laut RFC 6761 für besondere Zwecke reserviert: Es verweist auf den Rechner vor Ihnen, niemals auf einen entfernten Dienst.

Lesen Sie den Resolver, bevor Sie die Route ändern

Fragen Sie, welcher Namensserver geantwortet hat und welches Suffix angehängt wurde. Dieselbe Abfrage über verschiedene Resolver liefert unterschiedliche Antworten, und dieser Unterschied ist der Beweis, den Sie brauchen.

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

Wenn die vollständig qualifizierte Abfrage aufgelöst wird, die kurze aber nicht, liegt der Fehler im Suffix, nicht im Server. Wenn keine von beiden aufgelöst wird und die Adresse funktioniert, nutzt der Client den internen Resolver überhaupt nicht. Vergleichen Sie die Resolverliste mit dem, was das VPN übertragen soll, denn ein Client, der für jede Abfrage seinen lokalen Resolver behält, wird die interne Zone nie sehen.

Bringen Sie den richtigen Namen zum Client

Bitten Sie den Administrator um den dokumentierten Fernzugriffsnamen, vollständig, und verwenden Sie ihn im Profil, statt Suffixe zu raten. Wenn die Bereitstellung Split-DNS unterstützt, konfigurieren Sie die interne Domäne so, dass sie von den internen Servern aufgelöst wird, während alles andere den lokalen Resolver behält. Übertragen Sie die Suchdomäne über die VPN-Konfiguration, wo der Client es unterstützt.

Überprüfen Sie das Ergebnis auf dem Client statt auf dem Gateway. Eine Einstellung, die auf dem Server angewendet wird und den Client nie erreicht, ändert nichts.

Bewahren Sie die Zertifikatsidentität

Ein adressbasierter Test, der den Zertifikatsfehler ignoriert, beweist nur, dass der Socket geöffnet wurde. Das Dienstzertifikat ist auf einen Namen ausgestellt, und der Client wird die Abweichung aus gutem Grund weiterhin ablehnen. Wenn das Zertifikat nur den internen Namen aufführt, verwenden Sie diesen Namen und beheben Sie die Auflösung, oder besorgen Sie ein Zertifikat, das die Adresse abdeckt, die Sie verwenden wollen.

Notieren Sie den Namen, den Resolver und das Suffix, die eine erfolgreiche Verbindung ergeben haben. Diese Aufzeichnung erspart der nächsten Person die Wiederholung des adressbasierten Workarounds, der das eigentliche Problem verbirgt.