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-
IP-Tables DNAT Problem
- mistersixt
- Beiträge: 6601
- Registriert: 24.09.2003 14:33:25
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: IP-Tables DNAT Problem
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:
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.
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
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
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
Re: IP-Tables DNAT Problem
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...)
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...)
- mistersixt
- Beiträge: 6601
- Registriert: 24.09.2003 14:33:25
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: IP-Tables DNAT Problem
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.
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
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
Re: IP-Tables DNAT Problem
...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-
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-
Re: IP-Tables DNAT Problem
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-
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-