IPTables Port Weiterleitung durch VPN-Tunnel

[uncharted]

Hallo zusammen,

leider komme ich an einem Problem nicht mehr weiter.

Ich würde gerne einen gewissen Port (z.b. 1234) über ein Interfaces ausgeben und empfangen (nur über dieses Interface).

Das heißt, alles was über diesen Port gesteuert wird soll über ein Interfaces weitergeleitet werden.

Server IP 91.x.x.x (Port1234) -> Weiterleitung an Interfaces tun1 (VPN IP-Bereich 10.175.228.0).

Der Server soll über das VPN an diesem Port "hören" und "senden".

Wie kann ich dies realisieren?
Ich kann das Ziel "10.175.228.1" pingen, somit klappt das routing durch den tunnel.

EDIT:im Bezug auf den tcpdump-Log

Ich frage mich, warum die Anfrage zwar von extern über den Tunnel kommt, aber die Antwort nicht in den tunnel geleitet wird.

Gruß
uncharted

Ausgabe route -n

Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 91.x.x.x 0.0.0.0 UG 0 0 0 eth0
10.9.8.0 10.9.8.2 255.255.255.0 UG 0 0 0 tun0
10.9.8.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.175.228.0 10.175.228.41 255.255.255.0 UG 0 0 0 tun1
10.175.228.41 0.0.0.0 255.255.255.255 UH 0 0 0 tun1
91.x.x.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

Aktuelle IPTables Regeln

#VPN-Freigabe für tun1
iptables -A FORWARD -i eth0 -o tun1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 10.175.228.0/24 -o eth0 -j ACCEPT
iptables -A FORWARD -j REJECT
iptables -A INPUT -s 10.175.228.0/24 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 1234 -j ACCEPT (ist aktuell aktiv, soll nachher wegfallen, wenn die Weiterleitung klappt)
iptables -A INPUT -i tun1 -p tcp --dport 1234 -j ACCEPT

Log von tcpdump

~ > tcpdump -lnvi tun1 port 1234
tcpdump: listening on tun1, link-type RAW (Raw IP), capture size 65535 bytes
12:40:32.532347 IP (tos 0x0, ttl 54, id 15963, offset 0, flags [DF], proto TCP (6), length 60)
79.x.x.x.54321 > 10.175.228.42.1234: Flags , cksum 0x75eb (correct), seq 2236606606, win 14600, options [mss 1368,sackOK,TS val 58778260 ecr 0,nop,wscale 7], length 0

~ > tcpdump -lnvi eth0 port 1234
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:40:44.727167 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
10.175.228.42.1234 > 79.x.x.x.54321: Flags [S.], cksum 0x4272 (incorrect -> 0x74c2), seq 132418478, ack 2869063960, win 14480, options [mss 1460,sackOK,TS val 14527230 ecr 58783262,nop,wscale 6], length 0

[gbotti]

Hi.

...
Aktuelle IPTables Regeln

#VPN-Freigabe für tun1
iptables -A FORWARD -i eth0 -o tun1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 10.175.228.0/24 -o eth0 -j ACCEPT
iptables -A FORWARD -j REJECT
iptables -A INPUT -s 10.175.228.0/24 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 1234 -j ACCEPT (ist aktuell aktiv, soll nachher wegfallen, wenn die Weiterleitung klappt)
iptables -A INPUT -i tun1 -p tcp --dport 1234 -j ACCEPT

...

Ohne es getestet zu haben. Die erste Forward-Regel erlaubt alles, was bereits verbunden oder bezogen ist, was über eth0 reinkommt und über tun1 rausgeht. Dann wird alles auf eth0 Freigegeben, was von 10.175.228.0/24 kommt und alles andere wird weggeworfen / abgewiesen. Was ist mit der Rückroute?

Die Dienste laufen alle auf den Geräten, die per VPN miteinander verbunden sind und der / die Dienst(e) mit Port 1234 läuft(en) direkt auf den Geräten?
Hört denn der Dienst auf allen Interfaces oder nur auf eth0?

