nf_conntrack_sipが機能しない場合があります。 iptablesを再起動すると、通常は問題が解決します。

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を再起動した後にロードされたとは見えません。ローディングと問題発現の間に直接的な関連性がないため、関連がないと考えられます。

答え1

解決策

解決策は、conntrack sip ヘルパーが処理する発信パケットを表示することです。

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ヘルパーを使用して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

それでも同じ方法で損傷して「固定」されています。セカンダリ自動トリガに多くの時間を費やしていなかったので、何か間違っているようです。より多くの情報が見つかったら、この回答を更新できます。有効な自動サポートを使用しない予定です。

関連情報