VPN でキャストが止まる：検出・制御・再生のどこで失敗したか

受信機が見えない、セッションが拒否される、再生が途中で止まる。失敗する場所はそれぞれ違います。VPN ポリシーやネットワークを変える前に、まず段階を特定しましょう。

キャストの不調は、ソファから見ると同じに見える三つの場所で起きます。スマートフォンが受信機をまったく見つけられない、受信機は見えるのにセッションを拒否する、セッションは始まるが一分後に止まる、のいずれかです。スマートフォン上のトンネルは、それぞれの経路に別々の影響を与え、そのうち一つには何も影響しません。まず失敗している段階を特定し、そのうえでポリシーの変更が本当に適切な手段なのかを判断してください。

ポリシーを変える前に失敗している段階を特定する

キャストのアイコンをタップした直後にスマートフォンが何をするかを見ます。一覧が空なら検出の結果であり、失敗を報告するタップなら制御の結果であり、止まる前に始まるセッションなら再生の結果です。この三つは担当が異なり、通常は最初の二つだけがスマートフォンのトンネル設定に関わります。

StageWhat the phone showsEvidence that separates it
DiscoveryNo receiver in the listAnother device on the same segment sees the receiver
ControlReceiver listed, session refusedPort answer versus permission prompt
PlaybackSession starts, then stallsThe receiver's own link, not the phone's

何かを変える前に段階を書き留めてください。間違った段階に施した修正は次のテストを読めなくし、キャストにまつわる俗説の多くはまさにこの混同から生まれます。

検出はローカル通信であり、トンネルはそれを隠す

受信機はローカルの告知で自分の存在を知らせ、スマートフォンは同じリンク上の問い合わせでそれを見つけます。したがって、スマートフォンをそのリンクから外すものは受信機も一覧から外します。すべての通信を LAN の外へ向けるトンネルはこのやり取りを隠すことがあり、アプリ単位のローカルネットワーク許可は経路があってもそれを遮断します。クライアント分離のあるゲスト Wi-Fi は、VPN がまったくなくても同じ空の一覧を生みます。トンネルを疑う前に、二台が同じセグメントを共有していることを確かめてください。

avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTR

一つ目のコマンドは補助マシンのセグメントで何が告知されているかを一覧にし、二つ目はマルチキャスト DNS のグループに直接問い合わせます。どちらにも現れない受信機は、スマートフォンのアプリにも現れません。トンネルの状態がどうであれ同じです。トンネルが切れている端末からは見え、入っている端末からは見えないなら、段階と原因を同時に突き止めたことになります。

LAN の例外はトンネルを維持する

多くのクライアントには、トンネルを有効のままローカルアドレスを許可するローカルネットワークの例外があります。キルスイッチやファイアウォール全体を切るのではなく、その文書化された設定を使ってください。それらはキャストに必要な以上に多くのものを変えてしまいます。ネットワークが意図的にスマート家電を分離している場合は、フラットなアクセスではなく、検出・制御・戻りの通信を具体的に管理者に求めてください。

nc -vz 192.168.1.50 8009

受信機に対する制御テストは、許可と到達性を切り分けます。応答するポートは経路が存在することを意味し、拒否は端末の検出は許されたが通信はできないことを意味します。8008 と 8009 が通常のキャスト用ポートで、アプリが別のポートを使うこともあるため、一つのポートの拒否は判断ではなく手がかりとして扱ってください。例外とアプリの許可は独立しています。ローカルアクセスを与えても経路は生まれず、経路を追加しても許可は得られません。キルスイッチは再接続後にローカル通信を落とすこともあるため、トンネルが戻ったら検出を再テストする必要があります。

再生はスマートフォンの接続を使わないことがある

アプリが指示するセッションでは、スマートフォンが受信機にメディアのアドレスを渡し、受信機が自分の接続で取得するため、スマートフォンの公開アドレスを変えてもストリームには何の効果もありません。アカウント制限のある作品はそれ自体の理由で失敗することがあり、Google の キャストの要件 はアプリと端末の互換性を扱うもので、ネットワーク経路ではありません。テレビ自体をトンネル経由にするのは別の設定で、独自のポリシー上の論点があります。

二つの手がかりがモードを分けます。スマートフォンの画面をロックしても続くキャストは、受信機が自分で取得するアプリ指示型です。送信側の画面ロックで止まるミラーリングは、スマートフォンからの連続ストリームです。検出と制御は成功するのに再生が止まる場合は、代わりに受信機の Wi-Fi リンクとインターネット経路を見てください。スマートフォンでの速度テストはテレビではなくスマートフォンを語るものです。

例外を取り消して再テストする

一時的な変更には戻り道が必要で、順序も重要です。LAN の例外を外し、クライアントがポリシーを再適用するようトンネルを再接続し、そのうえで検出手順を繰り返して、受信機が再び消えるかどうかを記録します。この順序によって、例外が効いていたのか、途中で別のものが変わったのかが分かります。

# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'

その後、三つの段階を別々に検証してください。一つ通っても他については何も分かりません。次に、無関係なスマートフォンのアプリが意図した経路に従っているかも確認します。静かに完全なバイパスになったローカル例外は、タップが一回増えるキャストより悪い結果です。

関連記事