Ich stehe vor einem seltsamen Problem, wenn ich versuche, einen großen iptables-Regelsatz in einen LXC-Container zu laden (auf einer virtuellen Maschine funktioniert das einwandfrei).
Der Container läuft unter Linux Debian 12 Bookworm.
Ich kann die Regeln konfigurieren und speichern mit:
/usr/sbin/netfilter-persistent save
Wenn ich jedoch versuche, sie zu laden, erhalte ich diese Fehlermeldung (die Datei ist 694 Zeichen lang).
$ sudo iptables-restore < /etc/iptables/rules.v4
sendmsg() failed: Message too long
iptables-restore: line 692 failed: Message too long.
Das Seltsame ist, dass es einwandfrei funktioniert, wenn ich den ausführlichen Modus hinzufüge
$ sudo iptables-restore -v < /etc/iptables/rules.v4 && echo ok
(...)
# Completed on Fri Sep 15 08:57:48 2023
ok
Wenn ich jedoch versuche, eine große Datei (33.750 Zeilen) zu laden, erhalte ich immer die Fehlermeldung „Nachricht zu lang“, unabhängig davon, ob ich mich im ausführlichen Modus befinde oder nicht.
Alle Ladetests funktionieren auf einer virtuellen Maschine (dasselbe Betriebssystem) einwandfrei.
Ich frage mich also, ob es irgendwo in LXC eine Zeilen- oder Speicherbegrenzung gibt. Ich habe versucht, damit herumzuspielen, limits.confaber es hat sich bisher nichts geändert.
Irgendeine Idee ?
BEARBEITENHier finden Sie weitere Informationen zum Reproduzieren dieses Verhaltens:
Kernelversion:
Linux xxxxxx 6.2.16-10-pve #1 SMP PREEMPT_DYNAMIC PMX 6.2.16-10 (2023-08-18T11:42Z) x86_64 GNU/Linux
Einige Paketversionen (Gastcontainer):
ii iptables 1.8.9-2 amd64 administration tools for packet filtering and NAT
ii iptables-persistent 1.0.20 all boot-time loader for netfilter rules, iptables plugin
ii libip4tc2:amd64 1.8.9-2 amd64 netfilter libip4tc library
ii libip6tc2:amd64 1.8.9-2 amd64 netfilter libip6tc library
ii libnetfilter-conntrack3:amd64 1.0.9-3 amd64 Netfilter netlink-conntrack library
ii libxtables12:amd64 1.8.9-2 amd64 netfilter xtables library
ii netfilter-persistent 1.0.20 all boot-time loader for netfilter configuration
Host-Pakete:
ii lxc-pve 5.0.2-4 amd64 Linux containers userspace tools
ii lxcfs 5.0.3-pve3 amd64 LXC userspace filesystem
ii pve-lxc-syscalld 1.3.0 amd64 PVE LXC syscall daemon
Der kleine Regelsatz lautet:
# Generated by iptables-save v1.8.9 (nf_tables) on Fri Sep 15 08:57:48 2023
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:block_spam2 - [0:0]
:block_spam1 - [0:0]
:block_spam3 - [0:0]
:incoming_net - [0:0]
:sensitive_daemons - [0:0]
-A INPUT -j block_spam1
-A INPUT -j block_spam2
-A INPUT -j block_spam3
-A INPUT -j sensitive_daemons
-A INPUT -j incoming_net
-A INPUT -j sensitive_daemons
-A block_spam2 -s 1.0.1.0/24 -j DROP
-A block_spam2 -s 84.22.192.0/19 -j DROP
-A block_spam1 -s 103.39.156.0/22 -j DROP
-A block_spam1 -s 5.255.220.0/22 -j DROP
-A block_spam3 -s 87.245.234.136/32 -j DROP
-A block_spam3 -s 217.199.224.0/19 -j DROP
[...] 675 lines here : block_spam[1-3] with a uniq ip address [...]
-A incoming_net -d 192.168.1.248/29 -p tcp -m tcp --dport 80 -j ACCEPT
-A incoming_net -d 192.168.1.248/29 -p tcp -m tcp --dport 443 -j ACCEPT
-A incoming_net -d 192.168.1.248/29 -p tcp -j DROP
-A sensitive_daemons -s 192.168.1.248/29 -p tcp -m tcp --dport 22 -j DROP
-A sensitive_daemons -s 192.168.1.0/24 -d 192.168.1.24/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A sensitive_daemons -p tcp -m tcp --dport 22 -j DROP
COMMIT
# Completed on Fri Sep 15 08:57:48 2023
Antwort1
Sie sollten erwägen, ipset zu verwenden, um Host-/Netzwerkadressen für block_spam*-Regeln beizubehalten (und sie wahrscheinlich in nur einem Satz zusammenzuführen), das wäre schneller. Oder wechseln Sie einfach zu nftables und verwenden Sie integrierte Sätze.
Antwort2
Wenn Sie die Manpage von sendmsg() nachschlagen, werden Sie sehen, dass es dort eigentlich keine Antwort gibt, die darauf hinweist, dass eine Nachricht zu groß war. Es gibt jedoch ENOBUFS zurück, wenn im Nachrichtenpuffer nicht genügend Platz ist – ähnlich, aber nicht dasselbe. Ich vermute, dass das hier passiert. Und es wird dadurch verursacht, dass der Nachrichtenpuffer nicht geleert wird – die Socket-Kommunikation ist irgendwie fehlgeschlagen. Warum schreibt iptables-restore in einen Socket? Höchstwahrscheinlich versucht es, Protokolleinträge zu schreiben (oder einen großen), aber das ist größtenteils nur eine Vermutung. In den meisten modernen Linux-Versionen ist „iptables-restore“ ein symbolischer Link, der auf eine von mehreren Implementierungen von Paketfilter-Tools verweist.
Wenn iptables-restore -vdas funktioniert, haben Sie eine Problemumgehung. Der WAHRSCHEINLICHSTE Grund für viele Firewall-Regeln ist jedoch, dass Sie Regeln für einzelne Clientadressen direkt hinzufügen. Das ist für eine kleine Anzahl von Adressen in Ordnung, aber NICHT SKALIERBAR. Wie @Tomek sagt, ipsetist die Verwendung eine viel bessere Lösung (dies ist skalierbar).