「VPNが繋がらない」その原因、実はネット回線の”構造”にある
現場でこんな経験をしたことはないだろうか。
スピードテストでは上り100Mbpsが余裕で出ている。機材も揃っている。NDI Bridgeの設定も間違いない。それなのに、離れた拠点との接続が一切確立できない。サポートに問い合わせても「ルーターの設定を確認してください」の一点張り。
原因は機材でも設定でもない。回線契約の”種類*だ。
日本の主要ISPは2020年以降、新規フレッツ光契約の標準方式を「PPPoE」から「IPoE（IPv6）」へ切り替えた。この移行は通信速度の改善に大きく貢献した一方で、従来型VPNの設計思想と根本的に相性が悪い。総務省の「令和5年度 情報通信白書」によると、国内固定ブロードバンドのIPv6対応率は2023年時点で約73%に達している。
つまり、現在のプロダクション現場の3拠点に2拠点は、すでにこの”IPoE問題”の射程圏内にいる計算だ。
従来型VPNがIPoE環境で動かない、構造的な理由
VPNには大きく分けて2つのアーキテクチャがある。「ハブ＆スポーク型」と「メッシュ型（P2P型）」だ。
長年使われてきたOpenVPN、L2TP/IPsec、PPTP——これらはすべてハブ＆スポーク型だ。中央にVPNサーバを置き、すべての端末はそこに接続して通信する。このモデルは「サーバ側がグローバルIPv4アドレスを持ち、ポートが開いている」ことが大前提だ。
IPoE環境では、この前提が成立しない。
IPoE（v6プラス/MAP-E/DS-Lite）は、複数ユーザーで1つのIPv4アドレスを共有する「CGNAT（キャリアグレードNAT）」構造を採用している。RFC 7597（MAP-E仕様）の標準実装では、1つのIPv4アドレスを16台のCEルーター（家庭用ルーター）で分割する。その結果、各拠点に割り当てられるポート数は最大4,096個（計算根拠：65,535 ÷ 16 ≒ 4,096）となる。しかし、ポートの「開放」という概念自体が存在しないため、外部から特定拠点への着信が原理的に不可能だ。
これがVPNサーバを自拠点に立てられない、そして外部からのVPN接続を受け入れられない理由だ。
メッシュVPNは、この問題をどう解決するのか
2024年現在、この問題を根本から解決する技術が実用段階に入っている。
「メッシュVPN」と呼ばれるアーキテクチャは、中央サーバへの集中を廃し、各拠点が直接つながる（P2P）設計を採用している。認証・管理のみを中央で行い、実際のデータ伝送は拠点間で直接やり取りする。この構造により、IPoE/CGNAT環境でも、ポート開放なしに拠点間を接続できる。
この記事では、NDIを使ったIP映像伝送の文脈で、このメッシュVPNを徹底的に解説する。
有料部分では以下を完全に解説する：
- メッシュVPNの内部構造（WireGuard / NAT traversalの段階的な動作メカニズム）
- 主要5サービス（Tailscale / ZeroTier / Netmaker / SoftEther / Nebula）のNDI用途別スペック比較
- IPoE環境でVPNが”詰む”具体的な技術的理由と、それを回避するロジック
- NDI BridgeとIPv4グローバルIPの関係、そしてなぜメッシュVPNが橋渡しになれるのか
- 3つの解決パターン（用途・規模・遅延要件別の選択ガイド付き）
- 現場でのリアルな判断フロー（シーン別推奨構成）
- よくある落とし穴8項目と、それぞれの回避策
- 記憶定着に最適化したメンタルモデルと記憶術
「IPoEだから仕方ない」と諦めていたIP伝送の現場を、もう一度動かすために。
コメント