VPN 上のスマートテレビ：キャストと DNS が別々に壊れる理由

テレビでは海外のカタログが表示されるのに、スマートフォンのキャストボタンには出てこない。どちらの不満も、ルーターの四つのページにある四つの設定を指す一言から始まる。出口を直せば検出が壊れ、検出を直せば次のリースで出口が別の機器に移る。以下の順序はセレクターからキャスト経路へと進む。

四つの判断がそれぞれどこにあるか

メニューを開く前に四つを書き出しておく。それぞれ別のページにあり、別の場所で壊れるからだ。セレクターはトンネルをどのクライアントに適用するかを選び、リゾルバーは名前をどこで答えるかを決め、アドレスファミリーは IPv6 をそもそも対象にするかを決め、ローカル経路はスマートフォンとテレビがまだ互いを見えるかを決める。一つを変えると、今いるページからは完了に見える。残り三つの損害は後になって、別のメニューで、別の不満として現れる。

ファームウェアのメニューは違っても、四つの場所はほとんど変わらない。セレクターは DHCP サーバー上の静的マッピングと、それに一致するファイアウォール規則だ。リゾルバーは DNS サービスとともにあり、フォワーダー項目や上流サーバーの一覧が、ルーターがどの名前を答えるか、問い合わせがどこから出るかを決める。ファミリー設定はインターフェース自体に属し、IPv4 と IPv6 は別々に構成され、ポリシーが覆えるのは最初のものだけだ。ローカル経路はアクセスポイントのスイッチで、クライアント分離か、独自のファイアウォールを持つゲストネットワークのどちらかだ。

セレクターをリースより長生きさせる

機器ごとのポリシーも専用セグメントも機能する。より良い選択は、二人目が覚えていなくてもファームウェアが維持できるものだ。罠は、DHCP サーバーが独自のスケジュールで配ったアドレスに固定した規則で、リースが動くまで機能し、その後は所有者に見えない理由でノート PC を別の国経由で通す。整頓ではなく持続性こそ、最適化する価値のある性質だ。

予約と規則を一つの変更として送る。予約より長生きする規則は、他人のハードウェアに向けた規則だからだ。セグメント全体の規則は最も長持ちし、最も粗いセレクターで、そのインターフェースの背後のすべての機器が必要の有無にかかわらず出口を継承する。どのセレクターを選んでも、次に来るのはカバレッジの問いだ。IPv4 だけのポリシーは半分の判断であり、覆われていないファミリーこそ、誰にも気づかれずに出ていく。

テレビが実際にどのリゾルバーを使うか調べる

ルーターに触る前に、テレビ自身のネットワーク設定を開く。決着をつけるのは機器だからだ。手動に設定した DNS フィールドは、DHCP が何を提供してもそのサーバーを使い続け、かつて別の地域向けに構成したセットトップボックスは、もう応答しないアドレスを指したままでいられる。フィールドが自動なら、ルーターの DHCP オプションが決め、ルーター自身のリゾルバーが次の問いになる。どちらにせよ答えは機器の画面にあり、ファームウェアの説明書にはない。

ルーター側で重要な区別は、ルーター自身が答える名前と、転送する名前の違いだ。この二つの経路は別のインターフェースから出られる。だから正しく解決する問い合わせは、メディア要求がどこへ行くかを何も語らない。Linux ゲートウェイでは、ポリシーテーブルと一回のルート参照が、テレビで何も捕まえずに両方の問いに答える：

ip rule show
ip route get 203.0.113.10

最初のコマンドはテレビの通信に印を付ける規則のために、二番目は例のアドレスへのパケットが実際に使うインターフェースのために読む。二つが食い違うとき、原因はリゾルバーではなくポリシーだ。一つだけ変えてから、もう一度この組を実行する。規則の一覧は順序に敏感で、新しい項目が通信を運んでいた規則を覆い隠すことがある。宛先は文書用に予約されているので、貼り付けた出力はサンプルとして読める。

キャストは検出で壊れ、ストリームでは壊れない

キャストは少なくとも三つの会話で、映像を運ぶのはそのうち一つだけだ。スマートフォンはローカルセグメントでマルチキャストかブロードキャストによりテレビを見つけ、何を再生するかを伝える制御チャネルを開き、その後テレビはストリームを自分で取りに行くか、スマートフォンから中継されて受け取る。検出は、その通信を転送していないルーターを決して越えない。だからテレビは意図どおりにルーティングされていても、キャスト一覧に決して現れないことがある。

ゲストネットワークとクライアント分離がよくある原因で、どちらも設定されたとおりに動いている。一台の機器をもう一度見せるためにワイヤレスネットワーク全体で分離を切るのはよくある過剰修正で、その設定が閉じるために存在したスマートフォン同士の経路をすべて開き直してしまう。もっと狭い答えはある。二つのアドレス間の検出と制御の通信に対する通過規則、テレビ用の別 SSID、ゲストネットワーク上の文書化された例外一つだ。

分離規則を置いたままキャストを試し、次に検出の例外だけを足してもう一度試す。二回目でテレビが見つかれば、例外が修正であり、セグメントの残りはそのままでよい。

トンネルを止めて、どちらへ壊れるかを見る

最後の確認はほとんどの構成が飛ばすものだ。トンネルを落として、テレビが止まるのか、ローカル接続で静かに出ていくのかを見る。優先を表すポリシーはオープンに失敗し、出口が ISP に戻る間も再生が続くので見逃しやすい。kill-switch 規則は代わりにクローズドに失敗し、トンネルが戻るまでテレビは何も報告しない。どちらの挙動も間違いではない。どちらを構成したか知らないことが間違いだ。

変更のたびに四つをこの順で再確認する。次のリースや再起動の後もセレクターが機器に一致しているか。リゾルバーがポリシーの意図する経路で答えており、機器が覚えていたサーバーからではないか。ポリシーのアドレスファミリーが、テレビとアクセスネットワークが実際に使うすべてのファミリーを覆っているか。キャストが、実際に使うスマートフォンからテレビを見つけ、同じ SSID 上の試験用スマートフォンからではないか。

その四行はチャットのスレッドではなく、ルーター設定のそばに置く。規則が何に一致するか、テレビがどのリゾルバーに問うか、どのファミリーが覆われているか、キャストにどのローカル経路が必要か。次にファイアウォールを開く人は、チケットを読むよりずっと早く設定を読む。そのころには、その人はあなたかもしれない。