OpenVPN-Server auf Virtualbox-Gast. Verbindung kann hergestellt werden, aber Ping schlägt fehl

OpenVPN-Server auf Virtualbox-Gast. Verbindung kann hergestellt werden, aber Ping schlägt fehl

Als Entwicklungsumgebung für meinen Produktionsserver habe ich einen Virtualbox-Gast eingerichtet.

Ich kann jedoch keinen OpenVPN-Server einrichten. Ich kann mich problemlos mit meinem VPN verbinden (KDE NetworkManager), aber ichkann nichtPingen Sie anschließend sogar den VPN-Host an.

Meines Wissens handelt es sich hierbei um ein Routing-Problem. Bevor ich mich mit meinem VPN verbinde, sieht die Routing-Tabelle folgendermaßen aus:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.64.64.64     0.0.0.0         UG    0      0        0 ppp0
10.64.64.64     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
33.33.33.0      0.0.0.0         255.255.255.0   U     0      0        0 vboxnet0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 br0

Die Tabelle sieht so ausnachIch habe mich mit dem VPN verbunden:

$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.64.64.64     0.0.0.0         UG    0      0        0 ppp0
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.64.64.64     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
33.33.33.0      0.0.0.0         255.255.255.0   U     0      0        0 vboxnet0
33.33.33.24     10.64.64.64     255.255.255.255 UGH   0      0        0 ppp0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 br0

bitte beachten Sie: Ich möchte mein VPN nicht als Gateway verwenden, daher kümmere ich mich nicht um die Weiterleitung von Paketen. Ich möchte nur auf den Server (z. B. Apache) über eine andere VPN-Adresse als seine öffentliche Adresse zugreifen können, daher lege ich es nicht als Standard-GW fest.

Das ProblemMir scheint, dass die Adresse 33.33.33.24 auf der Schnittstelle ppp0 nicht erreicht werden kann, da es sich um eine lokale Adresse handelt, die erreichbar ist aufvboxnet0

$ ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
^C
--- 10.8.0.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

Das gleiche Setup funktioniert wie erwartet, wenn ich es auf einemechter Serverauf welches Gateway über ppp0 zugegriffen werden kann:

$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.64.64.64     0.0.0.0         UG    0      0        0 ppp0
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.64.64.64     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
33.33.33.0      0.0.0.0         255.255.255.0   U     0      0        0 vboxnet0
<real_gw_ip>    10.64.64.64     255.255.255.255 UGH   0      0        0 ppp0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 br0

$ ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=782 ms
64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=122 ms
^C
--- 10.8.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms

Ich stecke irgendwie fest, weil ich nicht dahinterkomme, wie ich das Routing oder NAT richtig einrichte, um das zu erreichen, was ich will, d. h.: auf die VMBox auf 33.33.33.24 per VPN über 10.8.0.1 zuzugreifen.

Jede Hilfe ist sehr willkommen. Ich habe vorerst keine weiteren Konfigurationen (ifconfig, syslog) eingefügt, um den Beitrag kürzer zu halten, da sie mir in Ordnung erscheinen (IP-Adressen zugewiesen, alle iptables zum Testen geleert usw.) und wie oben beschrieben, glaube ich, dass ich eine Ahnung habe, was das Problem verursacht, also korrigieren Sie mich bitte, wenn ich falsch liege.

Antwort1

Na gut. Wie so oft reicht es schon, die Probleme zu benennen, um die Antwort zu finden. Ein einfaches

$ sudo route del 33.33.33.24

auf dem Host behebt das Problem wie erwartet.

Ich werde es so schnell wie möglich als gelöst markieren. (2 Tage)

verwandte Informationen