OpenVPN-Clients sehen sich gegenseitig nicht: Subnetz oder net30?

Zwei unabhängige Fehler erzeugen dieselbe Beschwerde. Beim ersten erreicht ein Client einen anderen nicht einmal über die Tunneladresse, weil die Adressen nicht in einem Subnetz liegen oder der Server Peer-Verkehr nicht weiterleitet. Beim zweiten funktioniert ping, und die Geräteliste der Anwendung bleibt leer, weil die Erkennung auf Broadcast beruht, den ein Tunnel der Schicht 3 nicht transportieren kann. Ein Ping trennt beide, und die Lösung für den einen ähnelt der Lösung für den anderen überhaupt nicht.

Ein Ping teilt das Problem in zwei

Pingen Sie von einem Client die Tunneladresse des anderen Clients an, nicht seinen Namen und nicht seine LAN-Adresse. Schlägt das fehl, liegt das Problem in der Weiterleitung oder Adressierung, und die Erkennung ist irrelevant, bis es behoben ist. Gelingt es, funktioniert die Weiterleitung bereits, und die verbleibende Lücke ist Broadcast oder Namensauflösung.

ip addr show tun0

Lesen Sie zuerst die Clientschnittstelle, denn die Netzmaske benennt die Topologie. Eine /24 oder eine andere Subnetzmaske bedeutet einen gemeinsamen Pool; eine /30 mit einer Peer-Adresse bedeutet das ältere Punkt-zu-Punkt-Layout, bei dem jeder Client genau einen Nachbarn hat, den Server.

net30 gegenüber Subnetz, von der Clientseite gelesen

Bei net30 vergibt der Server einen kleinen Block pro Client, daher existiert keine Route zur Tunneladresse eines anderen Clients, es sei denn, der Server leitet sie weiter. Beim Subnetz ist der gesamte Pool ein Netz, jeder Client kann jeden anderen adressieren, und der Server leitet zwischen ihnen weiter. Deshalb kann eine Serverkonfiguration gesund aussehen, während Peer-Pings fehlschlagen: Nichts ist kaputt, die Clients sind einfach nicht in einem Netz. Der Client sieht eine funktionierende Verbindung und eine Peer-Adresse, die nicht antwortet, was wie eine Firewall klingt, aber ein Adressierungslayout ist.

Das Umschalten der Direktive ist eine Bearbeitung auf der Serverseite plus Neustart, und sie gilt für die nächste Verbindung statt für bereits bestehende Sitzungen. Verbinden Sie die Clients neu, bevor Sie die Änderung beurteilen. Wenn ein Gerät die Konfiguration aus einer Weboberfläche neu erzeugt, notieren Sie Direktive, Datei und Datum, und nehmen Sie die Bearbeitung über die Oberfläche vor, wenn es eine gibt, denn ein Neuaufbau überschreibt eine Handbearbeitung beim nächsten Speichern.

client-to-client ist ein eigenes Tor

Selbst innerhalb eines Subnetzes verwirft der Server Pakete, die von einem Client kommen und an einen anderen adressiert sind, sofern client-to-client nicht gesetzt ist. Dieses Schlüsselwort macht den Server zu einem Weiterleiter für Peer-Verkehr statt zu einem Endpunkt, der ihn nur annimmt. Es ist die zweite Bedingung, die Menschen nach der Korrektur der Topologie übersehen.

Das erstreckt sich nicht auf Broadcast. Die Einstellung leitet Unicast zwischen Clients weiter; sie macht den Tunnel nicht zu einem gemeinsamen Segment, und keine Menge davon wird eine Multicast-Erkennungsanfrage an jeden Peer zustellen.

TUN gegenüber TAP und was jedes tragen kann

Ein tap-Gerät in das LAN zu brücken bringt entfernte Clients in die Broadcast-Domäne des Büros, was die Erkennung vollständig löst. Der Preis sind die Plattformen, die TAP nicht implementieren, eine Brücke, die auf dem Server existieren muss, und eine Fehlerdomäne, in der ein Broadcast-Sturm auf dem Bürokabel jedes entfernte Notebook erreicht.

Für zwei oder drei Workstations, die Namensauflösung brauchen, ist ein hosts-Eintrag oder eine Unicast-Adresse weit billiger als eine Brücke. Greifen Sie zu TAP, wenn ein Protokoll, das Sie nicht ersetzen können, von der Erkennung auf Schicht 2 abhängt, und nicht früher.

Clients im selben Subnetz ohne Brücke

Eine Adresse aus dem LAN-Bereich zuzuweisen bringt den Client nicht auf das Kabel. Der Server routet zwischen Tunnel und Ethernet, sodass ARP für diese Adresse an der Serverschnittstelle endet und der Rest des LAN nie erfährt, wo sie wohnt.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP schließt diese Lücke, indem der Server im Namen des Clients antwortet. Für einen Bereich verwaltet parpd die Einträge, während Clients kommen und gehen, während die sysctl net.ipv4.conf.eth0.proxy_arp=1 für alles antwortet, das woandershin geroutet wird, was breit genug ist, um auf einem ausgelasteten Segment eigene Überraschungen zu schaffen.

Welchen Weg Sie auch wählen, entfernen Sie NAT zwischen Tunnel und Kabel. Eine MASQUERADE-Regel verbirgt genau die Adressierungsfrage, die Sie beantworten wollen. Sie hinterlässt der nächsten Person außerdem eine Topologie, über die sie von der Clientseite aus nicht nachdenken kann.

Bevor Sie etwas ändern, fangen Sie einen Versuch auf dem Server mit tcpdump -ni tun0 ab und prüfen Sie, ob das Peer-Paket überhaupt ankommt. Ankommen und verworfen werden deutet auf client-to-client; nie ankommen deutet auf Topologie oder Routing. Das OpenVPN-2.6-Handbuch dokumentiert beide Schlüsselwörter und die Standardtopologie, was es wert ist, mit Ihrer Version abzugleichen, bevor Sie eine Zeile aus einem Forumsbeitrag kopieren.

• Die tun-Schnittstelle zeigt eine Pool-Maske statt eines /30-Peer-Paars.
• Ein direkter Ping auf die andere Tunneladresse gelingt, bevor Sie die Erkennung testen.
• Die Serverkonfiguration enthält client-to-client, wann immer Peers Pakete austauschen müssen.
• Benennen Sie das Erkennungsprotokoll, das Sie testen, statt zu sagen, die App versage.
• Verwenden Sie TAP nur, wenn jede Clientplattform in der Gruppe es unterstützt.
• Halten Sie NAT aus dem Pfad zwischen Tunnel und LAN, wenn Erreichbarkeit im selben Subnetz zählt.