NVR カメラが VPN 経由で消える？PoE サブネットの重複を確認

リモートサイトから NVR を開くと、LAN ページがまだ読み込まれている間にライブビューが失敗することがある。トンネルは確立し、レコーダーは応答し、応答は誰も描いていない経路を通る。レコーダーの内部カメラポートだ。PoE モデルでは、その 二つ目の接続ネットワークは、メインの LAN 設定ページに表示されるかどうかに関係なく、アドレス計画の一部である。

クライアントからレコーダーへ、そして戻る経路で障害をたどる。隠れたインターフェースが現れるのは、まさに復路である。

LAN からではなく、リモートクライアントから再現する

VPN を実際に越えるクライアントからテストする。同じ LAN 上のブラウザはレコーダーに直接到達するため、失敗する経路を決して通らない。クライアントのアドレス、レコーダーの LAN アドレス、失敗する具体的なサービスを記録する。

複数のサービスを試す。Web 管理ページ、ライブストリーム、再生リクエストは異なるポートとプロキシを使うことがあり、一方が動いて他方が失敗することがある。この比較で、障害がサービス固有かどうかがわかる。一つの失敗ポートを故障したレコーダーと誤認することも防ぐ。

リクエストがそもそもレコーダーに届くかどうかを確認する。決して届かない接続は入口側のルーティングかファイアウォールを示し、届いてから停滞するリクエストは復路かサービスを示す。レコーダーに接続ログやカウンターがあれば使う。サイト境界でのパケットキャプチャが代替手段だ。

レコーダーから出る応答を追う

二つのサイトを使った例を考える。リモートクライアントは 10.60.0.25/24、レコーダーのサイトの LAN は 10.70.0.0/24、レコーダーの LAN アドレスは 10.70.0.50、その内部 PoE ネットワークは 10.60.0.0/24 である。

Site A client:        10.60.0.25/24
Site B LAN:           10.70.0.0/24
NVR LAN address:      10.70.0.50
NVR internal PoE net: 10.60.0.0/24

サイト A のトラフィックはトンネル経由で 10.70.0.50 に到達する。次にレコーダーは自身のテーブルで戻りアドレスを調べ、10.60.0.25 をカバーする接続済みプレフィックスを見つける。そのプレフィックスはデフォルトルートより具体的なので、応答はトンネルではなくカメラポートへ向かう。

トンネルのネゴシエート状態も、サイト B のルーター上の正しい戻りルートも、このローカルな選択を覆せない。サイト B の別のサーバーへのリクエストが成功しても、この機器の 二つ目のインターフェースについては何も証明しない。

隠れた PoE ネットワークを棚卸しする

レコーダーのネットワーク設定で、内部 NIC、PoE セクション、または別個のカメラサブネットを探す。モデルによっては固有のアドレスを持つ 二つ目のインターフェースとして公開し、別のモデルはカメラ設定ページの背後に隠す。

工場出荷時のプレフィックスを仮定するのではなく、モデルとファームウェアの文書を確認する。ある製品ラインの一般的な既定値は、すべてのレコーダーについての事実ではない。コピーした番号は、実際の重複を明らかにするどころか隠してしまうことがある。

検出した範囲を、両サイトの LAN、VPN クライアントプール、レコーダー上の他の接続ネットワークと比較する。リモートクライアントプールとの重複が応答を転送するケースであり、無関係なローカル範囲との重複は VPN に触れずにローカルなカメラアクセスを壊すことがある。新しい番号を選ぶ前に、重複を 一枚のシートに描く。重複する 二つの範囲は、そこでは明白に見え、二つの別々の設定ページでは見えない。

範囲、インターフェース名、その上のカメラアドレスを記録する。この棚卸しこそ、再番号付け計画が保持すべきものだ。現地にいる間にカメラのモデルとファームウェアのバージョンも含める。

NVR だけでなく、カメラと一緒に再番号付けする

どのサイト、VPN プール、他の接続ネットワークとも重複しないカメラ範囲を選ぶ。次に、古い範囲に依存するすべてを列挙する。動的リース、静的設定のカメラアドレス、保存済みチャンネル、録画スケジュール、モデルが行う自動設定である。そのリストが移行チェックリストであり、後付けの思いつきではない。

許可された時間帯に内部ネットワークを移動し、レコーダーのバックアップと復旧アクセスを利用可能に保つ。レコーダーの内部アドレスだけを変えると、古い範囲をまだ持つカメラが取り残され、レコーダーはそれらを設定ミスではなくオフラインとして報告することがある。新しいストリームが丸一日動くまで、古い設定のエクスポートを保管する。

リモートクライアントをテストする前に、ローカルのカメラストリームと録画を確認する。カメラを失ったレコーダーの上に築いたリモート修正は修正ではない。

ストリーム、録画、リモートアクセスを確認する

リモートクライアントから、ライブビュー、再生、管理ページを個別にテストする。管理された LAN と VPN の境界でリクエストと応答を観察し、復路を、動いているページからの推測ではなく目に見える形にする。

カメラアクセスプロキシや仮想ホスト機能が設計の一部なら、そのポートマッピングと権限を、独自のレビューを持つもう 一つの明示的な経路として扱う。重複を補うためにすべてのカメラポートを開けたり、VPN セレクターを広げたりしない。

再番号付けが不可能な場合、アドレス変換の代替には、サポートされたアドレスビューと独自のポリシーレビューが必要である。一般的な教訓はレコーダーにとどまらない。機器が、リモートサイトがすでに番号を付けているカメラ、サービス、管理ネットワークを保持していることがある。

最終的な範囲とテスト済みサービスをサイト計画に記録する。次のレコーダー、カメラ増設、VPN プール変更でその番号が再利用され、一度直した重複は再び導入しやすい。