STUN/TURN トラフィックの iptable マッチングルール

STUN/TURN トラフィックの iptable マッチングルール

443 ポートで受信される TURN/STUN パケットを探しています。TURN RFC によると、バイト 46 から 49 は TURN パケット マジック クッキー「2112a442」です。こここれはWiresharkのスクリーンショットで、STUNクッキーが46から49であることがわかった。

使用しています-m u32 --u32 "46=0x2112A442" が、フィルタリングできません。

これが私の完全なiptableルールです

-A PREROUTING -i eth0 -p tcp --dport 443 -m u32 --u32 "46=0x2112A442" -j REDIRECT --to-port 3478

何が間違っているのか、何か考えはありますか?

答え1

iptables u32 モジュール オフセットは、イーサネット ラッパーを除いたパケット (送信元および宛先 MAC がそれぞれ 6 バイト、イーサ タイプが 2 バイト) を参照します。したがって、Wireshark オフセット 46 は 14 で調整する必要があり、32 になります。

さて、健全性チェックのために、サービスバイトのタイプを見つけます。これは、u32領域からわかります。iptables-extensions のマニュアルページオフセット 9 にあり、UDP の場合は 0x11 (17) であることもわかっています。Wireshark のスクリーンショットではバイト 0x17 (23) にあります。そこから数えると、使用すべきオフセットは 32 になります。

編集 1: プロトコルは UDP なので、iptables コマンドのその部分も調整する必要があります。つまり、

sudo iptables -A PREROUTING -i eth0 -p udp --dport 443 -m u32 --u32 "32=0x2112A442" -j REDIRECT --to-port 3478

編集 2: 例の Wireshark のスクリーンショットでは、宛先ポートは 443 ではなく 5004 です。そのため、iptables コマンドは、特定のパケットの例では機能しません。おそらく次のようになります。

sudo iptables -A PREROUTING -i eth0 -p udp --dport 5004 -m u32 --u32 "32=0x2112A442" -j REDIRECT --to-port 3478

関連情報