web-dev-qa-db-ja.com

マルチキャストトラフィックは、netfilter接続追跡システムに穴を開けることができます

私は自宅にIPTVソリューションを持っており、ISPは毎秒数百の大きなUDPデータグラムを10.4.4.5ポート10から239.3.5.3ポート10に送信します。つまり、マルチキャストを使用しています。入力トラフィックの現在のiptables構成は非常に単純です。

~# iptables -L INPUT -v -n --line-numbers
Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1       19   845 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
2     1146  275K ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED /* established/related connections */
#

iptables-save形式のルール：

# iptables-save -c
# Generated by iptables-save v1.6.0 on Sun Aug 26 12:51:11 2018
*nat
:PREROUTING ACCEPT [44137:4586148]
:INPUT ACCEPT [6290:1120016]
:OUTPUT ACCEPT [419:75595]
:POSTROUTING ACCEPT [98:8415]
[26464:2006874] -A POSTROUTING -o eth0 -m comment --comment SNAT -j MASQUERADE
COMMIT
# Completed on Sun Aug 26 12:51:11 2018
# Generated by iptables-save v1.6.0 on Sun Aug 26 12:51:11 2018
*filter
:INPUT DROP [72447:97366152]
:FORWARD ACCEPT [77426:101131642]
:OUTPUT ACCEPT [148:17652]
[17:787] -A INPUT -i lo -j ACCEPT
[333:78556] -A INPUT -i eth0 -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "established/related connections" -j ACCEPT
COMMIT
# Completed on Sun Aug 26 12:51:11 2018
#

上に表示されているeth0は、ISP向けのNICです。奇妙な部分は、このマルチキャストトラフィックがカウンターに従ってドロップされる一方で（チェーンのデフォルトポリシーカウンターは数MB /秒増加します）、実際にはmplayerで受信することです。これは、マルチキャストトラフィックがnetfilter接続追跡システムに穴を開けているように見えるためです。これはconntrack -Lで確認できます。例：

# conntrack -L | grep --color 239.3.
udp      17 29 src=10.4.4.5 dst=239.3.5.3 sport=10 dport=10 [UNREPLIED] src=239.3.5.3 dst=10.4.4.5 sport=10 dport=10 mark=0 use=1
conntrack v1.4.4 (conntrack-tools): 130 flow entries have been shown.
#

conntrack -Fを実行しても、上記のエントリが再び表示され、mplayerにビデオストリームが表示されます。ただし、最終的に（約5分後）このエントリは消え、すぐにストリームが停止します。

参考までに、このLinuxベースのルーターには9つの物理インターフェイスがあります。

# ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
eth2             DOWN           00:a0:c9:77:96:bd <NO-CARRIER,BROADCAST,MULTICAST,UP> 
eth1             UP             00:14:bf:5f:de:71 <BROADCAST,MULTICAST,UP,LOWER_UP> 
eth0             UNKNOWN        00:50:8d:d1:4f:ee <BROADCAST,MULTICAST,UP,LOWER_UP> 
eth3             DOWN           00:a0:c9:4b:21:a0 <NO-CARRIER,BROADCAST,MULTICAST,UP> 
eth4             UP             00:20:e2:1e:2e:64 <BROADCAST,MULTICAST,UP,LOWER_UP> 
eth5             DOWN           00:20:fc:1e:2e:65 <NO-CARRIER,BROADCAST,MULTICAST,UP> 
eth6             DOWN           00:20:fc:1e:2e:8e <NO-CARRIER,BROADCAST,MULTICAST,UP> 
eth7             UP             00:20:fc:1e:2f:67 <BROADCAST,MULTICAST,UP,LOWER_UP> 
wlan0            UP             00:21:91:e3:20:20 <BROADCAST,MULTICAST,UP,LOWER_UP> 
br0              UP             00:14:bf:5e:da:71 <BROADCAST,MULTICAST,UP,LOWER_UP> 
# ip -br address
lo               UNKNOWN        127.0.0.1/8 
eth2             DOWN           
eth1             UP             
eth0             UNKNOWN        192.0.2.79/24
eth3             DOWN           
eth4             UP             
eth5             DOWN           
eth6             DOWN           
eth7             UP             
wlan0            UP             
br0              UP             192.168.0.1/24
#

私が言ったように、eth0はISPに接続されています。 eth1からeth7に加えてwlan0は、br0という名前のブリッジの一部です。ルーティングテーブルは次のようになります。

# ip -4 r
default via 192.0.2.1 dev eth0 
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.79 
192.168.0.0/24 dev br0 proto kernel scope link src 192.168.0.1 
#

すべてのインターフェイスのさまざまなネットワークパラメータをここで確認できます。

# ip -4 netconf 
ipv4 dev lo forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev eth2 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev eth1 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev eth0 forwarding on rp_filter off mc_forwarding on proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev eth3 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev eth4 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev eth5 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev eth6 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev eth7 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev wlan0 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev br0 forwarding on rp_filter off mc_forwarding on proxy_neigh off ignore_routes_with_linkdown off 
ipv4 all forwarding on rp_filter off mc_forwarding on proxy_neigh off ignore_routes_with_linkdown off 
ipv4 default forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
#

