OpenVPN-Verkettung

Ich versuche, eine OpenVPN- "Kette" einzurichten, ähnlich wie hier beschrieben . Ich habe zwei separate Netzwerke, A und B. Jedes Netzwerk verfügt über einen OpenVPN-Server, der einen Standardansatz für "Road Warrior" oder "Client / Server" verwendet. Ein Client kann eine Verbindung zu einem der beiden herstellen, um auf die Hosts / Dienste in dem jeweiligen Netzwerk zuzugreifen.

Aber Server A und B sind auch verbunden miteinander . Die Server in jedem Netzwerk haben eine "Site-to-Site" -Verbindung zwischen den beiden.

Was ich erreichen möchte, ist die Möglichkeit, als Client eine Verbindung zu Netzwerk A herzustellen und dann Verbindungen zu Hosts in Netzwerk B herzustellen. Ich verwende Tun / Routing für alle VPN-Verbindungen. Die "Kette" sieht ungefähr so ​​aus:

[Client] ---> [Server A] ---> [Server A] ---> [Server B] ---> [Server B] ---> [Host B] 

(tun0) (tun0) (tun1) (tun0) (eth0) (eth0)

Die ganze Idee ist, dass Server A Datenverkehr, der für Netzwerk B bestimmt ist, über das auf tun1 eingerichtete "Site-to-Site" -VPN weiterleiten sollte, wenn ein Client von tun0 versucht, eine Verbindung herzustellen.

Ich habe dies einfach getan, indem ich zwei Verbindungsprofile auf Server A eingerichtet habe. Ein Profil ist eine Standardserverkonfiguration, die auf tun0 ausgeführt wird und ein virtuelles Client-Netzwerk, einen IP-Adresspool, Push-Routen usw. definiert. Das andere ist eine Client- Verbindung zu Server B, die ausgeführt wird auf tun1. Bei aktiviertem ip_forwarding habe ich den Clients einfach eine "Push-Route" hinzugefügt, die eine Route zum Netzwerk B ankündigt.

Auf Server A scheint dies zu funktionieren, wenn ich mir die Ausgabe von tcpdump anschaue. Wenn ich mich als Client verbinde und dann einen Host in Netzwerk B anpinge, kann ich sehen, dass der Datenverkehr von tun0 nach tun1 auf Server A weitergeleitet wird:

tcpdump -nSi tun1 icmp

Das Seltsame ist, dass ich nicht sehe, dass Server B diesen Verkehr durch den Tunnel empfängt. Es ist, als würde Server A es wie vorgesehen über die Site-to-Site-Verbindung senden, aber Server B ignoriert es vollständig. Wenn ich nach dem Datenverkehr auf Server B suche, ist er einfach nicht vorhanden.

Ein Ping von Server A -> Host B funktioniert einwandfrei. Ein Ping von einem mit Server A verbundenen Client zu Host B funktioniert jedoch nicht.

Ich frage mich, ob Server B den Datenverkehr ignoriert, weil die Quell-IP nicht mit dem Client-IP-Pool übereinstimmt, den er an Clients verteilt. Weiß jemand, ob ich etwas auf Server B tun muss, damit der Datenverkehr angezeigt wird?

Dies ist ein kompliziertes Problem, also danke, wenn du so weit bei mir geblieben bist.

Ich habe die Lösung dafür gefunden. Es ist nicht erforderlich, mehrere / redundante VPN-Verbindungen zu haben, wie in Antwort 1 beschrieben. Ich glaube auch nicht, dass es irgendetwas getan hätte, um mein Problem zu lösen, so sehr ich das Feedback geschätzt habe.

Das Problem ist darauf zurückzuführen, dass ein OpenVPN-Server nur dann IP-Verkehr durch den Tunnel des verbundenen Clients akzeptiert, wenn die Quell-IP-Adresse mit der übereinstimmt, die der Server dem Client beim Einrichten des Tunnels zugewiesen hat. Datenverkehr, der von einer anderen Quell-IP-Adresse stammt, die durch den Tunnel geleitet wird, wird vom Server vollständig ignoriert.

