iptables für snat rules (für openvpn) gehen auf centos8 auf einmal nimmer

Antitrack

Bekanntes Mitglied
Liebe Firewall-Experten!

Ich brauche eure Hilfe. Leider habe ich einen alten CentOS7-vserver auf CentOS 8 reinstalled, aber jetzt gehen meine Firewall-Rules nicht mehr.
Die Firewall-rules waren als script in der /etc/rc.d/rc.local (jaja ich weiss...) und dienen dazu, den OpenVPN-Traffic ans Netz durchzuleiten, falls der Win-Client nicht nur andere OpenVPN-Rechner erreichen will, sondern eben auch das Internet.
Das tut er jetzt nimmer, er erreicht nur die 10.9.0.x-VPN-Rechner, leider.

Also: Meine iptables gehen auf centos 8 nicht und liefern bei Überprüfung andere Ergebnisse als auf ubuntu 18.04.

Jetzt zum aktuellen Beispiel: Ich habe 2 Vserver: ein guter, bei dem das iptable script geht, ein schlechter, bei dem es nicht geht.

der gute vserver: Ubuntu 18.04 LTS (GNU/Linux 4.15.0-22-generic x86_64)
seine hypothetische (hier: abgeänderte, nicht die echte!) ipv4: 123.45.67.88, net card nach aussen ist eth0. Hetzner-Server. Ebendort :

--------

cat /etc/rc.local

#!/bin/sh -e

iptables -F
iptables -X
iptables -Z
iptables -t nat -F
iptables -t nat -X
iptables -t nat -Z

modprobe tun
echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -A FORWARD -i eth0 -o tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 10.9.0.0/24 -o eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j SNAT --to-source 123.45.67.88

exit 0

--------------------------------------------------------

Überprüfung der guten iptables:

# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- 10.9.0.0/24 anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Openvpn wird tadellos durchgereicht und jeder win-client,der sich mit dem Server verbindet, kommt auch ins internet, nicht nur ins 10.9.0.x netz. (client 2 client enabled!)

---------------------------------------------------------------------------------------------------------

Nun zum schlechten Server:

centos 8 : kernel 4.18.0 #1 SMP Tue Aug 25 11:59:26 MSK 2020 x86_64 x86_64 x86_64 GNU/Linux

network interface "venet0" : ip = 123.4.56.57 on venet0:0 : (nicht die echte IPv4, keine Sorge!)

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Lokale Schleife)
RX packets 176628 bytes 52813070 (50.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 176628 bytes 52813070 (50.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1400
inet 10.9.0.1 netmask 255.255.255.0 destination 10.9.0.1
inet6 fe80::f547:c6ff:e939:77be prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 504 bytes 39681 (38.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 9 bytes 504 (504.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

venet0: flags=211<UP,BROADCAST,POINTOPOINT,RUNNING,NOARP> mtu 1500
inet 127.0.0.1 netmask 255.255.255.255 broadcast 0.0.0.0 destination 127.0.0.1
inet6 xxxx:xxxx:xxxx:xxxx::1 prefixlen 128 scopeid 0x0<global>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 0 (UNSPEC)
RX packets 847452 bytes 1977019606 (1.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 678603 bytes 99147730 (94.5 MiB)
TX errors 0 dropped 5400 overruns 0 carrier 0 collisions 0

venet0:0: flags=211<UP,BROADCAST,POINTOPOINT,RUNNING,NOARP> mtu 1500
inet 123.4.56.57 netmask 255.255.255.255 broadcast 123.4.56.57 destination 123.4.56.57
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 0 (UNSPEC)

venet0:1: flags=211<UP,BROADCAST,POINTOPOINT,RUNNING,NOARP> mtu 1500
inet 10.4.56.57 netmask 255.0.0.0 broadcast 10.255.255.255 destination 10.4.56.57
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 0 (UNSPEC)


Der schlechte Server hat gleiche rc.local ausgenommen mit "venet0" statt "eth0" und iptables commands:

----------
touch /var/lock/subsys/local

iptables -F
iptables -X
iptables -Z
iptables -t nat -F
iptables -t nat -X
iptables -t nat -Z
# modprobe tun
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -i venet0 -o tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 10.9.0.0/24 -o venet0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o venet0 -j SNAT --to-source 123.4.56.57
---------


Diese rc.local führt zu:

# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
SNAT all -- 10.9.0.0/24 anywhere to:123.4.56.57
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- 10.9.0.0/24 anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
SNAT all -- 10.9.0.0/24 anywhere to:123.4.56.57
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- 10.9.0.0/24 anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
SNAT all -- 10.9.0.0/24 anywhere to:123.4.56.57
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- 10.9.0.0/24 anywhere
# Warning: iptables-legacy tables present, use iptables-legacy to see them


Frage(n): Wieso kriege ich die warnung "legacy tables present" ? Wie sehe ich diese Tables ? Wo ist das Programm "iptables-legacy"? Bei mir ist es nicht vorhanden und dnf search findet es auch nicht!
Wieso kriege ich andere rules als gewohnt?
Was soll ich machen damit das endlich richtig weitergeleitet wird?

Bitte um Hilfe. Danke !!
 

ibinsfei

Team (Technik) - BOFH
Mitarbeiter
VPN auf einem Container ist immer Glückssache, weil du auf die kernel-Module des Host angewiesen bist. Am besten immer KVM statt Container verwenden.
 
Oben Unten