これは予想される動作ですか？私の最初の考えは、conntrackモジュールがIGMP「メンバーシップレポート」メッセージを検査できるため、239.3.5.3へのトラフィックを許可することでしたが、これはconntrack -Fの後でもトラフィックがどのように許可されるかを説明していません。

iptablesnetfiltermulticast
2
Martin

pimd を使用して同様の設定を試みた後、私は次のように結論付けることしかできません。

  • 通常の（データ）マルチキャストパケットは転送されるため、このフローでマルチキャストルーティングが有効になっている限り、filter/FORWARDの対象となります。 conntrackエントリudp 17 29 src=10.4.4.5 dst=239.3.5.3 sport=10 dport=10 [UNREPLIED] src=239.3.5.3 dst=10.4.4.5 sport=10 dport=10 mark=0 use=1はそのような転送されたフローであり、nat/PREROUTINGおよびnat/POSTROUTINGカウンタを（のみ）1つインクリメントします：このcontrackエントリをトリガーした新しいパケット。
  • リンクローカルマルチキャストパケット（224.0.0。{1,22}へのIGMPパケットおよび224.0.0.13へのPIMv2）は、filter/INPUTによって停止されます。
  • 以前にフローが有効になっていた場合、マルチキャストルーターはこの特定のマルチキャスト宛先の転送をしばらくの間アクティブにします。設定されたタイムアウトが発生し、LANまたはPIMv2からWAN）からIGMPレポートを受信しなかった場合、ファイアウォールのためにリッスンしているクライアントがないか、有効なフローがないと見なされ、対応するマルチキャストフローの転送を停止します。

最後に、Linuxルーターが以下を受信できるようにする必要があります。

  • LANからのIGMPパケット。ルーターは、どのマルチキャストクライアントがリッスンしているかを認識し続けることができます。

    iptables -A INPUT -i br0 -p igmp -j ACCEPT

  • 私の特定のセットアップはpimdとPIMv2を使用しています。このプロトコルが常に使用されるかどうかはわかりませんが、PIMプロトコルが機能するようにする必要がありましたが、ソースIPが192.0.2.1だけではなく（10.4.4.5）の場合、DROPポリシーを維持します。

    iptables -A INPUT -s 192.0.2.1 -i eth0 -p pim -j ACCEPT

  • ISPルーターからのIGMPパケットを許可する必要があるかもしれませんが、私の特定のセットアップではそれらは必要ありませんでした。

    iptables -A INPUT -s 192.0.2.1 -i eth0 -p igmp -j ACCEPT

更新：

filter/INPUTチェーンのDROPポリシーは引き続きヒットを表示することに注意してください。マルチキャストされているLinuxルーター自体のIGMPおよびPIMv2パケットは、外部に送信されるとローカルシステムにループバックされるため、（無害に）ドロップされます。上記のルール。対応するルールを追加した後、PIMv2で奇妙な動作が発生し、最終的にはfilter/OUTPUTでパケットをマークして、filter/INPUTでのループバックコピーを許可する必要がありました。その間、私はNATルールも制限しました。最終的に、次のルールにより、filter/INPUTのDROPポリシーカウンターは、マルチキャストトラフィックを転送している間、常に[0：0]のままでした。

# Generated by iptables-save v1.6.2 on Mon Aug 27 01:01:48 2018
*nat
:PREROUTING ACCEPT [1:56]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [1:56]
[0:0] -A POSTROUTING -s 192.168.0.0/24 -o eth0 -m comment --comment SNAT -j MASQUERADE
COMMIT
# Completed on Mon Aug 27 01:01:48 2018
# Generated by iptables-save v1.6.2 on Mon Aug 27 01:01:48 2018
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [1533311:325676232]
:OUTPUT ACCEPT [75:3724]
[0:0] -A INPUT -i lo -j ACCEPT
[1:56] -A INPUT -i eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[40:1800] -A INPUT -i br0 -p igmp -j ACCEPT
[14:774] -A INPUT -s 192.0.2.1/32 -i eth0 -p pim -j ACCEPT
[28:1288] -A INPUT -s 192.0.2.1/32 -i eth0 -p igmp -j ACCEPT
[17:932] -A INPUT -s 192.0.2.79/32 -i eth0 -p igmp -j ACCEPT
[28:1392] -A INPUT -m mark --mark 0x1 -j ACCEPT
[28:1392] -A OUTPUT -p pim -j MARK --set-xmark 0x1/0xffffffff
COMMIT
# Completed on Mon Aug 27 01:01:48 2018

socat （複数のインターフェイスの場合はローカルIPを指定）を使用して、マルチキャストクライアントをシミュレートし、stdoutにダンプできます。

socat -u UDP4-RECV:10,ip-add-membership=239.3.5.3:0.0.0.0 -
2
A.B