Wenn der Dienst auf allen Ports läuft, würde es vermutlich reichen, wenn du den Input auf tun+ von Netzwerk 10.175.228.0/24 erlaubst. Auf der anderen Seite natürlich auch. Das könnte man dann noch mit "state NEW" und "ESTABLISHED,RELATED"-Rules verknüpfen, das ist aber (meiner Meinung nach) dann Unnötig, wenn eh nur die zwei Geräte miteinander reden. Ich würde dann auch nicht die IPs der Subnetze verwenden, sondern die des VPN, da man sich dann den ganzen Rattenschwanz mit dem Routing sparen könnte.

Das mit dem Forward benötigst du eigentlich nur, wenn du die beiden Netzwerke miteinander verbindest und du NAT machen willst...

[uncharted]

Hi,

danke dir für deine Antwort.

Mit der Rückroute hänge ich noch etwas, komme damit nicht so ganz klar.

Was wäre die richtige Regel? Stimmt diese?

Code: Alles auswählen

iptables -A FORWARD -d 10.175.228.0/24 -o tun1 -j ACCEPT

Der Dienst läuft auf dem Rootserver (also auf eth0).
Jedoch sollte er auch auf tun1 hören, jedoch bin ich mir nicht sicher, kann man von tun1 alles auf eth0 weiterleiten(wäre optional, würde es dann austesten)?

1.Rootserver (Dienst läuft hier und hört auf Port1234) <-> tun1 <-> 2.Rootserver der den Port 1234 an 1.Rootserver weiterleiten soll (dahinter hängen die meisten clienten)

Das Problem ist, das der 1.Rootserver auch ebenfalls auf eth0 auf den Port 1234 hören soll, damit auch die lokal angebunden auf den Dienst zugreifen können.
Sonst hätte man direkt alles was mit dem Port zu tun hat auf tun1 leiten können.

Ich hoffe du kannst mir dabei nochmal helfen

Gruß

[wanne]

Ich frage mich, warum die Anfrage zwar von extern über den Tunnel kommt, aber die Antwort nicht in den tunnel geleitet wird.

IP ist pakt-basiert. (Und das ist auch gut so. Alles andere ist grauenhaft inperformant.) Wenn man nicht irgend welche obskuren nicht standardkonforme Verbiegungen macht (NAT) hat das ausgehende Paket absolut nichts miteinander zu tun. Das ausgehende Paket wird ganz normal nach deine routing-Tabelle über eth0 geroutet.
Hier eine beschreibung die mach, was du willst:
http://archive.cert.uni-stuttgart.de/su ... 00008.html

[wanne]

Also schön für dich:

Code: Alles auswählen

echo "118 vpngw" >> /etc/iproute2/rt_table # tabelle für pakete übers vpn
ip r a 0/0 via 10.175.228.1 dev tun1 table vpngw # standardateway des VPNs setzen
ip rule add fwmark 0x76 table vpngw #Pakete, die mit 0x76 markiert sind über rutingdabelle vpngw leiten.
iptables -t mangle -I1 OUTPUT -p tcp -m tcp --sport 1234 -j MARK 0x76# Pakete die vom Programm (Port 1234) kommen mit 0x76 markieren.

[gbotti]

Wäre da nicht etwas wie das hier einfacher?

Code: Alles auswählen

 iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 1234 -j DNAT --to-destination SERVER_IP:1234

Nicht falsch verstehen! Ich finde die Idee mit dem Pakete markieren und Routing-Tabelle erstellen Super!

[wanne]

Wäre da nicht etwas wie das hier einfacher?

Nein. Das Paket get bis zum Gatewy und das weiß nicht was es damit machen soll.
Kannst du vermutlich beheben indem du auf dem VPN-Server wieder Routing aufgrund von Paketinhalten maschst. (Dismal dann Layer 5 statt layer 4 wie NAT) Da wird's dann aber irgend wann schmerzhaft. Weil du da typischeweiße ein paar mehr Nutzer hast und dich solangsam die Performanceeinbusen dann nicht mehr egal sind.

Außerdem finde ich es ganz und gar nicht einfacher. Es ist nur mal wider das gewaltsame aufdrücken von Verbindungsabsierter Denke wo eigentlich keine verbindung hingehört.

[gbotti]

Außerdem finde ich es ganz und gar nicht einfacher. Es ist nur mal wider das gewaltsame aufdrücken von Verbindungsabsierter Denke wo eigentlich keine verbindung hingehört.

Danke. Man lernt halt nie aus

[uncharted]

Danke euch beiden für die weiteren Antworten.

