IP-Tables DNAT Problem

Gemeinsam ins Internet mit Firewall und Proxy.
Antworten
joadoor
Beiträge: 11
Registriert: 30.11.2015 13:24:51

IP-Tables DNAT Problem

Beitrag von joadoor » 30.11.2015 13:46:18

Hallo hier im Forum,

jetzt muss ich mich mal an die Öffentlichkeit wenden, ich komme nichtmehr weiter.

Problem:
Ich will, wenn ein Client auf meinen Ubuntu-Server mit einem bestimmten Port zugreift, dieses Paket in meinen VPN-Tunnel schicken.
Das hat schon funktioniert, nach dem neu-Aufsetzen bekomme ich das aber irgendwie nichtmehr hin.

Deutlicher:
Client:
2.172.6.54

Server:
IP-Interface [IN]: 2.172.36.200 (em4)
IP-Interface [OUT]: 192.168.1.2 (tun0)

Jetzt soll, wenn der Client auf die 2.172.36.200 mit dport 6666 zugreift, dieses Paket nach 192.168.1.1 geroutet werden (Andere Seite des Tunnels).
Aber das klappt nicht.
Mittlwerweile habe ich -der einfachheit halber- alles was von der SRC_IP kommt, weitergeroutet.

Hier die IPTables-Syntax:
iptables -t nat -A PREROUTING -s 2.172.6.54/32 -j DNAT --to 192.168.1.1

Der Rest von IPTables ist mom. alles auf ACCEPT.

die Rule greift:
iptables -t nat -nL -v
Chain PREROUTING (policy ACCEPT 156 packets, 22922 bytes)
pkts bytes target prot opt in out source destination
15 780 DNAT all -- * * 2.172.6.54 0.0.0.0/0 to:192.168.1.1

wenn ich mit einem Ping mit der entsprechenden Source rüberpinge, funktioniert das aber:
root@ha-rr8-oe30084desktop:~/TEMP# ping -I 2.172.36.200 192.168.1.2
PING 192.168.1.2 (192.168.1.2) from 2.172.36.200 : 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.040 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.029 ms

routing ist aktiviert:
root@ha-rr8-oe30084desktop:~/TEMP# cat /proc/sys/net/ipv4/ip_forward
1

Auch für jedes Interface:
root@ha-rr8-oe30084desktop:~/TEMP# cat /proc/sys/net/ipv4/conf/em4/forwarding
1
root@ha-rr8-oe30084desktop:~/TEMP# cat /proc/sys/net/ipv4/conf/tun0/forwarding
1


Hat jemand eine Idee?
Wäre wirklich für jeden Tipp dankbar.
Vor allem, weil das schonmal irgendwie funktoiniert hat.

-joadoor-

Benutzeravatar
mistersixt
Beiträge: 6601
Registriert: 24.09.2003 14:33:25
Lizenz eigener Beiträge: GNU Free Documentation License

Re: IP-Tables DNAT Problem

Beitrag von mistersixt » 30.11.2015 13:58:48

Ich glaube, das sollte direkt mit iptables gehen, ohne Aktivierung vom Routing, auch wenn ich jetzt noch nicht vollständig Dein Setup durchschaut habe, sollte vermutlich sowas gehen:

Code: Alles auswählen

iptables -t nat -A PREROUTING  -i em4 -s 2.172.6.54/32 --dport 6666 -j DNAT --to 192.168.1.1:6666
iptables -t nat -A POSTROUTING -o tun0                 --dport 6666 -j SNAT --to 192.168.1.2
Hier wird das Paket also 2 x umgesetzt, einmal per DNAT soll das Paket von 192.168.1.1:6666 weitergeleitet werden, und zweitens wird das ausgehende Paket dann so umgesetzt, dass 192.168.1.1 denkt, es käme von 192.168.1.2.

Gruss, mistersixt.
--
System: Debian Bookworm, 6.5.x.-x-amd64, ext4, AMD Ryzen 7 3700X, 8 x 4.0 Ghz., Radeon RX 5700 XT, 16 GB Ram, XFCE

joadoor
Beiträge: 11
Registriert: 30.11.2015 13:24:51

Re: IP-Tables DNAT Problem

Beitrag von joadoor » 30.11.2015 14:23:32

Danke für die schnelle Antowrt.
Richtig, so SOLLTE es gehen ;-)
die unterste Zeile habe ich mit Masquerading gelöst.

Mein Problem ist aber, daß überhaupt kein Paket in das interface tun0 REINgeht...
(tcpdump -n -i tun0...)

Benutzeravatar
mistersixt
Beiträge: 6601
Registriert: 24.09.2003 14:33:25
Lizenz eigener Beiträge: GNU Free Documentation License

Re: IP-Tables DNAT Problem

Beitrag von mistersixt » 30.11.2015 15:28:50

Uff, "aus der Ferne" ist es nicht ganz einfach, dem Übeltäter auf die Spur zu kommen. Aber poste doch mal parallel die Routing-Tabelle vom Rechner mit der IP 2.172.36.200. Andere iptables-Einträge sind wirklich nicht vorhanden? "iptables -L -n" und "iptables -t nat -L -n" zeigen nur Deine Regeln an?

Gruss, mistersixt.
--
System: Debian Bookworm, 6.5.x.-x-amd64, ext4, AMD Ryzen 7 3700X, 8 x 4.0 Ghz., Radeon RX 5700 XT, 16 GB Ram, XFCE

joadoor
Beiträge: 11
Registriert: 30.11.2015 13:24:51

Re: IP-Tables DNAT Problem

Beitrag von joadoor » 01.12.2015 08:05:10

...wie gewünscht :-)

root@ha-rr8-oe30084desktop:~/TEMP# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 em3
2.172.36.0 0.0.0.0 255.255.255.0 U 0 0 0 em4
10.10.10.1 192.168.1.1 255.255.255.255 UGH 0 0 0 tun0
10.10.10.100 192.168.1.1 255.255.255.255 UGH 0 0 0 tun0
172.20.0.0 2.172.36.1 255.255.0.0 UG 0 0 0 em4
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 em3
192.168.0.1 192.168.1.1 255.255.255.255 UGH 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0

root@ha-rr8-oe30084desktop:~/TEMP# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

root@ha-rr8-oe30084desktop:~/TEMP# iptables -t nat -nL -v
Chain PREROUTING (policy ACCEPT 3 packets, 386 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp -- em4 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:6666 to:192.168.1.1:6666
Chain INPUT (policy ACCEPT 3 packets, 386 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * tun0 0.0.0.0/0 0.0.0.0/0




Ich denke ich muss rausfinden, warum die Kiste das Paket nicht zur 192.168.1.1 schickt.
Fehlt da noch ein Modul oder sowas?
Denn das Routing passt ja, weil der Extended Ping funktioniert.
Und die Rule greift grundsätzlich, weil der Packet und Byte Counter hochzählt.
Nur warum er dann das Paket nicht über den Tunnel schickt zur 192.168.1.1:6666 wie angegeben ist mir ein Rätsel...

-joadoor-

joadoor
Beiträge: 11
Registriert: 30.11.2015 13:24:51

Re: IP-Tables DNAT Problem

Beitrag von joadoor » 01.12.2015 08:29:01

OK.
Dämlich.
Jetzt geht's...
Hatte die Rückroute für das Netz 2.172.x.x vergessen.
Aber warum er dann das HIN-Paket garnicht erst in den Tunnel schickt versteh ich immer noch nicht...

-joadoor-

Antworten