OpenVPN-Client ohne Redirect-Gateway, der dreieckiges Routing und IP-Spoofing ausführt, funktioniert unter Ubuntu nicht

Ich habe einen OpenVPN-Client, der auf einem meiner Server ausgeführt wird und eine öffentliche IP in einem Remote-Netzwerk in einem anderen Land erhält. Die Client-Konfiguration lautet wie folgt:

dev tap
remote a.b.30.7
float a.b.30.7
port 5167
ifconfig a.b.28.178 255.255.255.128
route-gateway a.b.28.129
#redirect-gateway def1
secret woot.key
cipher AES-128-CBC
dhcp-option DNS a.b.8.8

Das Redirect-Gateway wird kommentiert, damit mein Server (auf dem der OpenVPN-Client ausgeführt wird) nicht von der VPN-Verbindung "übernommen" wird. Ich kann Dienste an die tap0-Schnittstelle (z. B. httpd usw.) binden und eine Website von dieser IP in einem anderen Land aus betreiben. Der ISP, auf dem sich der Server befindet, auf dem der openVPN-Client ausgeführt wird, verfügt nicht über eine Ausgangsfilterung, sodass der Datenverkehr für das VPN nur über das Standard-Gateway von eth0 mit der öffentlichen IP in einem anderen Land übertragen werden kann. Nur eingehender Datenverkehr wird über das VPN geleitet (dh eingehende httpd-Anforderungen), ausgehender Datenverkehr wird jedoch mit der öffentlichen VPN-IP gefälscht. Ohne ANY Ausmisten mit Routen oder iptables um, das funktioniert einfach ohne Probleme .. auf einem Debian - Server. Der offensichtliche Vorteil ist, dass ich die Geschwindigkeit und das Routing meiner regulären eth0-Schnittstelle habe, aber mit einer IP in einem anderen Land.

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
x.y.150.64   0.0.0.0         255.255.255.224 U     0      0        0 eth0
a.b.28.128    0.0.0.0         255.255.255.128 U     0      0        0 tap0
0.0.0.0         x.y.150.65   0.0.0.0         UG    0      0        0 eth0

xy ist das eigentliche Servernetzwerk und ab ist das Remote-OpenVPN-Netzwerk.

Das Problem? Genau das gleiche funktioniert in Ubuntu nicht und ich kann nicht herausfinden, warum. Ich habe dies auf unzähligen Debian-Servern ohne Probleme und absolut ohne benutzerdefinierte Routen oder irgendeine Art von iptables-Regeln getan. Keiner der Server führt eine Firewall aus. Ich glaube, das ist ein sehr grundlegendes Problem, oder Ubuntu hat eine seltsame Sache vor sich. Es ist erwähnenswert, dass das VPN auf den Ubuntu-Servern funktioniert, wenn ich das Redirect-Gateway auskommentiere (wie es sollte), außer dies ist nicht das, was ich will. Ich muss immer noch über die Hauptschnittstelle eth0 auf den Server zugreifen.

Debian Server Trace (ARBEITEN):

# traceroute -i tap0 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets
 1  blah (a.b.29.1)  39.161 ms  39.140 ms  39.332 ms
 2  asdf (a.b.30.1)  40.870 ms  40.879 ms  40.850 ms
 3  sth-sbb2-ank35-1-ge26-100.dcs.net (217.78.35.5)  40.816 ms  40.818 ms  40.783 ms
 4  google-gw.dcs.net (217.78.35.14)  40.780 ms  40.601 ms  40.565 ms
 etc. fine here.

Ubuntu Server Trace (funktioniert nicht):

# traceroute -i tap0 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 borked.

8.8.8.8 googelt öffentliches DNS.

Auf die VPN-IP kann von außen nicht zugegriffen werden. Interessanterweise, wenn ich:

ssh -b [debian.server.openvpn.client.IP] user@[ubuntu.server.openvpn.client.IP]

Ich kann es verbinden / pingen / sehen. Dies geschieht mit zwei separaten VPN-Clients, die sowohl auf der Debian- als auch auf der Ubuntu-Box im selben ab-Netzwerk wie in der Routentabelle ausgeführt werden (unterschiedliche IP-Adressen im Remote-Netzwerk). Die IP-Client-IP des Debian-Servers ist öffentlich zugänglich, auf dem Ubuntu-Server jedoch nicht! Nur von innen ab!

Das Ziel ist es, den Datenverkehr von eth0 zu fälschen, anstatt ihn über das VPN zurückzusenden und die VPN-Bandbreite zu verschwenden. Die gleiche VPN-Konfiguration funktioniert auch problemlos auf einem Debian-Server. Ich kann die Konfiguration für das VPN auf der Ubuntu-Box auf die Debian-Box setzen und es ist in Ordnung.

Auf dem Debian-Server wird Debian 5 64bit mit 2.6.32-bpo.5-xen-amd64 ausgeführt. Auf dem
Ubuntu-Server wird Ubuntu 10.04.1 LTS mit 2.6.32-24-Server ausgeführt