Schauen Sie sich Folgendes an:

10.2.1.15 10.2.0.1/123.123.123.1 124.124.124.1/10.1.0.1 10.1.1.20
  (eth0) (eth0 / eth1) (eth0 / eth1) (eth0)
---------- ---- --------- ------------ ----------
| Host A | ------------- | Gateway 1 | -------------------------------------- | Gateway 2 | -------- | Host B |
---------- -------------- {INTERNET} ---------------- ------- ----
                              VPN CLIENT VPN SERVER
                              172.16.1.12 172.16.2.1
                                   (tun0) (tun0)

In diesem Beispiel ist "Gateway 1" der VPN-Client, der einen Tunnel zu "Gateway 2" als VPN-Server erstellt. Was wir erreichen wollen, ist die Fähigkeit von Host A, über das VPN mit Host B zu kommunizieren. Daher haben wir eine Standard-OpenVPN-Verbindung mit Gateway 1 als Client zum Gateway 2-Server eingerichtet. Jedes Gateway verfügt über eine "öffentliche" und eine "private" Schnittstelle. Eine für das private Netzwerk und eine für das öffentliche Internet. Wenn die VPN-Verbindung hergestellt ist, verwendet jeder Server eine zusätzliche "tun0" -Schnittstelle. Gateway 2, das als VPN-Server fungiert, akzeptiert die Verbindung von Gateway 1 und weist ihr eine IP von 172.16.1.12 zu.

Das Problem ist, dass Gateway 2 nur dann Datenverkehr durch diesen VPN-Tunnel akzeptiert, wenn die Quell-IP 172.16.1.12 lautet .

Dies funktioniert einwandfrei, wenn Gateway 1 eine Verbindung zu Host B herstellen möchte. Es ist jedoch ein Problem, wenn Host A versucht, eine Verbindung zu Host B herzustellen. Wenn Host A versucht, eine Verbindung herzustellen, fungiert Gateway 1 als Router und leitet den Datenverkehr korrekt durch den VPN-Tunnel über Gateway 2 (vorausgesetzt, Sie haben Ihre Routen korrekt eingerichtet). Wenn Sie tcpdump auf dem tun0- Gerät von Gateway 1 ausführen , wird sogar der Datenverkehr von Host A durch den Tunnel geleitet, der für das andere Netzwerk bestimmt ist. Gateway 2 sieht die Quell-IP-Adresse jedoch als 10.2.1.15 an, die nicht mit der IP-Adresse übereinstimmt, die es für die Verbindung zugewiesen hat, und ignoriert sie vollständig.

Die Lösung besteht also darin, Gateway 2 so zu konfigurieren , dass Datenverkehr vom 10.2.0.0/16-Netzwerk über den VPN-Tunnel akzeptiert wird. Der VPN-Server muss mit einer iroute- Einstellung konfiguriert werden . Das Verfahren zum Einrichten und alle Konfigurationsparameter werden auf der offiziellen OpenVPN-Website hier erläutert , sodass ich es in diesem Beitrag nicht noch einmal erläutern werde.

Ich schlage vor, dass Sie beim Lesen dieser Dokumentation besonders beachten, dass Sie in Ihrer OpenVPN-Konfiguration Client-Konfigurationsverzeichnisse (CCD) verwenden müssen, um iroute verwenden zu können . Stellen Sie sicher, dass Sie diesen Teil der Dokumentation sorgfältig gelesen haben. Natürlich müssen Sie auch Routen auf allen Ihren Gateways einrichten, damit diese wissen, wie der Verkehr durch den VPN-Tunnel geleitet wird. Unter Bezugnahme auf das obige Diagramm müssten Sie dennoch eine Route auf Gateway 2 wie folgt hinzufügen :

route add -net 10.2.0.0 netmask 255.255.0.0 gw 172.16.1.12 tun0

und auf Gateway 1 wie folgt:

route add -net 10.1.0.0 netmask 255.255.0.0 gw 172.16.2.1 tun0

Damit der Datenverkehr von Host B beim Versuch, eine Verbindung zu Host A herzustellen , ordnungsgemäß über das VPN geleitet wird.

In meinem speziellen Fall fungiert Gateway 1 sowohl als Client für Gateway 2 als auch als Server für andere Clients, von denen aus eine Verbindung hergestellt wird Das Internet, das Zugriff auf Host A benötigt. Daher musste ich zwei Schnittstellen erstellen, tun0 und tun1, damit eine für die Clientverbindung mit dem anderen Netzwerk und die andere als Server für die Verbindung von Straßenkämpfern verwendet werden kann Ich muss außerdem zusätzliche Routen hinzufügen, damit ich über das Internet eine VPN-Verbindung zu Gateway 1 (Server) herstellen und den Datenverkehr an Host B im anderen Netzwerk weiterleiten kann.

Ich hoffe, das hilft anderen, die darüber verwirrt sind.

Ich habe das kürzlich eingerichtet. Die Magie, die ich brauchte, war das Hinzufügen korrekter Routenbefehle in der openvpn.confs.

Meine Konfiguration ist sogar etwas komplexer als deine. Ich habe drei Standorte, die zufällig EC2-Regionen sind: us-east-1 (VA), us-west-1 (CA) und us-west-2 (OR). Jeder hat seinen eigenen privaten IP-Bereich wie folgt:

VA 10.1.0.0/16
CA 10.0.0.0/16
OR 10.10.0.0/16

Die Konfiguration ist OR <=> CA <=> VA, wobei CA einen zentralen "Hub" bildet.

Host vavpn

config va-to-ca.conf

# Sample OpenVPN configuration file using a pre-shared static key
# Port to use: 1194 is the official IANA port number
port 1194

# Use a dynamic tun device.
dev tun

# Remote peer and network
remote 54.241.174.228
route 10.0.0.0 255.255.0.0
route 10.10.0.0 255.255.0.0

# Configure local and remote VPN endpoints
ifconfig 169.254.255.1 169.254.255.2

# The pre-shared static key
secret ovpn.key

# keepalive
keepalive 10 120

Host Cavpn

config ca-to-va.conf

# Sample OpenVPN configuration file using a pre-shared static key
# Port to use: 1194 is the official IANA port number
port 1195

# Use a dynamic tun device.
dev tun

# Remote peer and network
remote 54.244.21.223
route 10.10.0.0 255.255.0.0

# Configure local and remote VPN endpoints
ifconfig 169.254.255.3 169.254.255.4

# The pre-shared static key
secret ovpn.key

# keepalive
keepalive 10 120

config ca-to-or.conf

# Sample OpenVPN configuration file using a pre-shared static key
# Port to use: 1194 is the official IANA port number
port 1194

# Use a dynamic tun device.
dev tun

# Remote peer and network
remote 54.236.173.50
route 10.1.0.0 255.255.0.0

# Configure local and remote VPN endpoints
ifconfig 169.254.255.2 169.254.255.1

# The pre-shared static key
secret ovpn.key

# keepalive
keepalive 10 120

Host orvpn

config or-to-ca.conf

# Sample OpenVPN configuration file using a pre-shared static key
# Port to use: 1194 is the official IANA port number
port 1195

# Use a dynamic tun device.
dev tun

# Remote peer and network
remote 54.241.174.228
route 10.0.0.0 255.255.0.0
route 10.1.0.0 255.255.0.0

# Configure local and remote VPN endpoints
ifconfig 169.254.255.4 169.254.255.3

# The pre-shared static key
secret ovpn.key

# keepalive
keepalive 10 120

Beachten Sie auch die Routenbefehle, die zum anderen Endpunkt führen. Ich denke, wenn Sie Ihr Netzwerk und alle IPs an einem der beiden Endpunkte gestalten, können Sie mein Beispiel schnell an Ihre Topologie anpassen.