OpenVPN auf AWS (funktioniert im NAT-Modus, aber nicht im Routing-Modus)

Question

Ich habe ein brandneues VPC (10.0.0.0/16) mit 3 öffentlichen Subnetzen (die auf ein IGW verweisen) und 3 privaten Subnetzen (mit jeweils einem NAT-GW). Ich habe ein OpenVPN-Gerät im öffentlichen Subnetz bereitgestellt und es für die Verwendung des NAT-Modus konfiguriert ( Yes, using NATin der Routing-Konfiguration). Ich habe auch eine Testinstanz in einem der privaten Subnetze. Sowohl die OpenVPN-Instanz als auch die Testinstanz haben SG-Gruppen mit „großzügiger“ Flexibilität (d. h. alles ist rein-raus erlaubt … zu Testzwecken). Auf dem OpenVPN habe ich es 10.0.0.0/16vor Specify the private subnets to which all clients should be given access (one per line):Ort konfiguriert.

Von meinem Mac (im Heimnetzwerk 192.168.178.0/24) aus kann ich einen Tunnel aufbauen und problemlos auf die Testinstanz zugreifen. Alles gut.

Jetzt möchte ich in den Routenmodus wechseln.

• Ich habe den Routing-Modus auf geändert Yes, using Routing. Ich habe die Quell-/Zielprüfung der OpenVPN-Instanz deaktiviert.
• Ich habe allen 4 Routing-Tabellen im VPC (3 x die privaten Subnetze und 1 x das öffentliche Subnetz) eine statische Anweisung hinzugefügt, um festzulegen, dass der an 192.168.178.0/24(mein Heimnetzwerk) gerichtete Datenverkehr an die OpenVPN-Instanz gehen soll (für das öffentliche Subnetz war dies wahrscheinlich nicht erforderlich).
• Ich habe 192.168.178.0/24dem Specify the private subnets to which all clients should be given access (one per line):Feld zusätzlich etwas hinzugefügt (ich bin nicht sicher, ob das erforderlich war) 10.0.0.0/16.
• Ich habe die Benutzerberechtigungen für den Benutzer, mit dem ich mich anmelde, neu konfiguriert Use Routingund beide oben genannten Subnetze (10. und 192.) erneut angegeben.

Ich kann den Tunnel immer noch aufbauen. Ich kann die interne IP der OpenVPN-Instanz erreichen:

$ traceroute 10.0.4.223          
traceroute to 10.0.4.223 (10.0.4.223), 64 hops max, 52 byte packets
 1  10.0.4.223 (10.0.4.223)  178.345 ms  174.470 ms  173.680 ms
$

Aber ich kann die Testinstanz im privaten Subnetz NICHT erreichen:

$ traceroute 10.0.165.139
traceroute to 10.0.165.139 (10.0.165.139), 64 hops max, 52 byte packets
 1  172.27.232.1 (172.27.232.1)  194.976 ms  177.014 ms  174.402 ms
 2  * * *
 3  * * *
 4  * * *
^C
$

Interessanterweise kann ich meinen OpenVPN-Server nicht erreichen, wenn ich mich per SSH mit ihm in Verbindung setze und versuche, einen NGINX auf meiner lokalen Workstation zu curlen, auf der ich den Tunnel gestartet habe. Es sieht so aus, als ob die Workstation den OpenVPN-Server erreichen kann (siehe die Ablaufverfolgung oben 10.0.4.223), aber der OpenVPN-Server kann die Workstation (aus irgendeinem Grund) nicht erreichen.

Es sieht so aus, als ob der von der Workstation initiierte Datenfluss in der Lage ist, eine Route zur (und zurück von) OpenVPN-Instanz zu finden. Allerdings bricht die Route irgendwo auf dem Weg von der Workstation zur Testinstanz (und zurück) ab UND sie scheint auch abzubrechen, wenn sie von der OpenVPN-Instanz zur Workstation initiiert wird (siehe Curl).

Answer 1

Ich habe schließlich herausgefunden, dass das OpenVPN Access Server-Gerät nicht so konfiguriert werden kann, dass es eine Verbindung zur nativen IP des Clients im lokalen Subnetz herstellt. Der Client kann jedoch über die vom VPN zugewiesene Tunnel-IP erreicht werden. Diese IP kann statisch für jeden Benutzer konfiguriert werden oder aus einem auf dem Gerät definierten Pool stammen.

In meinem Fall habe ich beides konfiguriert (siehe Bild).

Es ist wichtig zu wissen, dass dies auch die Subnetze sind, die in den Routing-Informationen verwendet werden müssen. Das heißt, eine IP, die sich im Netzwerk 10.0.0.0/16 befindet, kann das Client-Gerät über eine der zugewiesenen 172.27-Adressen erreichen, und daher sind es die 172.27-Netzwerke, die in der Routing-Tabelle angegeben werden müssen (und NICHT das lokale native Netzwerk des Client-Geräts – in meinem Beispiel 192.168.178.0/24).