Chromecast と DLNA の検出はルーティングされた VPN を越えない

キャストボタンには何も表示されず、VLC の DLNA は空のままで、向こう側のマシンは文句も言わずに ping に応答します。この組み合わせは帯域の問題でもファイアウォールの謎でもありません。これらのプロトコルにおける検出はローカルセグメント上のグループ交換であり、ルーティングされたトンネルはグループ宛てのトラフィックを運ばない。開始しようとしているセッションは決して提供されません。

到達性は問題ありません。検出が欠けているのです。

俗説：トンネルには設定か、より多くの帯域が必要だ

よくある提案は、ピアツーピア通信を有効にする、MTU を上げる、トンネルのデバイス種別を変える、というものです。どれもブロードキャストドメインを増やしません。マルチキャストはスイッチとローカルなネットワークスタックが配信するもので、ポイントツーポイントの TUN インターフェイスにはあふれさせるグループアドレスがありません。

設定を変えると失敗がより大きな音で鳴るだけです。プロトコルが一度も送っていない告知を、そこに出現させることはできません。

検出の交換とは実際何か

ほとんどすべての場面は三つのパターンで説明できます。mDNS は UDP 5353 で 224.0.0.251 に送り、SSDP は UDP 1900 で 239.255.255.250 に送り、古い SMB のブラウズ一覧はサブネットのブロードキャストアドレスに送られていました。いずれもホストではなくグループ宛てで、いずれも同じセグメント上のリスナーを期待します。ルーティングされたトンネルの向こう側の受信者はそのセグメントにいないので、何も届きません。

中継された告知でさえペイロードを運びます。通常は送信者の LAN アドレスとポートで、遠隔の視聴者がそこに到達できなければなりません。

トンネルを変える前にキャプチャを読む

アプリがスキャンしている間にトンネルインターフェイスでキャプチャします。空のキャプチャは、告知が境界を越えなかったことを意味し、トンネルの調整では変わりません。アプリが何も表示しないのにパケットが現れる場合は、告知されたアドレスが視聴者から到達できないことが多く、これは検出の衣装を着たルーティングの問題です。

二分のキャプチャが、ポートについての一時間の推測に代わります：tcpdump -ni tun0 udp port 5353 or udp port 1900。

三つの修正、安い順に

クライアントをサービスのアドレスに直接向けます。DLNA、SMB、素朴なメディアサーバーでは検出を完全に飛ばし、ペイロードの経路が機能することを証明します。そのため最良の最初のテストであり、実用的な回避策にもなります。Chromecast は例外で、受信側はアドレス指定されるのではなく見つけられることを期待します。

ゲートウェイでプロトコルを中継します。mDNS リフレクターはトンネルと LAN の間で告知を繰り返し、Avahi には明示的なインターフェイス一覧を受け取るリフレクターのセクションがあります。中継は狭く保ち、告知されたアドレスが両側から到達可能であることを確認してください。そうでなければ応答は依然として視聴者がルーティングできないサブネットを指します。

ルーティングではなくブリッジします。サーバーが tap デバイスを LAN にブリッジする TAP セグメントは、両端を一つのブロードキャストドメインに置くので、告知はそのまま通過します。これは最も高価な選択肢でもあります。一つのサブネットは一つの障害ドメインを意味し、LAN 上のあらゆるマルチキャストサービスがすべてのピアに届くようになります。

役に立たないもの、どれほど頻繁に勧められても

ブリッジなしでdev tunからdev tapに切り替えても、ルーティングされたままの TAP デバイスが残るので、動作は変わりません。client-to-clientはピアツーピアのユニキャストを許可し、ブロードキャストをあふれさせません。検出ポートを一つのホストに転送してもグループ宛てのトラフィックは届きません。一つのアドレスに束縛されたメディアサーバーは、自身の設定が VPN インターフェイスを記載するまでそのアドレスで応答し続けます。

直接のユニキャスト要求を一つ試し、次に告知された要求を一つ試します。最初が機能して二番目が機能しないなら、トンネルは健全で、問題は検出だけです。