OpenVPN 上の SSM：1 つのソースとグループを最初から最後まで追う

一つのストリームと一人の受信者を選び、マルチキャストをカテゴリとして試すのではなく、そのペアをすべてのホップで追跡します。ソース固有の設計が失敗するのは、受信者が参加していない、ルーターが逆方向パスでパケットを拒否した、カーネルに状態がない、トンネルがコピーを配信しなかった、という四つのうちの一つです。この順序で作業すると、ホップあたり数分のコストで、四つのうち実際にどれが起きているかが分かります。

まずソース、グループ、受信者を確定する

どの機器に触れる前にも、送信するソースアドレス、受信者が参加するグループアドレス、受信者が存在するサブネットという三つの値を書き留めます。説明用の IPv4 ストリームなら、ソース 10.50.0.10 とグループ 232.20.30.40 がソース固有の設計に合う組み合わせの例です。この三つの値より曖昧なものはテストできません。

232/8 の範囲はソース固有マルチキャスト用に予約されており、そのモデルは RFC 4607 で説明されています。SSM を運用しているつもりなのにグループがその範囲外にある場合は、受信者の参加とルーターの転送判断がどちらもモデルの一貫性に依存するため、いったん止めて配備の実際の意図を確認してください。

受信者がソースに参加していることを確認する

グループだけのメンバーシップレポートは、ソース固有の参加ではありません。受信者にどのソースを要求したかを問い合わせ、最初のホップのルーターでグループの状態を見てソースリストが現れるか確認します。レポートがソースを持たない場合、ルーターは任意ソースの参加として扱い、設計全体は計画していなかったものへ静かに劣化します。

Linux の受信者では、ソケットが実際に何を購読したか、カーネルが何を記録したかを確認します。アプリケーションの設定ファイルは証拠になりませんが、メンバーシップテーブルが証拠です。受信者が実際に動作している間に読み取ってください。エントリは、それを作成したプロセスが終了した後も少しの間残ることがあり、以前のテストの古いエントリは誤った自信を生む確実な原因になります。

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

期待したソースを伴う参加が存在するなら、ルーターへ進みます。存在しないなら、転送するものが何もないため、トンネルの設定をどう変えても役に立ちません。

トンネルを見る前に逆方向パスを確認する

マルチキャストルーティングは逆方向パスチェックを行い、ユニキャストルートが指すインターフェース以外で到着したパケットは破棄されます。これが、明らかに送信されているストリームが次のホップに決して届かない最も一般的な理由であり、アプリケーションレベルでは有用なエラーがまったく出ません。

ソース側を向いたルーターでは、ソースへのルートと、パケットが実際に到着するインターフェースを比較します。受信者側を向いたルーターでは、受信者自身のサブネットについて同じことを行い、出力インターフェースリストにそこへのリンクが含まれていることを確認します。どちらかの方向で不一致があれば、それは RPF の失敗であり、メンバーシップの失敗ではありません。

次に、ソースの TTL が、設計したルーティングホップを通過するのに十分大きいことを確認します。最初のルーターでは動作し二台目で止まるストリームは、多くの場合ポリシーではなく TTL の問題です。

設定ではなくカーネルのマルチキャスト状態を読む

設定は何を要求したかを示し、カーネルは何が起きているかを示します。各 Linux ホップでマルチキャストルーティングのエントリを読み、ソースとグループの正確なペアについて入力と出力のインターフェースリストが存在することを確認します。ワイルドカードソースを持つグループのエントリは別のオブジェクトであり、ソース固有のフローを説明しません。

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

ルーティングデーモンはその状態の上に独自の見解を持ち、それを表示するコマンドはどの実装が入っているかによって変わります。原則は一定で、デーモンにそのペアの上流エントリを尋ね、次にカーネルに転送エントリが存在するかを尋ねます。カーネルにエントリがないのに転送していると思っているデーモンは、そのホストの設定範囲の問題です。

両者が食い違うときは、VPN ではなくホストを直します。尋ねたフローを転送していないホップを、下流の何かで補うことはできません。ストリームが動作している間に、各ホップのペア、入力インターフェース、出力リストを記録します。その記録が、次の障害を新たな調査ではなく比較に変えます。

トンネルが実際にどう複製するかを決める

ここで VPN 上のマルチキャストは定型作業ではなくなります。ポイントツーポイントのトンネルはパケットを対向側の一つのピアに届けるため、コピーはちょうど一つのクライアントに届きます。ブリッジされたセグメントは共有リンクのように振る舞います——なぜならトンネルがフレームを運び、ブリッジが何をフラッディングするかを決めるからです。これらは異なる配信モデルであり、二つ目を前提にしながら一つ目を動かしている設計は、一人の受信者には動くように見えて次の受信者では失敗します。

マルチポイントサーバー経由で複数の受信者を扱う場合、複製は明示的に設計する必要があります。ゲートウェイにマルチキャストルートをインストールしても、VPN サーバーにどのピアがコピーを受け取るべきかは伝わらず、クライアント側のルートがその判断を代行することもありません。多数の受信者が必要な場合は、サポートされた複製か意図的に選んだ代替手段を使い、どちらを選んだかを書き留めてください。

最後に、受信者側で狭い観察を行い、正確なソース、グループ、ポートを、想定したインターフェース上で、許可された一つの受信者が参加している間に確認します。SSM は送信者を選択しますが、その選択は送信者の認証ではなく、他のマルチキャストトラフィックが同じポリシーを通過する許可でもありません。