マルチキャストが計画なしで VPN を越えない理由

二つの拠点がユニキャストで完全に到達できていても、片方がプリンタの検出アナウンス、IPTV のストリーム、クラスタのハートビートを見ていないかのように振る舞うことがあります。これは壊れたトンネルではなく、宛先とグループの違いです。マルチキャスト配信にはメンバーシップモデル、経路上の転送状態、トラフィックを運ぶ用意のあるインターフェースが必要で、どれもユニキャスト経路からは出てきません。アプリケーションのグループから動作する一つの受信者までたどることが、答えへの最短経路です。

グループとアプリケーションから始める

アプリケーションがどのグループアドレスを使い、そのトラフィックが何のためのものかを尋ねてください。サービスを告知する検出プロトコル、ストリーミングのフィード、ルーティングプロトコルの hello パケットは、それぞれ異なる三つの問題であり、受け入れ可能な答えも三つに分かれます。グループアドレス自体がスコープを語ります。ローカルネットワーク制御ブロックのアドレスは通常のルーティングでリンクの外へ転送される想定ではなく、それを使うアプリケーションは通常ひとつのブロードキャストドメインを前提にします。グローバルスコープのグループ上のストリーミングフィードは、すべての端末がすべてのクエリを聞くことを前提とする検出プロトコルとは別の設計であり、ブロードキャストドメインの大きさを気にするのは後者だけです。

要件がサービスなのか検出の仕組みなのかを決めてください。この二つの答えはコストが一桁違います。一方は変わらないアドレスを求め、もう一方は 広域リンクにまたがって拡張されたブロードキャストドメイン とそこから続くすべてを求めます。

リンクローカルな検出は止まるべきもの

RFC 6762 で説明されている Multicast DNS は一本のリンクを前提に設計されています。クエリは固定のグループに送られ、応答も同じグループに送られ、プロトコルはすべての参加者が全員の声を聞くことに依存します。ルータは既定でそのトラフィックを転送せず、それは見落としではなく設計判断です。境界があるのは、ある建物の端末が別の建物へ気軽に自分を告知できないようにするためです。グループをどこへでも運ぶことで検出を直したように見えるトンネルは、助けが必要だったアプリケーションだけでなく、すべてのアプリケーションからその境界を取り除いています。

リピータやリフレクタは存在し、現実の結果を伴う現実のサービスです。ある拠点で告知された名前はすべて他の拠点から見えるようになり、人や機器を特定する端末名も含まれます。本当の要件が特定のサービスを発見できることなら、DNS に公開するサービスレコードのほうが通常は小さな変更で、名前の流れではなく一つの名前だけを明かします。

ルーティングされたマルチキャストに必要な三つ

ルーティングされたマルチキャストには、グループに参加する受信者、そのための転送状態を保つルータ、グループアドレスを運ぶべきトラフィックとして扱うトンネルの三つが同時に必要です。ユニキャストのサブネットだけを列挙したポリシーのトンネルは、暗号化の境界でグループのトラフィックを落とします。だから最初の症状はエラーではなく沈黙であることが多いのです。GRE や VTI トンネルのようなルートベースのインターフェースは、ルーティングテーブルが送り込むものを運ぶので、マルチキャストの状態さえあればグループは到達可能になります。

送信元への到達性が残り半分です。PIM のようなマルチキャストルーティングプロトコルは、送信元への戻り経路が期待どおりかを確認して配信ツリーを作ります。そのためグループのメンバーシップが正しくても、別の場所を指すユニキャスト経路はツリーを壊します。受信者向けの経路を入れてもその確認には何の役にも立たず、これが通る ping と落ちるストリームを生む誤りです。まず送信元の戻り経路を確認し、次にメンバーシップを加え、そのあとで初めてアプリケーションを見てください。

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

最初の二行はホストが何に参加したかとカーネルが何を転送しているかを示し、三行目はアプリケーション自身のメンバーシップを、最後の行は逆経路チェックが使うユニキャスト経路を示します。まとめて読むことで、一度も参加しなかったアプリケーションと、一度も転送しなかったネットワークを区別できます。

一つの送信元と一つの受信者で証明する

設定に触る前に、アプリケーションが単一セグメントで動くことを確認してください。ローカルで失敗するならマルチキャストルーティングは問題ではなく、トンネルの変更でも解決しません。そのうえでトンネルをまたいだ一つの受信者で繰り返し、暗号化の境界の両側でパケットを見ます。

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

トンネルの内側で見えて外側で見えないパケットはカプセル化かポリシーを示し、両側で見えてもアプリケーションが進まないパケットは受信者のメンバーシップかアプリケーションのバインドを示します。キャプチャは短く絞ってください。混雑したセグメントでの広いマルチキャストキャプチャはほとんどが雑音です。

サービスだけが必要ならサービスアドレスを選ぶ

検出は動く何かを見つけるためにあります。安定した名前のサーバーに検出は不要で、プライベート DNS に記録したアドレスは、ブロードキャストドメインを広域リンクへ広げることなく利用者の本当の問いに答えます。同じ理屈はプリンタ、家電、社内ウェブサービスにも当てはまります。DNS の名前は必要とする拠点からは到達でき、必要としない拠点には何も告知せず、端末が別のアドレスのものに替わっても動き続けます。

プロトコルが本当にマルチキャストを必要とするなら、グループと必要な拠点に限定し、理由を記録し、アプリケーションが変わったら判断を見直してください。検出をどこまでも広げるのは一度は簡単で、それに静かに依存する端末を一年抱えたあとで戻すのは難しいのです。