Routing/Iptables: Traffic über entfernten (OpenVPN-Tunnel) Gateway leiten ...

Mal was anspruchsvolles für die Profis? ;-)

Hallo,

ich habe hier glaube ein kleines, größeren Routing Problem und komme im Moment leider nicht so recht weiter. Kurz zur Zielsetzung. Lokal habe ich einen SMTP-Server der mit der IP von meinem Server im Internet DIREKT versenden soll. Sprich der Server soll NAT/MASQ für meinen SMTP-Server machen.

Code:

+------------------+ | SMTP-Server | | 10.0.0.11 | +------------------+ || eth1 +------------------+ tun0 (OpenVPN) +------------------+ | Router (T-DSL) |------------------| NAT-Server |------------ Internet | 10.0.0.1 |------------------| INET(81.169.x.x) |------------ mit offizieller, fester IP vom Server +------------------+ Internet +------------------+

Router:
Debian Woody
iptables v1.2.9
iptables Modul Route (http://www.iptables.org/patch-o-mati...om-extra-ROUTE)
Kernel: 2.4.25
ip_forward: 1

eth0 = DSL-Modem
eth1 = Lokales Netz (10.0.0.0/24)
tun0 = VPN-Tunnel (OpenVPN 1.5.0) zum Server (Lokaler Endpunkt: 10.100.0.1 - Entfernter Endpunkt: 10.100.0.2)
ppp0 = DSL

Routing-Tabelle (Router):

Code:

Destination Gateway Genmask Flags Metric Ref Use Iface 10.100.0.2 * 255.255.255.255 UH 0 0 0 tun0 217.5.x.x * 255.255.255.255 UH 0 0 0 ppp0 localnet * 255.255.255.0 U 0 0 0 eth1 default 217.5.x.x 0.0.0.0 UG 0 0 0 ppp0

Server:
Debian Woody
iptables v1.2.6a
Kernel: 2.4.18-bf2.4 (Debian Default)
ip_forward: 1

eth0 = 100mbit Standleitung
tun0 = VPN-Tunnel (OpenVPN 1.5.0) (Lokaler Endpunkt: 10.100.0.2 - Entfernter Endpunkt: 10.100.0.1)

Routing-Tabelle (Server):

Code:

Destination Gateway Genmask Flags Metric Ref Use Iface 10.100.0.1 * 255.255.255.255 UH 0 0 0 tun0 10.0.0.0 10.100.0.1 255.255.255.0 UG 0 0 0 tun0 default 81.169.xx 0.0.0.0 UG 0 0 0 eth0

Zur Konfiguration:
Der SMTP-Server hat den Router (10.0.0.1) als Gateway. Auf meinem Router wird mittels IPT_ROUTE der SMTP-Traffic auf den externen Gateway umgeleitet. Der Rest geht normal über T-DSL raus. Der entfernte Server macht normales NAT mittels iptables (iptables -A FORWARD -i tun0 -s 10.0.0.11 -j ACCEPT \ iptables -t nat -A POSTROUTING -s 10.0.0.11 -o eth0 -j MASQUERADE) für den SMTP-Server ...

Umleitung SMTP-Traffic auf Router

Code:

iptables -A POSTROUTING -t mangle -s 10.0.0.11 -p tcp --dport 25 -j ROUTE --oif tun0 --gw 10.100.0.2

Wenn ich nun von meinem SMTP-Server eine Verbindung mittels telnet aufbaue: telnet Zielserver 25 kommt meine Verbindung dort erfolgreich an und das MASQ hat auch wunderbar funktioniert.

tcpdump auf dem Zielserver:

Code:

01:23:01.498319 meinNATServer.1558 > Zielserver.25: S 4153295297:4153295297(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) 01:23:04.497049 meinNATServer.1558 > Zielserver.25: S 4153295297:4153295297(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) 01:23:10.411798 meinNATServer.1558 > Zielserver.25: S 4153295297:4153295297(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)

Bis hierhin funktioniert also alles wunderbar. Die Verbindung von meinem lokalen SMTP-Server wird auf dem Router anhand des Zielports auf meinen Gateway im Internet über das VPN "umgebogen". Dieser macht NAT für meine lokale IP (10.0.0.11) und die Verbindung geht DIREKT mit der offiziellen IP (81.169.x.x) zum Ziel.

Nun versucht der Server "Zielserver" auf die Verbindung von "meinNATServer" zu antworten. Diese Antwort kommt auch erfolgreich wieder auf tun0 (VPN) auf meinem Router (10.0.0.1) an und möchte die Pakete wieder an meinen internen SMTP-Server zustellen:

tcpdump auf Router tun0:

Code:

01:27:05.254156 Zielserver.25 > 10.0.0.11.1567: S 1973897288:1973897288(0) ack 4214399589 win 5840 <mss 1460,nop,nop,sackOK> (DF) 01:27:08.231350 Zielserver.25 > 10.0.0.11.1567: S 1973897288:1973897288(0) ack 4214399589 win 5840 <mss 1460,nop,nop,sackOK> (DF) 01:27:09.310802 Zielserver.25 > 10.0.0.11.1567: S 1973897288:1973897288(0) ack 4214399589 win 5840 <mss 1460,nop,nop,sackOK> (DF)

Eigentlich sollte man nun denken, funktioniert doch alles und alles ist super. Doch leider fehlt der letzte Schritt.

Meine Antwort-Verbindung kommt nun auf tun0 an und müsste nur noch auf eth1 an meinen SMTP-Server (10.0.0.11) weitergeleitet werden (ip_forward: 1). Doch aus mir unerklärlichen Gründen, hört hiermit auf tun0 die Verbindung auf und das Datenpaket landet im Nirvana. Auf eth1 kommt die Verbindung nicht mehr an und kann somit meinen SMTP-Server leider nicht mehr erreichen. Ich möchte noch erwähnen, dass der SMTP-Server problemlos aus dem VPN von dem Server im Internet zu erreichen ist. Also das kann meiner Meinung nach somit nicht das Problem sein.

Da der ganze externe NAT-Kram scheinbar wunderbar funktioniert und ich derzeit nicht mehr weiterkomme, warum mein Paket nicht von tun0 auf eth1 zum Ziel möchte, wäre ich dankbar wenn mir hier einer ein paar Denkanstöße geben könnte.

Die Iptables-Firewall habe ich auch schon komplett durchgeloggt. Das kann es nicht sein. Vorallem da ja eine Verbindung (aufgebaut vom Server im Internet über VPN) zum SMTP-Server funktioniert.

Habe ich vielleicht zuviele Hops dazwischen?!?! NAT wird ja nur einmal gemacht. Kann es also nicht sein?!?!

In der Hoffnung, dass mir einer helfen kann ;-)
MeTRiX

