「ポート開放していないから安全」は本当？ P2P・IPv6・オンプレVPNから考える“外から届く入口”のリスク
オンプレミスVPNがランサムウェア侵入のきっかけになった。
そんな話を見聞きすることがあります。
すると、
「オンプレVPNは危険なのでは？」
と思いたくなります。
でも、問題をVPNだけに絞ると、本質を見失います。
本当に考えるべきなのは、
Internet側から、自宅や社内のネットワークへ直接到達できる経路を持っているかどうか
です。
その経路は、手動で開けたポートかもしれません。
UPnPが自動で作ったものかもしれません。
P2PがNAT Traversalで動的に成立させたものかもしれません。
IPv6でGlobal Addressへ直接到達させているかもしれません。
あるいは、SASEやZTNAを導入していても、既存のVPN Gatewayや管理用ポートがそのまま残っているかもしれません。
仕組みは違っても、セキュリティ上の問いは同じです。
外から何が届くのか。
そして、その入口が破られたとき、どこまで到達できるのか。
昔のVPNは「Public IPv4がある」ことを前提にしていた
昔ながらの自宅VPNやオンプレVPNは、かなり単純でした。
Internet
│
▼
Public IPv4
│
Port Forward / VPN Gateway
│
▼
自宅・社内ネットワーク自宅や会社のルーターにPublic IPv4がある。
必要なポートを開ける。
外からVPN Gatewayへ接続する。
これで成立します。
今でも、Inbound可能なPublic IPv4があり、ルーターを自分で管理できる環境なら、この方式はシンプルです。
ただ、2026年の回線事情では、この前提が当たり前ではなくなっています。
CGNAT、DS-Lite、モバイル回線、固定無線回線などでは、昔ながらのIPv4 Inboundが成立しにくいケースがあります。
そこで出てくるのが、
「P2Pならポート開放しなくていい」
という考え方です。
「ポート開放不要」でも、外から届かないとは限らない
P2P型VPNでは、手動でPort Forwardを設定せず、NAT Traversalによって直接接続を成立させようとします。
概念的にはこうです。
自宅側端末
│
│ Outbound UDP
▼
NAT
│
│ Mapping / State
▼
Internet
▲
│
接続元端末自宅側から外向きにUDPを送る。
NATに状態が作られる。
その状態を利用して、外部の接続元端末から自宅側端末へ直接接続を試みる。
うまくいけば、
接続元端末 ◀────── Direct P2P ──────▶ 自宅側端末となります。
低遅延で、余計な中継もありません。
かなり魅力的です。
ただし、ここで注意したいのが、
「ポート開放していない」＝「外からパケットが届かない」ではない
ということです。
Direct P2Pが成立しているなら、外部の接続元から送られたパケットは、実際にNATの内側にある自宅や社内側の端末まで届いています。
手動のPort Forwardではありません。
でも、動的なInbound経路は成立しているわけです。
手動のPort Forwardは、入口を作る方法の1つにすぎない
ユーザー本人は、
「ルーターでポートなんて開けていない」
と思っていても、外部から到達可能な経路が存在することがあります。
例えば、
UPnP
NAT-PMP
PCP
P2P NAT Traversal
UDP Hole Punching
IPv6のFirewall Allow
などです。
UPnPが有効なら、アプリケーション側がルーターへポートマッピングを要求することもあります。
Application
│
│ Mapping要求
▼
Router / UPnP
│
│ 自動でMapping作成
▼
Internetから到達可能ユーザーはルーターの管理画面を開いていません。
Port Forwarding設定も触っていません。
それでも、外部から届く経路が作られることはあります。
なので、本当に確認すべきなのは、
「自分でポートを開けたか？」
ではありません。
「今、この接続先へInternetから何かが届く状態なのか？」
です。
NATの内側だから安全、とは限らない
NATは、主にAddress Translationの仕組みです。
それ自体を完全な認証機構として扱うべきではありません。
NATによって、外部からの通信が結果的に制限されることはあります。
ただし、NAT Mappingが作られたあと、どの外部パケットを通すかは実装やフィルタリングの挙動に依存します。
だからP2P VPNでも、最終的に重要なのはNATではありません。
VPN Protocol側の暗号認証です。
つまり、
NATを通ったから正しい接続相手
ではない。
逆に、
Port Forwardを設定していないから外から絶対に届かない
でもない。
STUNも「安全にしてくれる仕組み」ではない
STUNは、NATの内側にいる端末が、
「外から見ると自分はどのIP Address / Portに見えているのか」
を知るために使われます。
ただし、
外から見えるAddressを知ること
と、
その通信相手を信頼してよいこと
は別問題です。
Local Device
│
│ Outbound
▼
NAT Mapping
│
▼
Public IP : Port利用可能なMappingが存在すれば、NATのフィルタリングの挙動によっては、外部からそのMapped Addressへパケットが届く可能性があります。
もちろん、
偽装された適当なパケットを投げれば、そのままVPNへ侵入できる
という話ではありません。
WireGuardなどでは暗号認証があるため、正しい鍵を持たないパケットはVPN Trafficとして成立しません。
重要なのは、
「NATの内側だから何も届かない」という前提は強すぎる
ということです。
ではIPv6 Nativeなら解決するのか
IPv4 NAT Traversalが難しいなら、
IPv6で直接つなげばいい
という考え方もあります。
確かにIPv6では、NATを使わずGlobal IPv6 Addressへ直接到達できる構成があります。
Internet
│
▼
Global IPv6
│
IPv6 Firewall
│
▼
VPN接続先ただし、ここでも2つの話を分ける必要があります。
IPv6が使えること
と、
IPv6 Inboundを実際に許可できること
は別です。
IPv6自体は利用できても、RouterやISP側の仕様によってInboundを自由に開けられるとは限りません。
さらに、接続元にもIPv6が必要
自宅側のVPN接続先をIPv6だけで公開した場合、外出先側にも利用可能なIPv6が必要です。
接続元端末
IPv6あり
│
▼
自宅VPN
Global IPv6なら接続できます。
でもホテルやカフェのWi-FiがIPv4-onlyなら、
接続元端末
IPv4 only
│
X
│
自宅VPN
Global IPv6となります。
自宅側は何も変わっていません。
VPN設定も変わっていません。
変わったのは、接続元のネットワークだけです。
自宅VPNは、まさに自宅以外から使うものです。
ホテル、カフェ、空港、オフィスなど、自分で管理できないネットワークで使うなら、
自宅だけIPv6ならそれで終わり
とはいきません。
ならモバイル回線へ切り替える？
ホテルWi-FiでIPv6が使えないなら、スマホ回線や旅行用eSIMへ切り替える方法もあります。
それで接続できる場合もあります。
ただし、今度は別の問題が出ます。
ギガです。
メールや軽いWeb閲覧なら気にならなくても、
動画
大容量ゲームのダウンロード
OS Update
Cloud Sync
写真や動画のBackup
までVPN経由で流せば、データ容量をかなり消費します。
Hotel Wi-Fi
│
├─ ギガを消費しない
└─ IPv6がない可能性
Mobile / Travel eSIM
│
├─ 接続できる可能性
└─ 大容量通信でギガ消費IPv6は直接接続を成立させる手段にはなります。
でも、
どこからでも安定して自宅VPNへつながる
ことまで保証するわけではありません。
P2Pは「つながる」を解決しても「安定」を保証しない
P2Pも同じです。
Directが成立すれば速い。
接続元 ◀──── Direct ────▶ 自宅・社内側でもネットワーク条件が変わると、Directが成立しなくなることがあります。
その場合、中継経路へ切り替わります。
接続元 ───▶ Relay ───▶ 自宅・社内側そして後からDirectが成立すれば、直接経路へ戻る場合もあります。
つまり内部では、
Direct
↓
Relay
↓
Direct
↓
Relayのように経路が切り替わることがあります。
ユーザーから見るとVPN自体はつながったままでも、
急にLatencyが増える
Throughputが落ちる
また速くなる
場所を変えたら遅くなる
といった変化が起きます。
IPv6にすればDirectを成立させやすくなるケースはあります。
でも、
IPv6にすればP2Pが常にDirectで安定する
わけではありません。
ここでランサムウェアの話につながる
オンプレミスVPNがランサムウェア侵入の入口になった、という話を耳にすることがあります。
ただし、VPNの暗号そのものが破られているとは限りません。
攻撃者が狙うのは、
VPN Applianceの脆弱性
Authentication Bypass
管理画面
盗まれたVPN Credential
Session
MFAの弱点
PatchされていないFirmware / Software
などです。
昔ながらの構成では、
Internet
│
▼
VPN Gateway
│
▼
Corporate Networkとなります。
VPN Gatewayは、Remote Userが使うためにInternetから到達できなければなりません。
つまり、
VPN GatewayそのものがInternet-facingな攻撃面
になります。
危険なのはVPNだけではない
ここで、
「だからオンプレVPNは危険だ」
とだけ結論づけるのも少し違います。
同じ問題は、
SSH Server
RDP Gateway
NAS
Remote Management Interface
Self-hosted Web Application
Port ForwardされたServer
UPnPで自動公開されたService
IPv6で直接公開したService
P2Pで直接到達できる状態になった端末
にもあります。
技術は違います。
でも問いは共通しています。
Internetから何が直接届くのか。
そして、その接続先が破られたら何が起きるのか。
SASEを入れれば、この問題は解決するのか
ここで、
「それならSASEやZTNAを導入すればいいのでは？」
という考え方も出てきます。
SASEは、認証、アクセス制御、Web Security、ZTNAなどをCloud側へ集約できる強力なアプローチです。
ユーザー単位の認証やPolicy適用、拠点をまたいだ一元管理という点では、大きなメリットがあります。
ただし、
SASEを導入したからといって、社内側のInternet-facingな入口が自動的になくなるわけではありません。
例えば、
既存のVPN Gatewayを残している
管理用SSHやRDPを外部公開している
NASやRemote Management Interfaceが直接到達可能
IPv6でVPN接続先を直接公開している
P2PでDirect経路を成立させている
既存のPort ForwardやUPnP Mappingが残っている
といった構成なら、SASEの導入後も直接到達可能な入口は残ります。
つまり、重要なのは、
「SASEを導入しているかどうか」
だけではありません。
「Internetから自宅や社内側へ直接届く経路が、まだ残っていないか」
です。
SASEは非常に有効なセキュリティ設計の一部になり得ます。
でも、
Direct Inboundの入口を残したまま、その前段にSASEを追加しただけ
なら、今回問題にしている攻撃面がすべて消えるとは限りません。
P2Pだからこの問題から逃れられるわけでもない
P2Pには大きなメリットがあります。
手動でPort Forwardしなくていい。
ネットワーク条件がよければ自動でDirect接続できる。
非常に便利です。
でもDirect P2Pが成立しているなら、外部の接続元から送られたパケットは自宅や社内側の端末へ到達しています。
もちろん、だからP2P VPNが危険だという意味ではありません。
暗号認証、実装、端末側のセキュリティ、アクセス制御が適切なら、安全性を確保できます。
ただし、
No Port Forwarding ≠ No Inbound Path
です。
そして、
P2P ≠ No Attack Surface
でもあります。
「NATの内側だから安全」という説明だけでは十分ではありません。
共通しているのはDirect Inboundという設計
ここまでの方式を並べてみます。
手動Port Forward
Internet
│
▼
Open VPN Port
│
▼
自宅・社内側UPnPなどによる自動Mapping
Internet
│
▼
UPnP / PCP Mapping
│
▼
自宅・社内側の接続先P2P NAT Traversal
Internet
│
▼
NAT Traversal
│
▼
P2P端末IPv6 Direct
Internet
│
▼
Global IPv6
│
▼
自宅・社内側の接続先SASEを導入してもDirect Inboundを残した構成
SASE
│
│
Internet ─────┼─────▶ VPN Gateway / SSH / RDP
│ │
│ ▼
│ 社内ネットワークSASEが存在していても、別のDirect Inbound経路が残っていれば、その入口は引き続き管理しなければなりません。
仕組みは違います。
でも全部、
Internet側から自宅や社内側の接続先へ直接到達できる経路が存在する
という点では同じです。
そこで一度、問いそのものを変えてみます。
そもそも、Internetから自宅や社内側のVPN接続先へDirectに届く必要はあるのでしょうか。
逆の発想：Outbound Hub & Spoke
自宅や社内側をInternetからDirectに到達可能にするのではなく、自宅や社内側から外向きにTunnelを張る方式があります。
Hub
/ \
/ \
Outbound Outbound
/ \
接続元 自宅・社内側自宅や社内側がHubへOutbound接続する。
接続元側もHubへOutbound接続する。
Hubが待ち合わせ点になります。
この構成なら自宅や社内側は、
Public IPv4
Port Forward
UPnP Mapping
Global IPv6 VPN接続先
P2P NAT Traversal
Direct P2P Path
をRemote Accessの必須条件にしなくて済みます。
もちろん、これでセキュリティリスクがゼロになるわけではありません。
Hub、認証、鍵、Client、Software、Access Controlは安全に設計する必要があります。
ただし大きく違うのは、
自宅や社内側のVPN接続先をInternetから直接到達可能にする必要がない
という点です。
HomeGrid VPNはこのOutbound型
HomeGrid VPNは、Outbound型のHub & Spoke構成を取っています。
自宅や社内側のGridがHubへOutbound Tunnelを張ります。
接続元端末側もHubへOutbound接続します。
Hub
/ \
/ \
接続元端末 Grid
│
▼
Private LANそのためPrivate Networkへの接続に、
Public IPv4
IPv4 Port Forward
UPnPによるInbound Mapping
IPv6 Inbound
接続元側IPv6
P2P NAT Traversal
Direct P2P Path
を前提にする必要がありません。
ここで重要なのは、
「SASEかHomeGrid VPNか」という単純な比較ではない
ということです。
SASEは認証やPolicy、Security ServiceをCloud側へ集約する考え方です。
HomeGrid VPNがここで変えているのは、
自宅・社内側へDirect Inboundすること自体をRemote Accessの前提から外す
というネットワーク到達性の部分です。
両者が見るレイヤーは必ずしも同じではありません。
Internet-facingな入口をなくしても、それだけでは足りない
ランサムウェア対策を考えるなら、もう一つ重要なことがあります。
VPNへ接続したあと、どこまで到達できるのか
です。
従来型のRemote Accessでは、
接続元ユーザー
│
VPN
│
▼
社内LAN
├─ File Server
├─ Development Network
├─ NAS
├─ Backup Network
└─ Other Systemsのように、VPNへ入ったユーザーが広い範囲へ到達できる構成もあります。
もしAccountや端末が侵害された場合、
侵入できたこと
だけでなく、
そこから横展開できること
も問題になります。
HomeGrid VPNではLAN ACLで到達範囲も制限する
HomeGrid VPNではLAN ACLを使い、Private Subnet同士の到達範囲を制限できます。
例えば、
Remote / VPC A
│
├──▶ Project A Subnet Allow
│
├──▶ Project B Subnet Deny
│
└──▶ Backup Network Denyという考え方です。
VPNへつながったからといって、Private Network全体へ到達できる必要はありません。
必要なNetworkだけを許可する。
それ以外はDefault Deny。
許可された通信の戻りはStatefulに通す。
つまり、
1. Internetから自宅や社内側へDirectに到達させない
ことと、
2. 接続後も必要以上に横へ広げない
ことを分けて考えます。
ランサムウェアから学ぶべきことは「VPNが危険」ではない
オンプレVPNがランサムウェア侵入経路になった例を見て、
「VPN Applianceは危険だ」
だけで終わると、本質を見落とします。
同じように、
「SASEを導入したから安全」
だけで終わるのも早計です。
より重要なのは、
Internetから自宅や社内へDirectに到達できる経路は、すべて攻撃対象になりうる入口として考える
ことです。
手動で開けたPort。
UPnPが自動作成したMapping。
IPv6で直接公開した接続先。
P2P NAT Traversalによって動的に成立した直接経路。
SASE導入後も残っている既存VPN Gatewayや管理用の入口。
仕組みは違っても、
No Port ForwardingだからInbound Pathがない
とは限りません。
そして、
SASEがあるからDirect Inboundの問題も自動的に消える
とも限りません。
IPv4 NAT Traversalが難しくなったからIPv6へ移れば、それですべて解決するわけでもありません。
IPv6にはInboundや接続元側IPv6という別の条件があります。
P2PもDirectを自動化できますが、中継経路への切り替えや直接経路への復帰によって性能が変化することがあります。
だから2026年に考えるべき問いは、
「どうすればDirect接続を成立させられるか？」
だけではないのかもしれません。
むしろ、
「なぜInternetから自宅や社内側のVPN接続先へDirectに到達する必要があるのか？」
です。
Outbound Hub & Spokeは、すべてのセキュリティ責任をなくす魔法ではありません。
でも、スタート地点を変えます。
Internetから自宅や社内へ入ってくる入口を作るのではなく、
自宅や社内側から先に外へ接続する。
そして接続後も、必要なNetworkだけに到達範囲を絞る。
2026年のRemote Accessでは、VPN製品やSASE製品を選ぶ前に、
「そもそもInternetから直接届く入口を本当に残す必要があるのか」
から考え直してもいいのかもしれません。
