カメラストリームの公開：RTSP と HLS は同じエッジではない

カメラのポートをひとつ開き、プレーヤーをそこに向けて、インターネットの問題は解決したと考える。ところがスマートフォンでは再生できず、ブラウザーでも再生できず、カメラの管理ページは公開エッジからタイプミスひとつ分の経路にすぎない。選んだ配信モデル、RTSP か HLS かが、ファイアウォール規則をひとつ書く前にその大半を決めてしまう。VPN が提供するのはプライベート側の区間だけだ。

VPN が直すのは供給元の経路であり、視聴者の経路ではない

トンネル経由でカメラの LAN に接続した VPS は、カメラのプライベートアドレスに到達できるのは確かに役に立つ。カメラ側に受信ポートが不要になり、家庭のルーターは閉じたままでいられるという意味だ。ただし、視聴者がどのプロトコルを話すかは教えてくれない。デスクトップのプレーヤー、ブラウザー、スマートフォン、スマートテレビはそれぞれ異なるプロトコルに対応しており、TLS、認証、コーデックについての期待もそれぞれ違う。

捨てる価値のある前提はこれだ、公開とは供給元に到達可能にすることだという前提。公開とは実際には、定義された視聴者にメディアを消費するためのサポートされた手段を渡すことだ。公開されたストリームには形式と視聴者と資格情報がある、到達可能なカメラにはそのどれもない。到達可能性はトンネルが解決する部分であり、視聴者の入口はあなたがまだ設計しなければならない部分だ。

RTSP は交渉であり、単一のポートではない

RTSP はセッション制御を運び、クライアントは記述を要求し、ひとつ以上のメディアトラックを設定し、それから再生する。メディアそのものの転送はその設定の中で交渉されるので、転送した TCP ポートひとつではプロトコルをうまく説明できない。その交渉こそ、人がファイアウォール規則を比べるときに見落とす部分だ。

端点によっては、RTP は別々の UDP ポートに届くことも、制御接続にインターリーブされることもある。554 だけを転送し、残りは動くだろうと仮定するリレーは、たいてい接続し、トラックを報告し、そのあと何も表示しないセッションを生む。規則を書く前に、あなたのカメラが実際に交渉する転送方式を確認すること。プライベート側でのキャプチャーはそれを一分で答えるが、推測は一晩を費やす。

互換性のあるプレーヤーを持つ小規模で既知の視聴者なら、意図的に構成した RTSP リレーが正解になりうる。どの供給元から引けるかを制限し、リレーで認証を要求する。テストしたプレーヤーを書き留めておくこと、VLC で動く RTSP ストリームでもブラウザーでは失敗することがあるからだ。

HLS はプレイリストとリソースの組み合わせだ

HLS の視聴者はプレイリストを取得し、次にそのプレイリストが名指しするメディアセグメントを取得する。HLS 仕様がこのリソースモデルを定義しており、運用上の重要な点は、プレイリストが他の URL を参照することだ。相対参照はプレイリストの位置を基準に解決されるので、パスを書き換えるプロキシーは一貫して書き換える必要がある。

カメラがすでに使える HLS を配信しているなら、公開フロントエンドはそれらのプレイリストとセグメントの要求をトンネル越しに転送できる。アプリケーションが生成する鍵、リダイレクト、URL に注意する。プライベートなホストを指す絶対 URL は、LAN の外の視聴者がそれをたどった瞬間に壊れる。プロキシーの書き換えを生き延びるのは相対パスなので、生成される出力を制御できる場所では相対パスを優先する。

カメラが RTSP しか話さないなら、何かが供給元を視聴者の形式に変換しなければならない。再パッケージとトランスコードは別の仕事だ、再パッケージはコーデックを保ち、トランスコードは互換性のために再エンコードし、後者だけが本格的に CPU を食う。経路に VPN があるというだけでは、どちらも必要にはならない。

配信が起きる場所を軸に上り回線を計画する。公開メディアサービスを支える単一のプライベート取り込みは、各視聴者が自分のストリームをトンネル越しに引くのとはまったく違う振る舞いをする。後者のパターンはたいてい、飽和した家庭回線と、ランダムに故障しているように見えるカメラで終わる。

認証はあなたが公開するエッジに置く

TLS、視聴者の認証、アクセス記録は公開の入口に属し、カメラには属さない。これによりカメラの資格情報をストリームの資格情報から切り離せる。視聴者が去ったときにアクセスを取り消す場所もひとつにまとまる。代わりにカメラ側へそれらの制御を置くと、視聴者の変更のたびに、そもそも公開で到達可能であるべきでない機器への管理変更が必要になる。

VPN とカメラの管理権限を公開経路から分離する。ストリームを引くためにカメラの Web インターフェースへ到達できる VPS は、そのインターフェースを晒すマシンでもあるべきではない。視聴者がカメラのアドレスを知ることは決してないようにする。

次に、チェーンが動くと仮定するのではなく、実際に構築した両端を検証する：

$ ffprobe -v error -rtsp_transport tcp rtsp://10.50.0.9:554/stream1
$ curl -sI https://stream.example.net/live/index.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl

プライベートな供給元のプローブが成功し、公開エッジでのプレイリスト取得が成功したことは、設計の別々の半分を証明する。それらを分けてテストする。視聴者と同じ種類のクライアントから再生することが、チェーン全体を覆う唯一のテストだ。

最終的に手に入るのは、各リンクに目的を持つチェーンだ、プライベートな供給元、制限された取り込み、選ばれたパッケージ、認可された視聴者の入口。どのリンクも任意ではなく、どのリンクもポートを開けることで生まれるものではない。