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を再起動すると、ほとんど中断されません。

設定：

アップデート：最初は問題が仮想マシンで発生することを説明しましたが、それ以降は実際のハードウェア（8 Gb RAMを含むi5-6500 CPU @ 3.20 GHz）に再インストールしましたが、まだ同じ問題が発生します。初期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=1iptablesルールを使用せずにモジュールオプションを設定しても... -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を再起動した後にロードされたとは見えません。ローディングと問題発現の間に直接的な関連性がないため、関連がないと考えられます。