Hoffe es ist ausführlich genug.

Interessante Zusammenstellung hast du da ;)

Was passiert wenn du auf deinem Router die Zeile
iptables -A POSTROUTING -t mangle -s 10.0.0.11 -p tcp --dport 25 -j ROUTE --oif tun0 --gw 10.100.0.2
weglässt und stattdessen eine normale Hostroute für den Zielserver über tun0/NAT-Gateway einfügst?
Ist zwar nicht der Sinn der Sache aber ich habe die Vermutung dass es bei tun0 auf dem Router nicht hinhaut die zurückkommenden Pakete einzusortieren.

Ein anderer einfacher Test wäre auch diese Route wegzulassen und stattdessen mal die default-Route über den NAT-Gateway laufen zu lassen.

Edit: Auf der Seite
http://www.iptables.org/patch-o-mati...om-extra-ROUTE
steht was von "--continue", ich bin mir da jetzt nicht ganz sicher was das heisst aber probiers doch einfach mal aus :)

Nochmal Edit: Ich hab hier sogar eine ähnliche Konstellation mit Rechnern und OpenVPN, würd ich auch mal ausprobieren falls du es nicht herausfindest was es ist.

Grüsse, Stefan

Zitat:

Zitat von geronet

Was passiert wenn du auf deinem Router die Zeile
iptables -A POSTROUTING -t mangle -s 10.0.0.11 -p tcp --dport 25 -j ROUTE --oif tun0 --gw 10.100.0.2
weglässt und stattdessen eine normale Hostroute für den Zielserver über tun0/NAT-Gateway einfügst?
Ist zwar nicht der Sinn der Sache aber ich habe die Vermutung dass es bei tun0 auf dem Router nicht hinhaut die zurückkommenden Pakete einzusortieren.

das ist doch mal ein super tipp - aber auf so einfache dinge kommt man manchmal nicht mehr nach so vielen stunden testen ;-)

Code:

route add -host Zielserver gw 10.100.0.2 Destination Gateway Genmask Flags Metric Ref Use Iface Zielserver 10.100.0.2 255.255.255.255 UGH 0 0 0 tun0 10.100.0.2 * 255.255.255.255 UH 0 0 0 tun0 217.5.x.x * 255.255.255.255 UH 0 0 0 ppp0 localnet * 255.255.255.0 U 0 0 0 eth1 default 217.5.x.x 0.0.0.0 UG 0 0 0 ppp0

und siehe da nun funktioniert es problemlos wenn ich auf die eine ip connecte. scheinbar hat er also probleme, wenn ich nur den einen port über den anderen gateway schicke ?!?! muss ich vllt noch was anderes über den gw schicken außer dem tcp port 25?

Zitat:

Zitat von geronet

steht was von "--continue", ich bin mir da jetzt nicht ganz sicher was das heisst aber probiers doch einfach mal aus

wenn ich das aktiviere, leitet er komischerweise nicht mehr über den gateway. habe den sinn davon noch nicht so ganz kapiert ;-)

Zitat:

Zitat von geronet

Nochmal Edit: Ich hab hier sogar eine ähnliche Konstellation mit Rechnern und OpenVPN, würd ich auch mal ausprobieren falls du es nicht herausfindest was es ist.

die wäre? ;-)

Hmm noch ein einfacher Tipp: Füg doch mal bei allen iptables-chains (auch bei PRE-, POSTROUTING und OUTPUT in allen tables) ein --log ein und schau mal ob das Rücksende-Paket überhaupt irgendwo auftaucht, wenn nicht lässt es der OpenVPN nicht heraus.

ich frage mich nur, warum es bei einer festen route funktioniert und nich bei einer route die portbasiert ist ...

Ich füge mal noch an:

Code:

Routenverfolgung zu Zielserver [x.x.x.x] über maximal 30 Abschnitte: 1 <1 ms 1 ms 1 ms router.home.lan [10.0.0.1] 2 197 ms 96 ms 87 ms 10.100.0.2 3 * * * Zeitüberschreitung der Anforderung.

kommt also bis zum "umgeleiteten" (mittels ipt_route) gateway und ab da ist ende. sprich der gateway antwortet noch korrekt.