Weiterleitung des Datenverkehrs auf einer virtuellen Linux-Maschine, die über einen über OpenVPN verbundenen GRE-Tunnel empfangen wird

Ich versuche, den für das öffentliche Internet bestimmten Datenverkehr über ein OpenVPN-Netzwerk zu leiten, wobei der Datenverkehr das VPN über einen anderen Client im Netzwerk (der zufällig eine VirtualBox-VM ist) verlässt.

Um die Topologie zu erläutern, verwende ich Client A als Traffic Originator und Client E als gewünschten Ausgang / vermuteten Ausgangspunkt des Datenverkehrs. Sowohl die Clients als auch der Server sind Linux-Maschinen.

Die Clients A und E sind beide mit einem OpenVPN-Server verbunden und verfügen über lokale Adressen in einem vom Server erstellten Subnetz. Nehmen wir an, 10.8.0.0/16, wo der Server 10.8.0.1 hat und die Clients A, E ... 2 und ... 3 haben. Die Clients können sich über den Server erreichen. Der OpenVPN-Server verfügt auch über einen GRE-Tunnel zum Client E, der über der OpenVPN-Verbindung ausgeführt wird.

Derzeit sieht die abstrakte Topologie / Ablauf wie folgt aus:

(A) ==> (OpenVPN Server) ==> (E) -> ... 

Das Problem, das ich habe, ist, dass der Datenverkehr, sobald er den Client E erreicht, nicht über das Standard-Gateway von E und in das öffentliche Internet gesendet wird.

Die relevante Konfiguration der Clients ist wie folgt:

EIN:

default gateway is the OpenVPN server (10.8.0.1) 

OpenVPN-Server:

ip rule add from 10.8.0.2 lookup node 

Die Routing-Tabelle 'Node' hat die Routen:

default dev gre5 scope link  10.8.0.0/16 dev tun0 proto static scope link src 10.8.0.1  

E:

default gateway is the VirtualBox nat network (through which it has a working Internet connection)  net.ipv4.ip_forward = 1  net.ipv4.conf.all.forwarding = 1  net.ipv4.conf.default.forwarding = 1  iptables -t nat -A POSTROUTING -s 10.8.0.0/16 -o eth0 -j MASQUERADE  The iptables policy for E's filter table is to accept everything. 

Mit tcpdump kann ich die Pakete von A sehen, die aus der GRE-Tunnelschnittstelle von E kommen, aber sie scheinen auf E zu fallen. Ich konnte überprüfen, dass sie über keine der Schnittstellen von E weitergeleitet werden (Loopback, die virtuellen Tunnel noch die VBox-nat-Netzwerkschnittstelle; eth0 oben).

Fehlt mir eine spezielle Konfiguration für den GRE-Tunnel oder etwas, das damit zusammenhängt? Bezieht sich dieses Problem auf die Tatsache, dass der Endpunktclient eine VM ist?
Gibt es optional eine bessere Möglichkeit, den für ausländische Netzwerke bestimmten Verkehr durch ein OpenVPN-Netzwerk und einen Client zu leiten?

Gerne stehe ich Ihnen bei Bedarf zur Verfügung.

Routingtabelle von E, wie von @MariusMatutiae angefordert

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 10.0.2.2 0.0.0.0 UG 0 0 0 eth0 10.0.2.0 * 255.255.255.0 U 0 0 0 eth0 10.8.0.0 * 255.255.0.0 U 0 0 0 tun0 10.10.5.0 * 255.255.255.0 U 0 0 0 gre5 192.168.56.0 * 255.255.255.0 U 0 0 0 eth1 

Wenn eth0 mit dem VBox-nat-Netzwerk verbunden ist, ist eth1 mit einem Host-Netzwerk verbunden, das ich für ssh in die VM verwende. Tun0 ist die OpenVPN-Schnittstelle und gre5 ist die Schnittstelle zum GRE-Tunnel.