Warum ein LAN-Host für die Adresse eines OpenVPN-Clients ARP-Anfragen stellt

Erreichbarkeitsprobleme zwischen einem LAN-Host und einem VPN-Client führen oft auf den Adressplan selbst zurück. Geben Sie diesem Host eine Schnittstelle in 10.0.100.0/22, behandelt er jede Adresse von 10.0.100.0 bis 10.0.103.255 als direkt verbunden, einschließlich eines Client-Pools, der stillschweigend in 10.0.101.0/24 liegt. Die Antwort geht nie an einen Router, denn aus Sicht des Hosts ist kein Router beteiligt. Das Paket ist an einen Nachbarn adressiert und wird auf dem Draht angefordert.

Dieser Mechanismus steckt hinter einer ganzen Familie von Meldungen: Der Tunnel ist oben, der Server hat eine Route, und der LAN-Host kann den Client trotzdem nicht erreichen.

Das /22, das das /24 verschluckt

Lesen Sie das Präfix als Bereich, nicht als Zeichenkette. Ein /22 umfasst 1024 Adressen, und 10.0.100.0/22 reicht von 10.0.100.0 bis 10.0.103.255, sodass ein Pool in 10.0.101.0/24 vollständig darin liegt. Der Fehler übersteht die Prüfung, weil die ersten Oktette des Pools anders aussehen als die ersten Oktette des LANs, und nur das dritte Oktett die Überschneidung verrät. Schreiben Sie beide Bereiche numerisch aus, bevor Sie sie für getrennt erklären.

Dieselbe Überschneidung kann auch umgekehrt auftreten. Ein Pool, der frei wirkt, weil ihn derzeit niemand nutzt, kann trotzdem in einem Präfix liegen, das ein Standortrouter ankündigt, und der Adressplan ist das einzige Dokument, das das zeigt.

Direkt verbunden heißt ARP, nicht Routing

Wenn ein Host mit einer /22-Schnittstelle an 10.0.101.25 sendet, vergleicht der Kernel das Ziel mit dem Präfix der Schnittstelle und findet eine Übereinstimmung. Das Paket wird zu einer Nachbarabfrage statt zu einem gerouteten Paket, und auf Ethernet ist die Nachbarabfrage eine ARP-Anfrage für diese Adresse. Gehört die Adresse zu einem VPN-Client hinter einem gerouteten Gateway, besitzt kein Host im LAN sie, sodass die Anfrage unbeantwortet bleibt und die Pakete verworfen werden. Der Tunnel ist nicht schuld, und der Client sieht den Verkehr nie.

Deshalb wirkt der Ausfall asymmetrisch und mitunter sporadisch. Der VPN-Host kann das LAN oft erreichen, weil seine eigenen Routen in die richtige Richtung zeigen, während der LAN-Host nicht antworten kann, und alles, was einen veralteten ARP-Eintrag zwischenspeichert, lässt das Symptom flackern.

TUN, TAP und was jedes überträgt

Ein TUN-Gerät überträgt IP-Pakete, und ein TAP-Gerät überträgt Ethernet-Frames. Eine geroutete TUN-Verbindung muss kein ARP übertragen, um IP-Erreichbarkeit herzustellen, und genau deshalb ist die unbeantwortete Anfrage oben zu erwarten und nicht als Defekt zu werten. TAP mit einer bewusst gesetzten Bridge kann die Broadcast-Domain erweitern und ARP funktionsfähig machen, aber es verändert, was der Client sieht, verlangt Endpunkte, die dieselbe Rahmung unterstützen, und ist eine Neugestaltung des Netzmodells statt einer Reparatur für ein überlappendes Präfix. Ein geroutetes Deployment auf TAP umzustellen, um einen Adressplanfehler zu beheben, tauscht ein kleines Problem gegen ein größeres.

Halten Sie fest, wo die ARP-Anfrage aufgetreten ist und welches System sie ausgesendet hat, bevor Sie Schlüsse ziehen. Der Absender sagt Ihnen, was er über das Ziel glaubt, nicht was der Tunnel tut.

Planen Sie einen Pool, der sich nicht überschneiden kann

Wählen Sie einen Pool außerhalb jedes verbundenen Präfixes und jedes angekündigten Standortpräfixes und fügen Sie dann die Routen hinzu, die ihn in beide Richtungen erreichbar machen. Ein Bereich wie 10.8.0.0/24 in einem ungenutzten Teil des Plans ist leicht nachzuvollziehen, und ein LAN, das ihn erreichen muss, erhält eine statische Route, die auf den VPN-Server zeigt. Ändern Sie die Zuteilung, die angekündigten Routen, die erlaubten Quelladressen und die Firewall-Regeln gemeinsam, denn sie beschreiben ein Design und nicht vier Einstellungen.

Source-NAT auf dem Server kann den Pool hinter einer im LAN routbaren Adresse verbergen, und es ist ein legitimes Migrationswerkzeug. Es schreibt allerdings die Quelle um, sodass das LAN die Fähigkeit verliert, Verbindungen einzelnen Clients zuzuordnen und Regeln pro Client anzuwenden.

Nutzen Sie für die Abnahme die tatsächlich zugewiesene Adresse des echten Clients und eine echte Anwendungsanfrage von einem LAN-Host und bestätigen Sie dann, dass die Antwort dem geplanten Gateway folgt und nicht dem Draht.