「本社と支店をVPNでつなぎたい」「工場のNVRを本社から見たい」——見積もりを取り始めた段階で、こんな話が出てくることがあります。
「回線をIPoEに変えたので、拠点間VPNは張れません」
「片側だけなら張れます」
「固定IPを追加してください」
言っていることが事業者ごとに違うように見えるのですが、実は同じ1つの前提を指しています。それは、拠点間VPNは「どちらか一方が待ち受ける」構成が必要で、待ち受ける側には外から届くIPv4アドレスが要る、というものです。IPv4 over IPv6（IPoE）で一般的なアドレス共有型のサービスは、この「待ち受け」を構造として想定していません。
この記事でわかることは次の3点です。
- IPv4 over IPv6環境で拠点間VPNがつまずく、回線側の3つの論点（着信・NAT越え・MTU）
- 実現できる4つのパターンと、それぞれに必要な前提
- つながらない／不安定なときの切り分け手順と、契約前に確認しておく項目
なお、光回線を用いたインターネット接続はベストエフォート型のサービスです。通信の速度・品質は回線の混雑状況、時間帯、宅内環境などによって変動し、特定の速度や、特定のVPN構成が問題なく動作することを保証するものではありません。この記事も、特定の構成によって通信が速くなること・安定することを保証するものではありません。
最初に決めるのは「どちら側が接続を開始するか」
技術の話に入る前に、設計上いちばん効く1点を先に置きます。
VPNは、接続を開始する側（イニシエータ）と、それを待ち受ける側（レスポンダ）に分かれます。家庭用の言い方をすれば「電話をかける側」と「電話を受ける側」です。
- 電話をかける側は、相手の番号さえ分かっていればよい
- 電話を受ける側は、相手から見て変わらない番号を持っていないといけない
拠点間VPNで「固定IPが必要」と言われるのは、ほぼこの受ける側の話です。逆に言えば、受ける側が1か所で足りるなら、固定IPも1か所で足りることがあります。ここを決めずに「両拠点とも固定IPで」と見積もると、必要のない条件を抱えることになります。
まず紙に、拠点を四角で描いて、矢印をどちら向きに引くかを決めてください。この矢印の向きが、以降の要件をほぼ決めます。
用語メモ：ONU＝光回線の終端装置。HGW（ホームゲートウェイ）＝ひかり電話などに使われる、ONUとルーター機能が一体になった装置。網終端装置＝PPPoE方式でプロバイダ網の出入口に置かれる装置で、宅内ではなく事業者側にあります。
なぜIPv4 over IPv6環境でつまずくのか — 回線側の3つの論点
前提として、言葉を分けておきます。IPv6は通信のプロトコル（住所の規格）、IPoEは接続方式（PPPoEのようなトンネルを使わずにルーティングする繋ぎ方）で、この2つは別の概念です。日本ネットワークインフォメーションセンター（JPNIC）の解説でも、IPoEは接続方式として説明されています（出典1）。そしてIPv4 over IPv6は、IPoEで繋いだIPv6の上にIPv4の通信を乗せるための実現方式で、DS-Lite・MAP-E・IPIP などの種類があります。
拠点間VPNに効いてくるのは、3つ目の「乗せ方」です。
① 着信できるIPv4アドレスがない（アドレス共有型）
IPoE向けの一般的なIPv4接続は、アドレス共有型として設計されています。たとえば transix（インターネットマルチフィード株式会社が提供するIPoE接続サービス）の「IPv4 over IPv6接続 DS-Lite」は、公式の説明で「1つのグローバルIPv4アドレスをシェアするアドレス共有型のサービス」と明記されています（出典2）。DS-Lite の仕様である RFC 6333 も、事業者側の装置で複数の加入者が1つのIPv4アドレスを共有する前提で設計されています（出典3）。
この構造では、外から来た通信を「どの契約者宛てか」判別する手段がありません。IETF の RFC 6269「Issues with IP Address Sharing」は、アドレス共有によって生じる論点を体系的に整理しており、着信について 「アドレス共有の仕組みが入ると、一般論として、よく知られたポート番号への着信接続は機能しなくなる」旨を述べています（出典4・§5.2）。同文書は逆引きDNSの制限（§15）にも触れています。
拠点間VPNに置き換えると、こうなります。
- 共有型の拠点は、レスポンダ（待ち受け側）になれない
- 両方の拠点が共有型だと、どちらからも張れない
- 片側が共有型でも、その側がイニシエータ（発信側）に回れば成立し得る
3つ目が実務上の逃げ道になります。詳しくは後述のパターンBです。
② NAT越え（UDP 4500）は「発信側」の仕組みであって、着信を作るものではない
IPsecには、NATを挟んだ環境で通すための標準的な仕組みがあります。ESPをそのまま流すとNATを越えられないため、UDPポート4500にカプセル化して運ぶ方式が RFC 3948 で標準化されており（出典5）、IKEv2 を定めた RFC 7296 も §2.23 でNATの検出と4500番への切り替えを規定しています（出典6）。
ここで誤解が起きやすいのですが、この仕組みは「NATの内側から外へ出ていく通信」を成立させるためのものです。事業者側で複数契約のアドレスをまとめている構成では、外側から入ってくる接続を特定の契約者に振り分ける手段がないため、NAT越えの仕組みがあっても着信側にはなれません。「NAT-T対応の機器だから大丈夫」とは言い切れない、ということです。
あわせて、共有型では1契約あたりに使えるTCP/UDPポート数に上限があります。多数のセッションを同時に張る業務があると、混雑時間帯だけ接続に失敗する、という別の症状として現れることがあります。この切り分けはDS-Lite環境でポートが足りなくなるときの原因と切り分けにまとめています。
③ トンネルが二重になり、MTUの問題が出やすい
IPv4 over IPv6は、名前のとおりIPv4のパケットをIPv6で包みます（transix の固定IPは、この包み方に RFC 2473 に準拠した IPIP 方式を用いると公式に記載されています／出典7）。そこへVPNのカプセル化が重なると、包みが二重になり、1パケットで運べる実際のデータ量（実効MTU）が小さくなります。
RFC 4459「MTU and Fragmentation Issues with In-the-Network Tunneling」は、まさにこの論点——経路上の最小MTUに収まるようにどう送信サイズを決めるか——を扱った文書です（出典8）。
現場で出る症状には特徴があります。
- pingは通る。Webも見える。しかし大きなファイルの転送やDBの同期だけが止まる
- 特定のアプリケーションだけ、途中で固まる
- 「つながっているのに使えない」ので、回線障害として報告されにくい
これは回線の故障ではなくサイズの設計の問題で、多くはルーター側のMTU／MSSの調整で扱います。「疎通はするが特定の通信だけ落ちる」ときは、まずここを疑ってください。
4つの実現パターンと、それぞれの前提
「どちら側が待ち受けるか」と「回線がアドレス共有型か」の組み合わせで、選べる形が決まります。
| パターン | 構成の概要 | 回線側に必要な条件 | 向いている場面 | 注意点 |
|---|---|---|---|---|
| A. 両側に固定IP | どちらの拠点からも接続を開始できる | 両拠点にグローバル固定IPv4アドレス | 双方向で常時つないでおきたい／障害時にどちらからでも復旧したい | 両拠点の機器が、方式（IPIPなど）とVPNの両方に対応している必要がある |
| B. 片側だけ固定IP | 固定IP側が待ち受け、もう一方から発信 | 待ち受け側のみ固定IPv4アドレス | 本社＋小規模拠点・在宅・店舗。多くの中小規模はこれで足りる | 再接続も常に発信側から。共有型側はポート数の上限の影響を受けることがある |
| C. IPv6でVPNを張る | IPv4 over IPv6を経由せず、IPv6同士でトンネルを張る | 両拠点にIPv6の到達性 | 両側の機器を新規に揃えられる場合 | 社内の業務システムやSaaSがIPv4前提だと、結局IPv4側の手当てが要る |
| D. クラウド側で終端 | 各拠点から外向きに接続し、クラウド上のサービスで束ねる | 着信不要（各拠点はアウトバウンドのみ） | 拠点数が多い／全拠点に固定IPを揃えにくい | 月額サービス費用と運用が別途必要。回線はベストエフォートである点は変わらない |
A〜Dのどれが正解ということはありません。 拠点数、双方向で開始する必要があるか、既存機器を使い続けるか、運用を誰が見るかで変わります。ただし、BとDは「固定IPを全拠点に用意する」より条件が軽いため、見積もりが重く感じたときの検討先になります。
なお、固定IPそのものの仕組み（IPoE環境でどう実現されるか、機器要件は何か）は、別記事で扱っています。
固定IPと動的IPの基本的な違いから確認したい場合は、固定IPと動的IPの違いとは？を先にご覧ください。
つながらない・不安定なときの切り分け手順
順番に進めてください。上から順に、回線側の条件 → サイズ → 相手側の並びにしています。
- 矢印を描く：どちらの拠点が接続を開始する設計になっているかを確認します。設計と実際の設定が逆になっていることは珍しくありません。
- 待ち受け側のIPv4の見え方を確認する：待ち受け側の拠点で、ルーターのWAN側に表示されているIPv4アドレスと、外部のIPアドレス確認サービスに表示されるアドレスが一致するかを見ます。一致しない場合、事業者側でアドレス変換・共有が入っている可能性があります。
- 契約中の方式を書面で確認する：PPPoEか、IPoEか。IPv4はDS-Liteか、MAP-Eか、固定IP（IPIP）か。マイページや契約書面、開通通知に記載があります。事業者のサービス名と技術方式名は別物なので、「サービス名」ではなく「方式名」で回答をもらってください。
- サイズを疑う：疎通するのに特定の通信だけ落ちる場合は、分割禁止を指定したpingでサイズを変えながら試すと切り分けられます（Windowsなら
ping -f -l 1400 <宛先>のようにサイズを指定し、通る最大値を探す）。閾値が見つかれば、MTU／MSSの調整で改善する見込みが立ちます。 - 相手側の条件を確認する：接続先が取引先やSaaSの場合、接続元IPアドレスの届け出が必要なことがあります。届け出たアドレスと実際に出ていくアドレスがずれていないかを確認します。
- 両側のログを時刻を揃えて突き合わせる：片側だけのログでは、フェーズ1（鍵交換）で止まっているのか、フェーズ2以降で落ちているのかが判別できません。両拠点のNTPが合っているかも先に確認してください。
この6手順の結果を持って相談すると、事業者側の一次回答が「回線を見直しましょう」から先に進みます。
契約・設計前の確認チェックリスト
そのまま社内資料や、事業者への質問票に転記できる形にしました。
| # | 確認項目 | 確認先 |
|---|---|---|
| 1 | 接続を開始する向き（どの拠点がイニシエータか） | 社内 |
| 2 | 待ち受け側になる拠点はどこか（1か所で足りるか） | 社内 |
| 3 | 各拠点の現在の接続方式（PPPoE／IPoE）とIPv4の実現方式 | 各ISP |
| 4 | 待ち受け側のIPv4アドレスが共有か固定か | 各ISP |
| 5 | 必要なグローバルIPv4アドレスの個数 | 社内 |
| 6 | 各拠点のルーターの型番・ファームウェア版 | 社内 |
| 7 | その機器が、契約する方式（IPIP等）に対応しているか | 事業者／メーカー |
| 8 | その機器が、使いたいVPN方式に対応しているか（同時に何本張れるか） | 事業者／メーカー |
| 9 | ひかり電話・HGWの有無と、想定される接続構成 | 社内／事業者 |
| 10 | MTU／MSSの設定を誰が行うか | 社内／事業者 |
| 11 | IPアドレスが変更される可能性と、その条件 | 事業者（約款・重要事項説明） |
| 12 | 切替当日に業務が止まる見込み時間と、切り戻しの手順 | 事業者 |
| 13 | VPN機器のファームウェア更新を誰が・どの頻度で行うか | 社内／保守事業者 |
| 14 | 初期費用・最低利用期間・解約時の費用の有無 | 事業者（約款・重要事項説明） |
13番と14番は回線の話ではありませんが、あとから効いてきます。 13番の理由は次章、14番は条件の比較で最も差が出るところだからです。月額だけでなく、初期費用・最低利用期間・解約時の費用まで揃えて比べてください。
VPN機器そのものが侵入口になっている — 回線と機器は別の問題
拠点間VPNを検討するときに、回線側の条件と同じくらい先に決めておきたいのが、VPN機器を誰が保守するかです。
警察庁サイバー警察局が2026年3月に公表した「令和7年におけるサイバー空間をめぐる脅威の情勢等について」は、ランサムウェア被害組織へのアンケート結果として、侵入経路はVPN機器が6割以上を占める状況にあると記載しています。あわせて、未修正のぜい弱性、漏えいした認証情報や簡易なパスワード、設定不備などが悪用されていると指摘されています（出典9）。総務省の「テレワークセキュリティガイドライン（第5版）」も、外部から接続を受ける構成において、機器の脆弱性対策と認証情報の管理を継続的に行うことの必要性を扱っています（出典10）。
ここから読み取れる実務上の含意は、次の2点です。
- VPNを「張れるようにすること」と「安全に運用し続けること」は別の作業である。着信を受ける構成は、作った瞬間から更新の対象になる
- したがって、固定IPを用意しただけでセキュリティが確保されるわけではない。むしろ外部から到達できる入口を1つ作ることになるため、機器のファームウェア更新、不要アカウントの棚卸し、認証の強化とセットで設計する必要がある
見積もりの段階で「回線は事業者、機器は別会社、更新は誰も見ていない」という分担になっていないか、確認しておいてください。
GIGANEXTという選択肢
GIGANEXTは、有限会社ゼストが運営する法人向けのインターネット接続サービスです。インターネットマルチフィード株式会社が提供するIPoE接続サービス「transix」を基盤としています。
サービスは、transix の IPv4固定IP（IPIP方式・IPoE）を含む構成で提供しています。この記事の言葉でいえば、パターンAまたはBの「待ち受け側」に必要な回線側の条件を、最初から満たした状態で用意するという形です。transix の公式ページでも、この固定IPメニューの用途としてインターネットVPNや監視カメラ、IoT機器へのアクセスが挙げられています（出典7）。
この記事の範囲で、当社が担う部分とそうでない部分を分けて書いておきます。
| 項目 | 扱い |
|---|---|
| 回線側の条件（固定IPを含む接続構成の提供） | GIGANEXTの提供範囲 |
| 契約前の確認（現在の方式、機器の対応可否、必要IP数の整理） | ご相談を承ります |
| 切替の段取りと、うまくいかなかった場合の戻し方の事前確認 | ご相談を承ります |
| 接続用ルーターの設定に関するサポート | ご相談を承ります（構成により対応範囲が異なります） |
| VPN機器そのものの選定・VPN設計の請負・セキュリティ運用の継続保守 | 本サービスの範囲外です。別途のご相談・他社との組み合わせが必要になる場合があります |
ゼストは、福岡を拠点に集合住宅のインターネット環境を約3,000戸規模で運用し、あわせて法人向けネットワークの導入・保守、防犯カメラ・遠隔監視の連携を手がけてきました。その中で繰り返し見てきたのは、回線そのものより「どちら側が待ち受けるか」が決まっていないこと、そして手元の機器が方式に対応していないことでつまずく場面です。だからこそ、契約前の確認事項を先に片付ける形にしています。
なお、光回線を用いたインターネット接続はベストエフォート型のサービスであり、通信速度・品質は回線の混雑状況、時間帯、お客様の宅内環境などにより変動します。特定の速度や、特定のVPN構成・業務システムが問題なく動作することを保証するものではありません。ご検討にあたっては、料金・初期費用・最低利用期間・解約時の費用を含む契約条件を、個別にご案内します。
「そもそも固定IPが要る構成なのか」「片側だけで足りるのか」といった段階からのご相談も承っています。お問い合わせはこちら。
まとめ
- 拠点間VPNは待ち受け側（レスポンダ）に、外から届くIPv4アドレスが要る。最初に決めるのは矢印の向き
- IPoE向けの一般的なIPv4接続はアドレス共有型で、着信を構造として想定していない（出典2・3）。RFC 6269 も、アドレス共有下では既知ポートへの着信が一般に機能しないと整理している（出典4）
- NAT越え（UDP 4500）は発信側の仕組みであり、着信を作るものではない（出典5・6）。「NAT-T対応だから大丈夫」とは言い切れない
- トンネルが二重になるとMTUの問題が出やすい。「疎通はするが大きな通信だけ落ちる」はサイズの設計を疑う（出典8）
- 実現パターンは4つ。待ち受けが1か所で足りるなら固定IPも1か所で足りることがあり、全拠点に揃える必要はない場合がある
- VPN機器は侵入経路として最も多く報告されている（侵入経路のうちVPN機器が6割以上／出典9）。回線を用意することと、機器を安全に運用し続けることは別の作業
- 固定IPは「アドレスが変わること・共有されていること」に起因する課題を扱うもので、速度の問題とは別
進め方としては、矢印を決める → 待ち受け側の回線条件を確認する → 機器の対応可否を確認する → 保守の担当を決める。この順で進めると、見積もりの比較が噛み合います。
参考（出典）
- JPNIC「IPv6におけるPPPoE方式とIPoE方式とは」 nic.ad.jp
- インターネットマルチフィード「IPv4 over IPv6接続『DS-Lite』| transix」 mfeed.ad.jp
- RFC 6333「Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion」（2011年8月・Standards Track） rfc-editor.org
- RFC 6269「Issues with IP Address Sharing」（2011年6月・Informational／§5.2 Incoming Ports・§15 Reverse DNS） rfc-editor.org
- RFC 3948「UDP Encapsulation of IPsec ESP Packets」（2005年1月・Standards Track／UDPポート4500） rfc-editor.org
- RFC 7296「Internet Key Exchange Protocol Version 2 (IKEv2)」（2014年10月・STD 79／§2.23 NAT Traversal） rfc-editor.org
- インターネットマルチフィード「IPv4 over IPv6接続『固定IP (IPIP)』| transix」（RFC 2473準拠・IPIP対応ルーターの設置と設定作業が必要） mfeed.ad.jp
- RFC 4459「MTU and Fragmentation Issues with In-the-Network Tunneling」（2006年4月・Informational） rfc-editor.org
- 警察庁サイバー警察局「令和7年におけるサイバー空間をめぐる脅威の情勢等について」（令和8年3月・p.15） npa.go.jp（PDF）
- 総務省「テレワークセキュリティガイドライン（第5版）」（令和3年5月） soumu.go.jp（PDF）
- RFC 2473「Generic Packet Tunneling in IPv6 Specification」（1998年12月・Standards Track） rfc-editor.org
この記事について
- 運営者: 有限会社ゼスト（GIGANEXT／法人向けインターネット接続サービス）
- 本記事は、インターネットマルチフィード株式会社、JPNIC、IETF（RFC）、警察庁、総務省が公開する情報をもとに作成しています。サービスの仕様・提供条件は変更される場合がありますので、最新の内容は各社の公式情報および当社へのお問い合わせでご確認ください。
- 本記事は特定の通信速度・品質・動作・安全性を保証するものではありません。