Es ist dann aber nicht mehr möglich, das was direkt am eth0 ankam dort auch wieder auszugeben.

Das Problem ist, das einige auf den Port (1234) übers VPN (tun1) zugreifen und andere direkt am Server sind (also an eth0).

Ist es nicht möglich das Paket mit einem "Absender z.b. die IP vom VPN-Gateway" zu markieren und dann durch den Tunnel zu schicken und der Rest geht auf eth0 raus (default gateway)


Gruß

[wanne]

Es ist dann aber nicht mehr möglich, das was direkt am eth0 ankam dort auch wieder auszugeben.

Doch eigentlich müsste das damit gehen (Aber mal lieer ohne geähr):

Code: Alles auswählen

iptables -t mangle -I1 OUTPUT -p tcp -m tcp --sport 1234 -j MARK 0x76

durch das ersetzt:

Code: Alles auswählen

iptables -t mangle -I1 OUTPUT -s 10.175.228.41 -p tcp -m tcp --sport 1234 -j MARK 0x76

[uncharted]

Danke dir

Habe es nun oben versucht...leider klappt es nicht so ganz, kann im tcpdump immer noch nur den Eingang der Pakete sehen, aber kein Ausgang über tun1.
-> Fehler gefunden, klappt einwandfrei

Folgende Änderungen habe ich vorgenommen, dann gab es keine Fehlermeldungen mehr:

Code: Alles auswählen

echo "118 vpngw" >> /etc/iproute2/rt_table # tabelle für pakete übers vpn

ein s an rt_tables gemacht

Code: Alles auswählen

iptables -t mangle -I1 OUTPUT -p tcp -m tcp --sport 1234 -j MARK 0x76# Pakete die vom Programm (Port 1234) kommen mit 0x76 markieren.

das "1" bei -I entfernt

Code: Alles auswählen

root@debian ~ > iptables -t mangle -I OUTPUT -s 10.125.100.74 -p tcp -m tcp --sport 1234 -j MARK 0x76
Bad argument `0x76'

Ich konnte auch in der Anleitung kein Unterschied erkennen, daher habe ich im Internet weiter gesucht und folgendes gefunden:

Code: Alles auswählen

root@ns26358 ~ > iptables -t mangle -I OUTPUT -s 10.125.100.74 -p tcp -m tcp --sport 1234 -j MARK --set-mark 0x76

Danach kamen immer noch nur der "Input" durch den Tunnel und nicht der "Output".
Eine Änderung von -s auf -d hatte es geändert und nun wird alles einwandfrei weitergeleitet.

Code: Alles auswählen

root@ns26358 ~ > iptables -t mangle -I OUTPUT -d 10.125.100.74 -p tcp -m tcp --sport 1234 -j MARK --set-mark 0x76

PS: Nicht wundern, die IPs haben sich bei einer Umstellung geändert.

Danke euch beiden für die Hilfe

Gruß

[wanne]

ein s an rt_tables gemacht

Oops, copy and paste Fehler... Denn hatte ich sogar ausprobiert.

Code: Alles auswählen

iptables -t mangle -I1 OUTPUT -p tcp -m tcp --sport 1234 -j MARK 0x76# Pakete die vom Programm (Port 1234) kommen mit 0x76 markieren.

das "1" bei -I entfernt

Korrekter weiße wollte ich das schreiben. Um sicher zu gehen, dass da keine anderen Regeln dazwischenfunktn.

Code: Alles auswählen

iptables -t mangle -I OUTPUT 1 -s 10.125.100.74 -p tcp -m tcp --sport 1234 -j --set-mark MARK 0x76

Aber funktioniert ja jetzt.
Ich konnte auch in der Anleitung kein Unterschied erkennen, daher habe ich im Internet weiter gesucht und folgendes gefunden:

Code: Alles auswählen

root@ns26358 ~ > iptables -t mangle -I OUTPUT -s 10.125.100.74 -p tcp -m tcp --sport 1234 -j MARK --set-mark 0x76

Eine Änderung von -s auf -d hatte es geändert und nun wird alles einwandfrei weitergeleitet.

Hinter das -s wollte ich eigentlich die IP von deinem Interface haben. Also verm. 10.175.228.42. Und nicht 10.175.228.41. Das wäre die universellere Variante.

[uncharted]

Jap, klappt seit dem einwandfrei

Danke dir nochmal

Gruß