LXC 컨테이너에 큰 iptables 규칙 세트를 로드하려고 할 때 이상한 문제에 직면했습니다(가상 머신에서는 제대로 작동합니다).
컨테이너는 Linux Debian 12 bookworm을 실행하고 있습니다.
규칙을 구성하고 다음을 사용하여 저장할 수 있습니다.
/usr/sbin/netfilter-persistent save
그러나 로드하려고 하면 다음 오류 메시지가 나타납니다(파일 길이는 694자입니다).
$ sudo iptables-restore < /etc/iptables/rules.v4
sendmsg() failed: Message too long
iptables-restore: line 692 failed: Message too long.
이상한 점은 장황한 모드를 추가하면 제대로 작동한다는 것입니다.
$ sudo iptables-restore -v < /etc/iptables/rules.v4 && echo ok
(...)
# Completed on Fri Sep 15 08:57:48 2023
ok
그러나 큰 파일(33750줄)을 로드하려고 하면 상세 모드 여부에 관계없이 항상 "메시지가 너무 깁니다" 오류가 발생합니다.
모든 로딩 테스트는 가상 머신(동일 OS)에서 제대로 작동합니다.
그렇다면 LXC 어딘가에 라인 제한이나 메모리 제한이 있는지 궁금합니다. 나는 가지고 놀려고 노력했지만 limits.conf아직 아무것도 바뀌지 않았습니다.
어떤 아이디어?
편집하다이 동작을 재현하기 위한 추가 정보는 다음과 같습니다.
커널 버전:
Linux xxxxxx 6.2.16-10-pve #1 SMP PREEMPT_DYNAMIC PMX 6.2.16-10 (2023-08-18T11:42Z) x86_64 GNU/Linux
일부 패키지 버전(게스트 컨테이너):
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
호스트 패키지:
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
작은 규칙 세트는 다음과 같습니다.
# 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
답변1
block_spam* 규칙에 대한 호스트/네트워크 주소를 유지하려면 ipset을 사용하는 것을 고려해야 합니다(그리고 아마도 이를 하나의 세트로 병합할 가능성이 높습니다). 이것이 더 빠릅니다. 아니면 nftables로 이동하여 내장된 세트를 사용하세요.
답변2
sendmsg() 매뉴얼 페이지를 찾아보면 메시지가 너무 크다는 것을 나타내는 응답이 실제로 없다는 것을 알 수 있습니다. 그러나 메시지 버퍼에 충분한 공간이 없으면 ENOBUFS를 반환합니다. 유사하지만 동일한 것은 아닙니다. 나는 그것이 여기서 일어나는 일이라고 생각합니다. 이는 메시지 버퍼를 비우는 것이 아무것도 없을 때 발생합니다. 즉, 소켓 통신이 어떤 방식으로 실패했을 때 발생합니다. iptables-restore가 소켓에 쓰는 이유는 무엇입니까? 로그 항목(또는 하나의 큰 항목)을 작성하려고 시도할 가능성이 높지만 이는 대부분 추측입니다. 대부분의 최신 Linux에서 'iptables-restore'는 패킷 필터링 도구의 여러 구현 중 하나를 가리키는 심볼릭 링크입니다.
작동 한다면 iptables-restore -v해결 방법이 있습니다. 그러나 방화벽 규칙이 많은 가장 가능성이 높은 이유는 개별 클라이언트 주소에 대한 규칙을 직접 추가하기 때문입니다. 주소 수가 적은 경우에는 괜찮지만 확장되지는 않습니다. @Tomek이 말했듯이 사용하는 것이 ipset훨씬 더 나은 솔루션입니다(확장 가능).