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，很少會破壞它。

設置：

更新：最初該問題被描述為發生在 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 後，據我所知，它從未被列為已載入。我懷疑它是不相關的，因為它被載入和問題出現之間沒有直接聯繫。

解決方案

解決方案是簡單地標記要由 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

它仍然以同樣的方式被破壞和“修復”。我沒有花太多時間在助手自動觸發上，所以也許我做錯了什麼。如果我發現更多，我可能會更新這個答案。我不打算使用啟用的自動助手。

引用自：https://unix.stackexchange.com/questions/461320