☰

nf_conntrack_sip 有时不起作用，重新启动 iptables 通常可以修复它

tag-icon • tag-icon iptables sip ip-conntrack
nf_conntrack_sip 有时不起作用，重新启动 iptables 通常可以修复它

我正在尝试在运行 Asterisk 的盒子上使用 nf_conntrack_sip，即不为另一个 VoIP 盒子路由流量。安装程序一直有效，直到我重新启动为止。重新启动后，nf_conntrack_sip 几乎总是停止工作并且媒体流量被丢弃。

conntrack --dump | grep -E 'sip|helper'
# No output matching 'sip' nor 'helper' while a call is in progress (albeit no audio)

iptables 规则已正确加载并由 确认iptables-save。

然后我就这么做了systemctl restart iptables，9/10 次就解决了这个问题。如果没有，那么我重新启动，重复 iptables 重新启动。

conntrack --dump | grep -E 'sip|helper'
conntrack v1.4.4 (conntrack-tools): 9 flow entries have been shown.
udp      17 3597 src=10.7.0.38 dst=10.47.1.11 sport=5063 dport=5060 src=10.47.1.11 dst=10.7.0.38 sport=5060 dport=5063 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 helper=sip use=2

简单地重新加载规则并iptables-restore < /etc/sysconfig/iptables没有帮助。我怀疑卸载/加载 conntrack 或某些模块可以解决问题。

有时它会在启动时工作，但非常罕见。星号启动很快。给它更多的时间“完成开始的事情”并没有帮助。

更新：在 nf_conntrack_sip 按预期工作时重新启动 iptables，很少会破坏它。

设置：

更新：最初，问题被描述为发生在虚拟机上，但从那时起，我重新安装到真实硬件（i5-6500 CPU @ 3.20GHz，带有 8Gb RAM）上，仍然出现完全相同的问题。所有与初始虚拟机相同的包（相同的配置脚本）。

操作系统是 CentOS-7.4 Minimal + 更新，内核 3.10.0-693.21.1.el7.x86_64。它全部是从 RPM 安装的，没有自定义内核或模块。更新：我还yum update对 2018 年 8 月 10 日从 CentOS 获得的最新稳定软件包和内核进行了操作。问题仍然存在。

我做了yum autoremove firewalld并且yum install iptables-services。

差异/etc/sysconfig/iptables-config（其他值按 RPM 默认）

-IPTABLES_MODULES=""
+IPTABLES_MODULES="nf_conntrack_sip"

添加的文件/etc/modprobe.d/nf_conntrack.conf：

options nf_conntrack nf_conntrack_helper=0

整个过程/etc/sysconfig/iptables非常简单：

*raw
-A PREROUTING -p udp --dport 5060 -j CT --helper sip
COMMIT

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 5060 -j ACCEPT
-A INPUT -j LOG --log-level 7 --log-prefix "REJECT in filter.INPUT:"
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

更新：设置模块选项options nf_conntrack nf_conntrack_helper=1而不使用 iptables 规则并... -j CT --helper sip不能修复它，并且行为仍然是不确定的。

与问题无关，只是为了确认数据包已被丢弃，而不是存在 NAT 问题，/etc/rsyslog.d/kern-debug.conf

kern.=debug /var/log/kernel-debug

使用 Cisco SPA504G 电话进行测试，该电话拨入 PBX 并获取保留音乐。不尝试用媒体做任何复杂的事情。 SIP 信令和媒体使用相同的 IPv4 地址进行交换。测试呼叫仅在电话和 PBX 之间进行。没有其他各方参与。

我尝试诊断它：

我制作了一个简短的脚本，尝试通过重新启动 iptables 来捕获修复前后各种事物的状态，以进行比较diff。剧本：

for f in $( find /proc/sys/net/netfilter -type f ); do
  echo f=${f}
  cat "${f}"
done

echo cat /sys/module/nf_conntrack/parameters/*
cat /sys/module/nf_conntrack/parameters/*

echo ls /sys/module/nf_conntrack/holders/
ls /sys/module/nf_conntrack/holders/

echo cat /sys/module/nf_conntrack_sip/parameters/*
cat /sys/module/nf_conntrack_sip/parameters/*
echo ls /sys/module/nf_conntrack_sip/holders/
ls /sys/module/nf_conntrack_sip/holders/

echo ls /sys/module/ip*/holders/
ls /sys/module/{ip,nf_}*/holders/

echo sysctl -a
sysctl -a

echo lsmod
lsmod

echo iptables-save
iptables-save

我唯一注意到的是，模块经常nf_conntrack_netlink被列为启动后加载，但存在问题。有时lsmod启动后它不会列出，但问题仍然存在。据我所知，重新启动 iptables 后，它从未被列为已加载。我怀疑它是无关的，因为它的加载和问题显现之间没有直接联系。

答案1

解决方案

解决方案是简单地标记要由 conntrack sip helper 处理的传出数据包：

iptables -t raw -A OUTPUT -p udp -m udp --sport 5060 -j CT --helper sip

原因

问题是防火墙规则仅标记 conntrack sip helper 的传入数据包。

iptables -t raw -A PREROUTING -p udp -m udp --dport 5060 -j CT --helper sip

当 PBX 向电话发送第一个数据包时，它将在没有 sip 帮助程序的情况下建立一个 conntrack 条目。该条目继续匹配 SIP 对话，而无需涉及 SIP 帮助程序。

[root@test ~]# conntrack -L | grep -E '5060|sip'
conntrack v1.4.4 (conntrack-tools): 13 flow entries have been shown.
udp      17 159 src=10.47.1.11 dst=10.7.0.38 sport=5060 dport=1024 src=10.7.0.38 dst=10.47.1.11 sport=1024 dport=5060 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1

当电话向 PBX 发送第一个数据包时，它将符合上面列出的“-j CT --helper sip”规则，并且将使用 sip helper 创建 conntrack 条目。

[root@test ~]# conntrack -L | grep -E '5060|sip'
conntrack v1.4.4 (conntrack-tools): 9 flow entries have been shown.
udp      17 3588 src=10.7.0.38 dst=10.47.1.11 sport=1024 dport=5060 src=10.47.1.11 dst=10.7.0.38 sport=5060 dport=1024 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 helper=sip use=2

请注意条目末尾的“helper=sip”，与第一个示例中缺少它的情况进行比较。

PBX 和电话相互发送 SIP 数据包以确认对方是否存在，因此时间安排使其显得不确定。

Asterisk 会在重新启动后保留对等点的状态，并在重新启动后探测它们，因此更有可能首先发送传出数据包并导致 conntrack 中出现非 SIP 帮助程序条目。

非常感谢用户 AB 在评论中为我指明了正确的方向。

尚存谜团

我无法解释的是为什么当我有 modprobe 选项时

options nf_conntrack nf_conntrack_helper=0

它仍然以同样的方式被破坏和“修复”。我没有花太多时间在助手自动触发上，所以也许我做错了什么。如果我发现更多信息，我可能会更新这个答案。我不打算使用启用的自动助手。

相关内容