ルーターのVPNを有効にするとキャストが止まる理由
検出はローカルなマルチキャストで行われ、テレビ側は自らメディアを取得します。既定のポリシーがLAN宛ての要求を捕捉し、トンネルへ送ってしまうことがあります。
キャストはルーターのVPNを有効にする前は動作し、直後から失敗します。一方、スマートフォンでの通常の閲覧はそのまま動きます。この二つは矛盾しません。キャストは一つの接続ではないからです。スマートフォンはローカルネットワーク上で受信機を見つけて制御し、受信機はその後、自身の接続でメディアを取得します。
異なる形で壊れる二つの経路
制御の経路はローカルです。スマートフォンはローカルネットワークに問い合わせて受信機を見つけ、学習したアドレスへ制御接続を開きます。受信機が一覧にまったく現れない場合、メディアが要求される前に検出の段階で失敗しています。
メディアの経路は必ずしもローカルではありません。多くの受信機はストリームを自分で取得し、自分の接続と自分の資格情報を使います。したがってスマートフォンの経路は受信機の経路を表しません。一つの出口を使っているように見えるスマートフォンは、テレビの通信がどこへ行くかを何も語りません。
この分離のため、不具合は奇妙に見えます。トンネルはスマートフォンの経路表を変え、テレビの経路表は変えていません。だから組の片側に現れた症状は、その側で追う必要があります。間違った機器を追うことが、修正が何も効かないように見える通常の原因です。
検出が最初に壊れる理由
検出は通常、リンクローカルなマルチキャストで行われます。mDNSはUDPポート5353で224.0.0.251へ送り、SSDPはUDPポート1900で239.255.255.250へ送ります。どちらも設計上ひとつのリンクに限定されるため、ルーターはリピーターやプロキシの助けなしにセグメント間へ転送しません。経路化されたVPNはマルチキャストグループを拡張せず、ポリシー経路はリンクを出たことのないグループを別のリンクに出現させることはできません。
つまり最初の失敗は暗号化とは関係ありません。スマートフォンのマルチキャストは送信されたインターフェースを出て、受信機はそれを見ないセグメントにあり、機器一覧は空で戻ります。空の一覧は、テレビがインターネット接続を失った証拠ではありません。
分離はVPNがなくても同じ症状を生みます。ゲストネットワークやアクセスポイントのクライアント分離は、機器同士の通信を意図的に妨げます。分離されたセグメントの上でルーターのVPNを有効にしても、そこは変わりません。トンネルより先に分離の設定を確認してください。安く済む答えであり、より多い原因です。
セグメントの配置が残りの半分です。二台目のルーター、別モードのメッシュノード、別のNATの背後にある有線セグメントは、いずれもスマートフォンの検出通信が届かない場所に受信機を置きます。
既定のポリシーがローカルな要求を飲み込む理由
すべての通信をトンネルへ流すルーターは、トンネルのインターフェースに既定経路を入れます。LANのプレフィックスがそのポリシーから除外されていないと、二メートル先の機器宛てのパケットが既定経路に一致し、ルーターは制御要求をスイッチではなくトンネルへ送ります。
| Stage | What carries it | How a router VPN interferes |
|---|---|---|
| Discovery | Link-local multicast on a single segment | Not extended across segments, and not repaired by a route |
| Control connection | Unicast to the receiver address on the LAN | A policy default can capture the LAN destination and tunnel it |
| Media fetch | The receiver's own connection | Unaffected by the phone's route, but affected by the TV's own policy |
| Account authorization | Tokens held by the application | Can fail for reasons unrelated to any route |
結果を決めるのはルールの順序です。ポリシールーティングは優先順位の順にルールを評価するため、ローカルなプレフィックスの例外は、トンネルのテーブルを選ぶルールより前に置く必要があります。トンネルのルールの後に例外を足しても効果はありません。正しく見える設定がLANの通信を遠隔の出口へ送り続けるのはそのためです。
修正は狭く行います。キャストの流れが必要とする特定のローカル宛先だけを許可し、残りの分離はそのままにします。最初の一手としてクライアント分離を外すと症状は直りますが、ネットワークが持つよう設計された制御を捨てることになります。
スマートフォンでの簡単な確認が、二つの失敗のどちらかを決めます。受信機への経路がトンネルを指すなら、問題はポリシーです。LANを指していて検出がなお失敗するなら、問題はマルチキャストか分離であり、経路の変更では解決しません。
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcp変わった段階を試し、国を変えない
記録した観察は繰り返す実験より価値があります。受信機が機器一覧に現れるか、制御要求が届くか、ストリームを選んだ後に再生が始まるかを書き留めます。答えごとに疑いから一段階が消えます。
次に、出口の場所を変えるのではなく、各段階を直接試します。VPNの国を変えるのはメディアの経路を試すだけで、検出と制御の段階には触れません。だから偶然に効いたように見えても、何も教えてくれません。
受信機側では、それ自身の経路とアカウントの状態を確認します。スマートフォンとは別の出口でメディアを取得するテレビは正常な設計であり、そこでの失敗はスマートフォンのトンネルではなく、受信機のネットワークポリシーの問題です。
結果は、どの段階が壊れ、何がそれを変えたかという一文で書き留めます。その一文は一週間の国替えより価値があり、次のファームウェア更新を越えて残ります。
キャストはトンネルに関する一般則の良い試験例です。ネットワークにトンネルを追加するとき、最初の問いは どの宛先がそもそも入るべきでなかったか です。二つ目の問いは、そのうちどれをポリシーが黙って受け入れたかです。