OpenVPN mit nftables

[Kammermark]

Hallo,

ich habe ein eigentlich einfaches Problem, aber ich komme ums Verrecken nicht weiter...

Folgendes Szenario: ich haben ein OpenVPN 10.9.0.0/16. Die 10.9.0.0/24 sind die Admins, die 10.9.1.0/24 sind die Rechner für den Admin A, die 10.9.2.0/24 für den Admin B, und so weiter... Ursprünglich hatte ich das VPN mit "client-to-client" konfiguriert, das möchte ich aber aus verschiedenen Gründen nicht mehr. Ich möchte, dass die einzelnen Admins nur noch auf "ihre" Clients zugreifen können.

Meine OpenVPN server.conf sieht so aus:

Code: Alles auswählen

port 1194
proto udp
dev tun
user nobody
group nogroup
persist-key
persist-tun
keepalive 10 120
topology subnet
server 10.9.0.0 255.255.0.0
ifconfig-pool-persist ipp.txt
crl-verify crl.pem
ca ca.crt
cert server.crt
key server.key
tls-auth tls-auth.key 0
dh dh.pem
auth SHA256
cipher AES-128-CBC
tls-server
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
status openvpn.log
verb 4
management 127.0.0.1 5555
client-config-dir ccd
log-append /var/log/openvpn.log

Das VPN läuft schön stabil, und alle Clients können wie gewünscht rund um die Uhr ihre Messwerte bei einem Zabbix-Server, der auf dem 10.9.0.1 installiert ist, abliefern.

Für die Zugriffsberechtigungen Admin<->Client habe ich in /etc/nftables.conf folgendes angelegt (Beispielhaft die Kommunikation zwischen Admins und 10.9.1.0/24 freigeschaltet):

Code: Alles auswählen

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
	chain input {
		type filter hook input priority 0;
	}
	chain forward {
		type filter hook forward priority 0; log;
		ip saddr 10.9.1.0/24 ip daddr 10.9.0.0/24 counter packets 0 bytes 0 accept
		ip saddr 10.9.0.0/24 ip daddr 10.9.1.0/24 counter packets 0 bytes 0 accept
	}
	chain output {
		type filter hook output priority 0;
	}
}

Aktuell kann ich von 10.9.0.4 keinen von 10.9.1.x anpingen. Es sieht für mich so aus, als würden die forward rules überhaupt nicht angewandt. Das deutet auch darauf hin, dass ein "log" bei der input chain sofort das Logfile füllt (die Clients übermitteln nonstop Messwerte an den Server), wenn ich ein "log" in die forward chain mache und dann als Admin ein paar Clients anpinge, dann findet sich nichts davon im Logfile...

Hat jemand noch eine Idee, wie ich an das Problem herangehen könnte?

Viele Grüße
Konstantin

[TomL]

Die 10.9.0.0/24 sind die Admins, die 10.9.1.0/24 sind die Rechner für den Admin A, die 10.9.2.0/24 für den Admin B, und so weiter...

Das sind 3 verschiedene Netze/24 und kann imho deshalb nicht einfach so funktionieren.
10.9.0.0/24 (Admin A) ist ein anderes Netz, als die ihm zugedachten Rechner aus dem Netz 10.9.1.0/24
10.9.0.0/24 (Admin B) ist ein anderes Netz, als die ihm zugedachten Rechner aus dem Netz 10.9.2.0/24

Ich würde es vermutlich als ersten Versuch mal auf diese Weise probieren.... aber ohne Testumgebung und entsprechende Versuche habe ich keine Ahnung, ob das erfolgreich ist:

Code: Alles auswählen

chain forward {
    type filter hook forward priority 0; policy accept;
    ip saddr 10.9.0.1/32 ip daddr 10.9.0.0/24  accept
    ip saddr 10.9.0.2/32 ip daddr 10.9.1.0/24  accept
    ip saddr 10.9.0.3/32 ip daddr 10.9.2.0/24  accept
    
    drop
}

Damit sollte es evtl. möglich sein, 3 Admins mit static-IP konkrete virtuelle Subnet-Bereiche zuzuweisen.... aber wie gesagt, das muss man testen. Wie sich der Drop auf andere Funktionen auswirkt, kann ich nicht sagen, da ich das lokale Netz nicht kenne. Allerdings kann man sich das ohne drop auch ganz sparen, wenn die Chain-Policy auf 'accept' steht.... dann wäre das nur ein unnützer Bremsklotz.

[Kammermark]

Hallo Thomas,

mir war nicht klar, dass das 3 /24er Netze sind, und nicht ein /16er... Ich habe deswegen per

Code: Alles auswählen

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

das ip forwarding aktiviert, und seitdem läuft alles (soweit ich das als Nicht-Spezialist überblicke) so wie es soll.

Vielen Dank und viele Grüße
Konstantin

[TomL]

mir war nicht klar, dass das 3 /24er Netze sind, und nicht ein /16er... Ich habe deswegen per

Code: Alles auswählen

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

das ip forwarding aktiviert, und seitdem läuft alles

Doch, es sind drei /24'er Netze oder ein /16er. Offensichtlich hatte mein Posting gar nichts mit dem Problem zu tun.... weil ich das Problem vermutlich missverstanden hatte. Der Paketfilter definiert nicht das Netzwerk, die Subnetmask bei der Angabe einer IP-Adresse (/16 oder /24) ist nur ein Filterkriterium auf 16 oder 24 Bit, welches auf das IP-Paket angewandt wird. Ich hatte jedoch angenommen, dass die Netze selber auch via Subnetmask so definiert sind.... hatte aber bei meiner Antwort schon ein merkwürdiges Gefühl.

Aber ist doch prima, wenn sich das so einfach gelöst hat.

[mat6937]

... Ich habe deswegen per

Code: Alles auswählen

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

das ip forwarding aktiviert, und seitdem läuft alles (soweit ich das als Nicht-Spezialist überblicke) so wie es soll.

Diese Konfiguration ist aber nicht persistent. Evtl. die sysctl.conf (oder gleichwertig) benutzen:

Code: Alles auswählen

:~$ cat /etc/sysctl.conf | grep -i forward
# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward = 1
# Uncomment the next line to enable packet forwarding for IPv6
#net.ipv6.conf.all.forwarding = 1