Erreicht ein WireGuard-Client einen OpenVPN-Client nicht?

Beide Tunnel kommen zustande, jeder Client erreicht das Gateway, und in dem Moment, in dem einer die Adresse des anderen versucht, verschwinden die Pakete. An keinem der beiden Handshakes ist etwas falsch, und kein noch so häufiges Neuausstellen von Schlüsseln ändert das. Das Gateway befördert gewöhnliche unverschlüsselte IP-Pakete zwischen zwei seiner eigenen Schnittstellen, die Protokolle müssen einander also nie verstehen; was sie brauchen, sind drei Dinge, die kein Handshake liefert. Zielabdeckung auf dem Ursprungs-Client, Quelleneigentum am Gateway und ein Rückweg auf der Gegenseite. Das Symptom ist bei allen drei dasselbe, weshalb sie gemeinsam diagnostiziert werden.

Dem Symptom fehlt jeweils ein Teil

Dieses Design verwendet einen WireGuard-Pool 10.71.0.0/24 auf wg1 und einen OpenVPN-Pool 10.72.0.0/24 auf tun1, beide enden auf einem Gateway. Die getestete Anfrage läuft von 10.71.0.5 zu HTTPS auf 10.72.0.30. Jeder Schritt unten betrifft genau diesen einen Fluss. Jede Prüfung hat eine andere Fehlersignatur, obwohl der Nutzer sie gleich erlebt, und meist fehlt jeweils nur eine der drei.

Prüfen Sie zuerst, ob beide Pools wirklich auf diesem Gateway liegen und ob die Weiterleitung in dem Namespace aktiv ist, in dem die Tunnel leben. Ein Gateway, das beide Protokolle in verschiedenen Namespaces beendet, leitet nichts zwischen ihnen weiter, und das lohnt sich auszuschließen, bevor Sie irgendeine Peer-Konfiguration lesen.

Erweitern Sie die Zielabdeckung des Spoke

Auf dem WireGuard-Client muss der bestehende Peer-Eintrag das Gateway für das OpenVPN-Ziel auswählen, das heißt, das Zielpräfix muss in der Allowed-Liste dieses Peers stehen. Es hinzuzufügen erzeugt keinen zweiten Tunnel; es ändert, welchen Peer der Client wählt, wenn er diese Adresse nachschlägt, und mit wg-quick folgt die Route normalerweise automatisch der Liste.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Lassen Sie die echten Schlüssel- und Endpunkt-Zeilen unangetastet und bedenken Sie, dass ein Manager mit Table = off überhaupt keine Route aus dieser Liste übernimmt. In diesem Fall muss dasselbe Präfix von dem, der es besitzt, in die Routing-Tabelle des Systems eingetragen werden, und eine dort fehlende Route sieht genau wie ein fehlendes erlaubtes Präfix aus.

Behalten Sie das Quelleneigentum am Gateway

Der Peer-Eintrag dieses Clients am Gateway sollte weiterhin genau die Quelladresse dieses Clients besitzen. Erlaubte Adressen werden in beide Richtungen geprüft: Sie wählen einen Peer für ausgehenden Verkehr und sie bestätigen, dass die Quelle eines eingehenden Pakets zu dem Peer gehört, der es gesendet hat. Den OpenVPN-Pool in den Eintrag des Spoke zu schreiben, weil der Spoke ihn erreichen will, ist der Fehler, der den Verkehr zum falschen Teilnehmer schickt.

AllowedIPs = 10.71.0.5/32

Lesen Sie diesen Eintrag als Eigentumserklärung und nicht als Routing-Bequemlichkeit. Alles andere, was der Client erreichen muss, gehört in die Zielliste des Clients, nicht in die Vorstellung des Gateways davon, was dieser Peer senden darf.

Geben Sie der OpenVPN-Seite einen Rückweg

Das Ziel braucht jetzt eine Route zurück zur WireGuard-Quelle, und bei Clients aus einem Pool kommt sie normalerweise als gepushte Route vom OpenVPN-Server. Pushen Sie sie nur an Clients, die sie haben sollten, und bestätigen Sie auf dem Client, dass sie angenommen wurde, statt anzunehmen, dass die Anweisung angewendet wurde.

push "route 10.71.0.0 255.255.255.0"

Routenverteilung ist keine Autorisierung. Wenn das Ziel hinter einem anderen OpenVPN-Client liegt statt im Pool, kommen das LAN-Eigentum dieses Clients und seine Weiterleitungsanforderungen zum Design hinzu, und die gepushte Route ist nur die erste Hälfte. Formulieren Sie die Anforderung als Graphen, bevor Sie Anweisungen hinzufügen: welcher Knoten welches Präfix besitzt und welcher Knoten dorthin weiterleitet.

Erlauben Sie genau den einen Dienst, den Sie erlauben wollten

Mit aktivierter Weiterleitung und beiden routbaren Pools bleibt die Frage der Politik. Schreiben Sie die Regel für den konkreten Fluss statt für das Schnittstellenpaar im Allgemeinen, sehen Sie sie vor dem Anwenden in der Vorschau an und behalten Sie den zustandsbehafteten Rückweg, damit Antworten nicht als neue Verbindungen blockiert werden. Ein Probelauf kostet nichts und zeigt genau, was hinzugefügt würde.

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

Das sind Weiterleitungsregeln, getrennt von den Listener-Regeln des Gateways für die beiden VPN-Dienste. Die äußeren UDP-Ports zu öffnen autorisiert die innere Anfrage nicht, und die innere Anfrage zu autorisieren erfordert weder uneingeschränktes SSH zum Gateway noch ein Standard-Allow auf der Weiterleitung. Auch die eigene Firewall des Ziels und die Listen-Adresse müssen zusammenpassen, denn ein an Loopback gebundener Dienst weist selbst das sorgfältigst geroutete Paket ab. Politik, die nur eine Richtung des Gesprächs abdeckt, scheitert typischerweise an einer erfolgreichen Anfrage und einer stummen Antwort, was das verwirrendste der drei Ergebnisse ist.

Gegenseitige Routen bedeuten normalerweise, dass keine Quellübersetzung nötig ist, was die WireGuard-Adresse am Ziel erhält und Protokolle lesbar macht. Fügen Sie kein pauschales Masquerading hinzu, nur weil zwei Protokolle beteiligt sind, und entfernen Sie keine bestehende Übersetzungsregel, ohne zu wissen, was davon abhängt. Prüfen Sie dann den einzelnen Fluss von Anfang bis Ende und testen Sie auch eine unerlaubte Quelle oder einen Port: ein funktionierender Handshake auf jeder Seite beweist weder die Querroute noch die Isolation.