Warum Namensauflösungen über einen gerouteten OpenVPN-Tunnel scheitern
Ein gerouteter TUN-Tunnel überträgt nur Unicast-IP, eine Broadcast-Namensabfrage hatte also nie eine Route hinein. Bridging hebt die Grenze auf; DNS zu pushen ist die günstigere Lösung.
Ein Host antwortet auf Ping per Adresse und scheitert bei jeder Suche per Name. Der Tunnel steht und die Route existiert, also liegt der naheliegende Schluss darin, dass das VPN falsch konfiguriert ist. Ein nützlicherer Schluss ist, dass die Suche nie routingfähig war: Ein gerouteter Tunnel überträgt Unicast-IP, während die betreffende Abfrage ein Broadcast war, der ein Segment suchte, das es auf der anderen Seite nicht gibt. Sobald die Schichtendifferenz sichtbar ist, sortieren sich die Lösungen von selbst nach Kosten.
Mythos: Der Tunnel ist kaputt, weil Namen scheitern
Das Symptom überzeugt, weil alles oberhalb der Namensschicht funktioniert. Adressen werden geroutet, das Interface steht, und der Peer antwortet auf einen Ping. Gescheitert ist ein Erkennungsmechanismus, der nie einen Pfad über eine Punkt-zu-Punkt-Verbindung hatte, und das ist eine andere Aussage als ein kaputter Tunnel. Diese beiden Aussagen zu trennen, ist der größte Teil der Diagnose.
Wird es als Tunnelfehler behandelt, folgen Profiländerungen, die nicht helfen können. Optionen hinzufügen, die Verschlüsselung wechseln oder den Client neu installieren lässt den Broadcast genau dort, wo er war.
Benennen Sie den Mechanismus, der gescheitert ist, bevor Sie die Lösung benennen. Eine Suche per Broadcast braucht ein Segment, während eine Suche per Resolver eine Adresse braucht, die sie fragen kann.
Was TUN überträgt und was nicht
Ein TUN-Gerät ist eine IP-Schnittstelle, und genau das macht es routingfähig. OpenVPN gibt dem Client eine Adresse und eine Reihe von Routen, und von da an sendet der Client Datagramme an einen Peer. Nichts in diesem Modell erzeugt eine gemeinsame Strecke, auf der jeder Host jeden Frame hört.
Erkennungsverkehr passt überhaupt nicht in dieses Modell. Ältere Windows-Namensabfragen, SSDP-Ankündigungen und mDNS-Anfragen gehen an alle in einem Segment statt an ein einziges Ziel. Eine geroutete Strecke hat kein „alle“, an das sie senden könnte. Jeder dieser Mechanismen setzt ein gemeinsames Medium voraus.
Der Tunnel kann also gesund sein, während die Erkennung vollständig scheitert. Dieser Satz ist der, an dem man festhalten sollte, wenn jemand das VPN als ausgefallen meldet.
Bridging funktioniert, indem es die Grenze aufhebt
Ein TAP-Gerät überträgt Frames, und eine Bridge hängt es an ein echtes LAN-Segment. Der Client hat dann eine Adresse in diesem Segment und hört dessen Broadcast-Verkehr. Deshalb scheint Bridging das Namensproblem zu heilen. Es macht den Client zugleich für die Adressierung von diesem Segment abhängig.
Die Heilung ist die Aufhebung der Routing-Grenze, nicht eine neue Namensfähigkeit im Tunnel. Alles, was das Segment per Broadcast sendet, überquert jetzt ebenfalls die Strecke.
Für ein kleines Labor ist das ein fairer Tausch. Über eine verteilte Belegschaft hinweg selten.
DNS und WINS zu pushen ist die engere Reparatur
Geben Sie dem Client eine konkrete Stelle zum Fragen. dhcp-option DNS und dhcp-option DOMAIN verweisen interne Namen auf einen Server, der die Zone kennt, und ein Windows-Client, der noch auf NetBIOS setzt, kann auf demselben Weg einen WINS-Server erhalten. Der Tunnel bleibt geroutet, und das Segment bleibt, wo es hingehört.
Zwei Bedingungen entscheiden, ob das funktioniert. Der genannte Server muss für die Zone antworten, und die Abfrage muss durch den Tunnel erlaubt sein.
Testen Sie den Resolver vom Client aus und nicht aus der Shell des Servers selbst. Ein Resolver, der lokal funktioniert, sagt nichts darüber, was der Tunnel überträgt.
Finden Sie heraus, welche Schicht gescheitert ist
Pingen Sie zuerst die Adresse, lösen Sie dann den Namen auf und lesen Sie, welcher Server geantwortet hat. Eine negative Antwort von einem Server, der die Zone nicht hostet, sieht anders aus als eine Abfrage, die den Rechner nie verlassen hat. Ein Name, der sich auflöst, aber Verbindungen ablehnt, ist ein ganz drittes Problem.
Multicast steht hinter derselben Wand. Eine Gruppe wie 224.0.0.251 wird standardmäßig nicht über einen gerouteten Tunnel weitergeleitet, und eine Route für die Gruppe reicht ohne einen multicast-fähigen Pfad oder einen Reflektor im LAN nicht aus.