Ich dachte, dies könnte ein Problem mit Kernelmodulen und tun.ko sein, da ich es nicht mit modprobe -l auf dem Ubuntu-Server, sondern mit DID auf dem Debian-Server gesehen habe. Siehe https://bugs.launchpad.net/ubuntu/+source/linux/+bug/565856, wenn Sie interessiert sind. Ich habe die Problemumgehungen ohne Erfolg versucht. Ich denke es ist etwas anderes.

Jede Hilfe wird sehr geschätzt! Ich entschuldige mich für das Fehlen geeigneter Netzwerkbedingungen, wenn nötig, ich habe nur fortgeschrittene Netzwerkkenntnisse und da dies für mich mit Leichtigkeit in Debian funktioniert hat, musste ich nichts Besonderes tun.

Ich muss zugeben, dass ich (noch) nicht vollständig verstehe, was Sie erreichen wollen. Aber ich denke, Sie möchten, dass Ihr Ubuntu (und Debian) Server über eine IP erreichbar ist, die Sie über OpenVPN (eingehender Datenverkehr) erhalten haben, aber Ihren eigenen (= Ubuntu Server) Datenverkehr über die eth0-Schnittstelle lokal an Ihren (Ubuntu) Server senden ("Spoofing") ") die VPN-IP. Oder in diese Richtung. Ich bin mir nicht sicher, ob dies eine sehr gute Idee ist (hängt wahrscheinlich davon ab, warum Sie es tun), aber ich gehe davon aus, dass es einen Grund dafür gibt und wie Sie sagen, dass es mit Debian funktioniert. Lassen Sie uns dies also nicht näher erläutern (obwohl es später noch wichtig sein könnte).

Weiter frage ich mich warum die Linie

route-gateway a.b.28.129

Die in Ihrer VPN-Konfiguration enthaltene Version (scheint) nicht zu einem Eintrag in Ihrer Routing-Tabelle zu führen.

Ich bin mir auch nicht sicher, was das Ziel / die Einsicht der beiden von Ihnen gezeigten Traceroutes ist ... Sie scheinen zu versuchen, 8.8.8.8durch den VPN-Tunnel zu tracerouten . Da es sich um ausgehenden Verkehr handelt, verstehe ich seine Relevanz für Ihr Problem nicht wirklich. Und ich würde sagen (in Bezug auf Ihre Routing-Tabelle), dass der Verkehr, den Sie auf diese Weise generieren, nicht durch den Tunnel fließt (sollte es nicht sein?). Ich sehe, dass es so aussieht, als ob dies bei Debian der Fall ist ... Aber ich verstehe nicht, warum dies der Fall ist. Wenn ich mir die Routing-Tabelle anschaue, würde ich eher annehmen, dass die Traceroute-Pakete, auf denen Sie versenden möchten, tap0"umgeleitet" werden (sollten?) eth0(Standardroute).

Dies bringt mich zu der Vermutung, die ich für Ihr Problem annehmen würde: IP-Weiterleitung . Könnte es sein, dass Ihre Debian-Box es aktiviert hat, während es unter Ubuntu deaktiviert ist? Weitere Informationen (wie Sie beispielsweise herausfinden können, ob die IP-Weiterleitung aktiviert ist) finden Sie unter dem obigen Link (oder verwenden Sie Ihre bevorzugte Suchmaschine oder das Ubuntu-Handbuch).

Ihre Fähigkeit, den SSH-Daemon unter Ubuntu zu erreichen, deutet darauf hin, dass Sie sehr nah dran sind :). Daher kann es wichtig sein zu wissen, was Sie damit meinen

"Die IP-Client-IP des Debian-Servers ist öffentlich zugänglich, auf dem Ubuntu-Server jedoch nicht!"

Was versuchen Sie zu tun (dh mit welchem ​​Dienst möchten Sie eine Verbindung herstellen), wenn der Ubuntu-Computer "nicht erreichbar" ist? Auf seinen Webserver zugreifen? Welche IP hört dieser Dienst ab?

Ubuntu hat möglicherweise eine andere Standardeinstellung für die Umkehrpfadfilterung. Überprüfen Sie die verschiedenen rp_filterin /proc/sys/net/ipv4/conf/....

Wenn dies nicht hilft, besteht der nächste Schritt darin, zu bestätigen, ob Pakete mit tcpdump oder wireshark ein- oder ausgehen. Stellen Sie außerdem sicher, dass Sie wirklich keine Firewall haben iptables -vL.

Überprüfen Sie, ob rp_filering aktiv ist

sysctl -a | grep \\.rp_filter

Suchen Sie nach Schnittstellen mit = 1

Bearbeiten Sie /etc/sysctl.conf und legen Sie fest

net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0

Hier gibt es eine gute Webseite dazu http://www.tolaris.com/2009/07/13/disabling-reverse-path-filtering-in-complex-networks/