主页 / unix / 问题 / 461320
Accepted
AnyDev
Asked: 2018-08-09 08:34:23 +0800 CST

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

  • 772

我正在尝试在运行 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，很少会破坏它。

设置：

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

操作系统是 CentOS-7.4 Minimal + 更新，内核 3.10.0-693.21.1.el7.x86_64。它都是从 RPM 安装的，没有自定义内核或模块。更新：我还在yum update2018 年 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

使用拨入 PBX 并获取保留音乐的 Cisco SPA504G 电话进行测试。不要试图用媒体做任何复杂的事情。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 后，据我所知，它从未被列为已加载。我怀疑它是不相关的，因为它被加载和问题出现之间没有直接联系。

iptables sip

1 个回答

  1. Best Answer

    解决方案

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

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

    原因

    问题是防火墙规则只标记 conntrack sip 助手的传入数据包。

    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-helper 条目。

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

    剩下的谜团

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

    options nf_conntrack nf_conntrack_helper=0

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

    • 3

相关问题