【全滅】自作VPN・P2P・ポート開放・DDNSがIPv4 over IPv6／10Gbps時代に「詰む」理由

追記：では、どんな回線なら自宅VPNをDIYできるのか？

ここまで見てきたように、ポート開放やP2Pがうまくいくかどうかは、ルーター設定だけでなく契約している回線方式そのものに大きく左右されます。

では、2026年の日本で自宅VPNをDIYするなら、どんな回線なら現実的で、どんな回線では難しいのか。

MAP-E / DS-Lite / CGNAT / IPv6環境も含めて、回線ごとに整理しました。

→ 自宅VPNをDIYできる回線・できない回線｜2026年の日本では何が現実的なのか

「自宅にWireGuardを立てた。LAN内では動く。でも外からつながらない」

「Port ForwardもDDNSも設定したのに、海外へ行ったら自宅VPNへ入れない」

「P2PならPort Forward不要と聞いたのに、なぜかDirectにならずRelayへ落ちる」

こんなふうに、昔なら定番だった方法を全部試したのに“全滅状態”になることがあります。

昔の自宅VPNは、もっと単純でした。

Public IPv4
    ↓
Port Forward
    ↓
WireGuard / OpenVPN
    ↓
DDNS

Public IPv4が変わるならDDNSで追いかける。

RouterでUDP Portを開ける。

それだけで、外出先から自宅へ接続できる回線も多くありました。

しかし現在の家庭用回線では、CGNAT、MAP-E、DS-LiteなどのIPv4 over IPv6が広がり、この前提そのものが崩れています。

さらに、

• P2Pなら解決するのか

• IPv6 Directなら解決するのか

• 固定IPv4を契約すればいいのか

• 10Gbps回線では何が変わるのか

• HotelやFree Wi-Fiでも同じように使えるのか

• 自宅Public IPをDirect接続先として見せてよいのか

• それを3年、5年と維持できるのか

まで考えると、問題は単なる「WireGuardの設定方法」ではありません。

最初に断っておくと、従来方式がすべての環境で使えないわけではありません。

Public IPv4があり、Port Forwardできる回線なら、自宅WireGuardは今でも作れます。

MAP-Eでも割り当てられたPortを使って成立させられる場合があります。

固定IPv4を契約する方法もあります。

IPv6 Directという方法もあります。

問題は、

「できるか」ではなく、今からゼロから作り、それを何年も維持する方法としてどうなのか

です。

1. MAP-Eでは「好きなPortを開ける」がほぼ成立しない

IPv4 over IPv6の代表的な方式の一つがMAP-Eです。

MAP-Eでは、1つのPublic IPv4を複数の契約者で共有し、それぞれが利用できるIPv4 PortをPort Setとして分割します。

1つのPublic IPv4
       ↓
複数ユーザーで共有
       ↓
各ユーザーには
一部のPortだけ割り当て

ここで重要なのは、

Routerで好きなPortを自由に開けるわけではない

ということです。

WireGuard標準の51820番がそのまま使える割合は約0.39%

v6プラス系でよく知られる構成例では、IPv4 Portのうち 4096〜65535番 が利用対象になります。

この範囲に含まれるPort数は、

65535 - 4096 + 1
= 61,440 Port

です。

この61,440 Portの中から1契約に240 Portが割り当てられる構成なら、

240 ÷ 61,440
= 0.00390625
≒ 0.39%

になります。

つまり、WireGuard標準の 51820/UDP のような**特定の1 Portが、自分のPort Setに含まれる割合は約0.39%**です。

逆に、その特定Portが自分のPort Setに含まれない割合は約99.6%になります。

これは「Routerを再起動するたび99.6%の確率で外れる」という意味ではありません。

MAP-EのPort Setは一定のルールに基づいて決まります。

重要なのは、

61,440 Portのうち、自分が使えるPortは240個しかない

ということです。

そのため、

UDP 51820をPort Forward
        ↓
WireGuardへ接続

という昔ながらの設定をそのまま持ってきても、そのPortが自分のPort Setに含まれていなければ使えません。

もちろん、自分に割り当てられたPortを確認し、WireGuard側のListen Portを合わせれば成立するケースはあります。

ただ、それは昔の、

UDP 51820を開ける
       ↓
終わり

という世界とは違います。

さらにDS-Liteや一般的なCGNATでは、MAP-Eのような利用者向けPort Setそのものを前提にできません。

LAN内ではWireGuardが正常に動くのに外からだけつながらない場合は、WireGuardの設定を直し続ける前に、そもそもPacketがServerまで届いているかを確認した方が早い場合があります。

→ ポート開放したのにWireGuardが外からつながらない。まず「回線」を疑ってみる

2. 「だったら固定IPv4を1個契約すればいい」は、その通り

ここまで読むと、

「それなら共有IPv4を使わず、自宅用にPublic IPv4を1個専有すればいいのでは？」

と思うかもしれません。

その方法は今でもあります。

個人向けでも固定IPv4を利用できるServiceはあり、対応Routerと組み合わせれば、

Internet
   ↓
専有Public IPv4
   ↓
Home Router
   ↓
Port Forward
   ↓
WireGuard Server

という昔ながらの構成を取り戻せます。

つまり、IPv4 Directが技術的に使えなくなったわけではありません。

ただし、その場合でも、

• 固定IPv4の契約

• 対応Router

• Port Forward

• Firewall

• VPN Server

• OSやPackageのSecurity Update

• Hardware故障への対応

は自分で管理します。

さらに、固定IPv4には別の側面もあります。

自宅WireGuardへDirect接続する場合、その固定IPv4はRemote側Networkから見えるVPNの接続先になります。

Free Wi-Fi
    ↓
Encrypted VPN
    ↓
Fixed Home Public IP

VPN Tunnel内部の通信内容は暗号化されていても、VPN PacketがどのPublic IPへ向かっているかまで隠れるわけではありません。

Public IPから正確な住所が分かるわけではありませんが、GeoIP、ISP、ASN、Reverse DNSなどから、おおよその地域やNetwork情報を推測できる場合があります。

固定IPv4は同じAddressを継続して利用するため、その家庭やNetworkを長期間識別する情報にもなり得ます。

つまり固定IPv4は、IPv4 Directの接続性を解決する方法にはなります。

ただし、Direct接続に伴うPublic IPの露出と長期運用までなくなるわけではありません。

3. DDNSは「IPが変わる」を解決する。でもInboundまでは解決しない

固定IPv4を契約しない場合、昔の自宅VPNとセットでよく使われるのがDDNSです。

home.example.net
       ↓
現在のPublic IPv4

Public IPが変わったら、自宅RouterやDDNS Clientが新しいIPをProviderへ通知します。

ただし現在では、

Public IPが分かること

と、

そのPublic IPから自宅へInboundできること

が別問題になりました。

DDNS
 ↓
共有Public IPv4
 ↓
CGNAT / IPv4 over IPv6
 ×
自宅VPN

DDNSが正しいPublic IPを返していても、ISP側でInboundを自宅まで届けられなければ接続できません。

さらにDDNSは長期運用すると、

• Router側の更新が止まる

• 認証情報が切れる

• 再Loginが必要になる

• IP変更後に正常更新されない

• FirmwareやProvider側の仕様変更が起きる

といったこともあります。

厄介なのは、海外へ出てから壊れた場合です。

海外
 ↓
home.example.net
 ↓
古いPublic IP
 ×
自宅

入口そのものが壊れているので、その入口を使ってRemote修復することもできません。

昔から安定して動いている構成を無理に変える必要はありません。

ただ、今から新しく、

Public IPv4 + Port Forward + DDNS

という依存関係を増やすなら、構築時だけでなく長期運用まで考えた方がいいでしょう。

4. 「P2PならPort Forward不要」で全部解決するわけではない

ではP2P型VPNならどうでしょうか。

P2P型VPNでは、STUNなどを使って外側から見えるIP AddressとPortを確認し、双方からUDPを送り合ってDirect接続を試みる方式があります。

かなり乱暴に言えば、UDPのキャッチボールです。

Home                    Remote
 │                         │
 ├── STUN                  ├── STUN
 │                         │
 └── Endpoint情報を交換 ──┘
            ↓
      双方からUDP送信
            ↓
       Directを試す

これが成立すれば、Routerで明示的なPort Forwardを設定しなくてもDirect接続できます。

ただし、

必ずこのキャッチボールが成立するわけではありません。

5. Symmetric NATではSTUNで見えたPortが相手側で使えないことがある

たとえばHome側がSTUN Serverへ通信した結果、

Home → STUN

203.0.113.10:40000

と外側から見えていたとします。

そのEndpoint情報がSignalingやControl Planeを通じてRemote側へ共有されます。

しかしNATによっては、HomeからRemoteへ通信するとき、

Home → Remote

203.0.113.10:51234

のように、通信相手によって外側のPort Mappingが変わることがあります。

すると、

HomeがSTUNで確認
203.0.113.10:40000
        ↓
Remoteへ共有
        ↓
実際のRemote向けMappingと一致しない

となり、単純なSTUN + UDP Hole PunchingではDirect接続が成立しない場合があります。

しかも条件はHome側だけではありません。

Remote側もHotel Wi-Fi、Cafe Wi-Fi、Mobile Network、企業Networkなど、別のNATやFirewallの内側にいます。

つまり、

「P2PだからPort Forward不要」

と、

「世界中どこからでもDirect接続できる」

は別の話です。

6. DirectできなければRelay。でもRelayはDirectと同じではない

P2P Directに失敗した場合、RelayへFallbackする方式があります。

Remote
  ↓
Direct ?
  ├─ YES → Home
  │
  └─ NO
       ↓
     Relay
       ↓
     Home

Webを少し見る程度なら問題にならないこともあります。

ただし、自宅回線をInternet Exitとして使い、

• 動画

• Game Update

• Cloud Sync

• 大容量Download

• File Transfer

などを流すと、Relayの影響が見えやすくなります。

特にTCPベースのRelayでVPN Trafficを中継し、その中をさらにTCP Application Trafficが流れる構成では、Head-of-Line BlockingやTCP-over-TCP系の性能問題が出やすくなります。

つまり、

Direct失敗時のRelayは、Directの完全な代用品とは限りません。

7. P2P VPNは「VPNを張る前」にInternetへ出られないと始まらない

P2P型VPNでは、VPN Tunnelを張る前に、

Internet接続
    ↓
Control Plane
    ↓
端末認証
    ↓
Peer情報取得
    ↓
STUN
    ↓
Direct / Relay
    ↓
VPN通信

という前段階があります。

つまり、

VPN Data Planeができる前にControl Planeへ到達できること

も成立条件になります。

HotelやFree Wi-Fiでは、さらにその前に認証画面を通す必要があることもあります。

Hotel Wi-Fi
    ↓
認証画面
    ↓
Internet
    ↓
VPN Control Plane
    ↓
VPN

「Free Wi-Fiにつないだ瞬間からVPNが全部守ってくれる」

とは限りません。

8. VPNを使っていても、「VPNの接続先」は見える

Free Wi-FiでVPNを使えば、VPN Tunnel内部の通信内容は暗号化できます。

ただし、自宅WireGuardへDirect接続する場合、VPN Packetそのものには宛先が必要です。

Free Wi-Fi
    ↓
Encrypted VPN
    ↓
Home Public IP

つまり、Wi-Fiの運営側や通信経路上からは、通信内容そのものを読めなくても、

どのPublic IPへ暗号化Trafficを送っているか

は観測できます。

Public IPから番地や部屋番号がそのまま分かるわけではありません。

GeoIPの精度も一定ではありません。

一方で、ISP、ASN、Reverse DNS、おおよその地域などを推測できる場合があります。

Public IP
    ↓
GeoIP / ISP / Reverse DNS
    ↓
おおよその地域やNetwork情報

だから、

「〇〇市までしか分からないから安心」

とは単純に言えません。

重要なのは、そのIPがどの家庭や会社のNetworkにつながる入口なのかを識別する材料にもなることです。

9. 家庭用RouterのPublic IPなら、単なる位置情報ではない

もしVPNの接続先Public IPが、家庭用RouterのWAN側Addressならどうでしょうか。

それは、

「この人は〇〇市付近に住んでいるらしい」

という情報だけではありません。

その家庭のInternet側の境界を示す情報

でもあります。

Public IPが知られただけで侵入されるわけではありません。

FirewallやAuthenticationが適切なら、それだけで不正アクセスが成立するわけでもありません。

ただし家庭用Routerは、自宅のPC、NAS、Smart Home機器などが接続されたNetworkの境界です。

Firmwareが古い。

不要なRemote Managementが有効。

Internet公開Serviceが残っている。

こうした条件があればRiskは高くなります。

一方で、Firmwareを最新に保っていても、すべての脆弱性に対応できる保証はありません。

まだ修正が提供されていない問題や、まだ発見・報告されていない問題が存在する可能性もあります。

そしてDirect接続では逆方向の情報もあります。

Home RouterやVPN Server側からは、接続してきたRemote側のSource Public IPが見えます。

Hotel / Free Wi-Fi
        ↓
Source Public IP
        ↓
Home Router / VPN Server

もしHome側が侵害され、接続履歴などを取得された場合、外出先からVPNを利用した地域や時間帯、移動パターンを推測する材料にもなり得ます。

つまり家庭用Routerは、単なるVPNの入口ではなく、Home側とRemote側のNetwork情報が交差する場所でもあります。

10. 家庭では「侵入された後」の対策を積み上げるのも簡単ではない

企業Networkであれば、侵害を前提として、

• Network Segmentation

• EDR

• IDS / IPS

• 集中Log監視

• Incident Response

などを組み合わせることができます。

家庭でも技術的には可能です。

ただ、それを個人で何年も維持するとなると話は別です。

機器を入れて終わりではありません。

設定、Update、監視、Alert確認、障害対応まで継続して行う必要があります。

つまり家庭用VPNでは、

「入口を公開して、侵害後のDefenseをさらに積み上げる」

という構成自体が、個人にとってはかなり重い運用になります。

では、侵害後の対策を増やす前に、そもそもInternetへ公開する入口を増やさない設計にできないのか。

この考え方は、後半のOutbound型の構成で改めて扱います。

11. IPv6 Directは有力。でも旅行用VPNの唯一の入口にはしにくい

IPv4 Directが難しいなら、

IPv6でHomeへ直接WireGuardすればいい

という方法があります。

これは技術的には有力です。

Remote IPv6
     ↓
Internet
     ↓
Home Global IPv6
     ↓
WireGuard

IPv6ならIPv4 NATによるPort Forwardを前提にせず、Global IPv6 Addressへ直接到達できます。

ただし、

「IPv6ならPort Forward不要」

と、

「IPv6ならInboundを考えなくていい」

は別です。

Home側では、

• Global IPv6があるか

• RouterのIPv6 FirewallでInboundを許可できるか

• Server OS側Firewallが許可しているか

• ISP側から到達できるか

を確認する必要があります。

そして旅行や出張用途では、さらに大きな制約があります。

Remote側にもIPv6が必要です。

Hotel、Cafe、AirportなどのGuest Wi-Fiでは、利用者側でIPv6対応を選ぶことができません。

そのため旅行用VPNを設計するときは、

「Hotel Wi-FiでもIPv6が使えるだろう」ではなく、「使えたらラッキー」くらいに考えておく

方が現実的です。

Home
Global IPv6
   ↑
   ×
Hotel / Free Wi-Fi
IPv4 only

Home側を完璧に設定していても、接続元がIPv4-onlyならIPv6 Directは利用できません。

Mobile Tetheringへ逃げる方法もありますが、海外ではRoamingやTravel eSIMのDataを消費します。

そのため、世界中のHotelやFree Wi-Fiから使うRemote Access VPNの唯一の入口としてIPv6 Directに依存することはおすすめしません。

12. IPv6が使えた場合も、今度はHome Global IPv6が見える

接続元Wi-FiがIPv6対応ならDirect接続できる可能性があります。

ただしその場合は、

Free Wi-Fi
    ↓
Encrypted WireGuard
    ↓
Home Global IPv6

となります。

VPN内部の通信内容は暗号化されても、VPN接続先であるHome Global IPv6まで隠れるわけではありません。

ここでIPv6 Addressの構造を簡単に整理します。

一般的な /64 Prefixでは、

IPv6 Address
┌────────────────┬────────────────┐
│ 上位64bit       │ 下位64bit       │
│ Network Prefix │ Interface ID   │
└────────────────┴────────────────┘
     /64 Prefix       Host側

という構成になります。

Prefixが分かっていたとしても、下位64bitのInterface IDを総当たりし、すべての /128 Addressを探索することは現実的ではありません。

ただし、

「総当たりScanが現実的でない」＝「Endpointを発見されない」

ではありません。

DNS、公開情報、Addressの規則性、過去の観測情報、Traffic Observationなど、IPv6 Addressを知る経路は他にもあります。

特にDirect VPNでは、自宅のGlobal IPv6へ実際に通信するため、接続元NetworkにはVPN Serverの正確な /128 Endpointが見えます。

つまり、IPv6 Address空間が広いため無差別な総当たり探索が難しくても、自分からそのAddressへ接続すれば、接続元Networkに対しては「探しにくさ」はほとんど意味を持ちません。

また、個別の /128 Addressだけでなく、ISPから割り当てられるIPv6 Prefixが一定期間安定していれば、そのPrefixも同じ家庭Networkを識別・相関する材料になる可能性があります。

つまりIPv6 Directでは、

RemoteがIPv4 only
       ↓
接続できない

RemoteがIPv6対応
       ↓
Direct接続できる
       ↓
Home Global IPv6が
接続先として見える

というTrade-offがあります。

管理できる2拠点間ならIPv6 Directは有力です。

しかし旅行・出張用途では、Remote側IPv6を必須条件にしない設計の方が扱いやすいでしょう。

IPv6 Firewallや接続元IPv6など、詳しい条件はこちらの記事で整理しています。

→ 「IPv6ならポート開放不要」は本当？ 自宅WireGuardで見落としやすいIPv6 Firewallの話

13. Direct型では「接続性」と「露出」の両方を見る

ここまでの話を整理すると、Direct型VPNには大きく2つの論点があります。

一つは、

Direct接続を成立させる条件。

もう一つは、

Home / OfficeのEndpointをRemote側Networkへ直接見せること。

Home側の回線条件
      ×
Router
      ×
Firewall
      ×
DDNS
      ×
Remote側Network
      ×
IPv4 / IPv6
      ×
NATの種類
      ↓
Direct接続

IPv4 DirectならPublic IPv4やPort Forward。

MAP-Eなら利用可能なPort Set。

P2PならNAT Traversal。

IPv6 Directなら双方のIPv6接続性とFirewall。

それぞれに解決方法はあります。

ただしDirect接続が成立しても、

Remote Network
      ↓
Home / Office Endpoint

という関係は残ります。

つまり、

「つながるか」だけでなく、「Remote側へ何を見せる設計なのか」

まで含めて考える必要があります。

14. さらに10Gbps時代では「つながった後」の性能差も大きい

ここまでで、Direct接続を成立させる条件と、Endpointを直接見せるという問題を整理しました。

ただし、自宅VPNにはもう一つあります。

つながったあとに、どれだけ速く通信できるか

です。

回線が10Gbpsでも、VPN方式が先に頭打ちになれば、そこが通信全体のボトルネックになります。

特に従来型VPNとWireGuardでは処理設計が大きく異なります。

WireGuardは高速なVPN Protocolで、HardwareやNetwork条件が合えば1Gbpsを超える通信も現実的です。

つまり、

「VPNだから1Gbps未満になるのは仕方ない」

という前提で考える必要はありません。

HomeGrid VPNもWireGuardを利用しています。

なお、ここで比較しているのはVPN Protocolそのものの処理性能です。

HomeGrid VPNでは実際の通信経路にCloud Hubも含まれるため、この話をそのままEnd-to-Endの実効速度保証として扱うものではありません。

15. DIY VPNは「作る」より「何年も維持する」方が大変

条件さえ揃えばDIY WireGuardでいい。

これはその通りです。

ただし、本当に大変なのは最初の構築ではありません。

その状態を3年、5年と維持することです。

自宅VPN Serverを運用するなら、

• OSのSecurity Patch

• KernelやPackageのUpdate

• WireGuardや関連SoftwareのUpdate

• Router Firmware

• Firewall Rule

• OSのMajor Upgrade

• DDNS

• 回線方式の変化

• Hardware故障

まで継続して面倒を見る必要があります。

Security対応も、常にPackage Managerだけで終わるとは限りません。

使っているOSのRepositoryへ修正版がまだ入っていない。

古いVersionではBackportされない。

依存Libraryだけ先にSecurity Fixが出る。

そんな場合には、LibraryやApplicationを自分で更新したり、場合によってはBuildし直したりすることもあります。

自分でBuildしたComponentを使えば、

どのVersionを入れたのか。
次のSecurity Fixをどう追うのか。
OS Upgrade後も動くのか。

まで自分の運用対象になります。

16. 台数が増えると、自宅VPNではなくInfrastructure運用になる

自宅に1台だけなら、まだ何とかなるかもしれません。

でも、

自宅
  +
実家
  +
別拠点
  +
予備VPN Server
  +
VPS

と増えると事情が変わります。

Patch適用。

動作確認。

再起動。

Firewall変更。

OS Upgrade。

Hardware故障。

そのすべてが台数分増えていきます。

そして個人でやる場合、その作業時間はたいてい夜間や休日です。

「Ansibleで自動化すればいい」という方法もあります。

Package Updateや設定配布などの定型作業には非常に有効です。

ただ、本当に時間を取られるのは、

• ある1台だけOS Upgrade後に起動しない

• Router交換後に特定拠点だけ経路が変わった

• Security Fixで依存Libraryとの互換性が崩れた

• 古いHardwareだけ正常動作しない

といった定型外対応です。

生成AIやAI AgentにLogを読ませる方法もあります。

それでも自宅でAI Agentを動かすなら、

VPN Server
    +
Monitoring
    +
Automation
    +
AI Agent Server

となり、今度は自動化基盤そのものが管理対象になります。

Cloudで動かせば、CredentialやCloud Cost、Network経路など別の運用が増えます。

自動化や生成AIは運用を減らせます。

でも、定型外対応やInfrastructureそのものの保守まで消してくれるわけではありません。

VPNを使いたいだけなのに、VPN Infrastructureを夜間や休日に何年も保守する。

そこまで来ると、目的と手段を一度見直してもいいはずです。

17. 発想を変える。「どうInboundするか」を考えない

ここまで紹介した方法は、技術的にはそれぞれ成立します。

Port Forward。

固定IPv4。

DDNS。

P2P NAT Traversal。

IPv6 Direct。

ただし、基本的には、

どうやってRemoteからHomeへ到達するか

を解決する方法です。

Remote
   ↓
Home Public IPv4 / IPv6
   ↓
Inbound
   ↓
VPN Server

そこで別の考え方があります。

HomeへのInboundそのものを成立条件から外す。

Home ──Outbound──▶ Cloud Hub ◀──Outbound── Remote

Home側から先にCloud Hubへ接続する。

Remote側もCloud Hubへ接続する。

これならRemoteからHomeへ新しいInbound Connectionを作る必要がありません。

ここで初めて、

「Portをどう開けるか」ではなく、「そもそもPortを開ける必要があるのか」

という問いに変わります。

10章で触れた、家庭環境で侵害後のDefenseを積み上げ続ける負担についても、ここにつながります。

自宅VPNのためにInternetへ新しい入口を作らなければ、その入口を守るための運用自体を減らせます。

18. HomeGrid VPNはこのOutbound型を使う

HomeGrid VPNでは、自宅・実家などに置くGridと、Remote側のClientがそれぞれCloud Hubへ接続します。

Home Grid ──Outbound──▶ Cloud Hub ◀──Outbound── Remote

そのためHome側では原則として、

• IPv4 Port Forward

• DDNS

• Remote → Home Public IPv4 Direct

• Remote → Home Global IPv6 Direct

• IPv6 Inbound Rule

を前提にしません。

これは単に、

「設定が楽になる」

というだけではありません。

自宅VPNのためにHome側へ新しいInbound経路を追加する必要がないため、Internetへ直接公開するAttack Surfaceを増やさずに済むという構造上の違いがあります。

もちろん、これですべてのSecurity Riskが消えるわけではありません。

Client端末のSecurity、Credential、LAN側のAccess Controlなどは別途必要です。

Cloud HubもVPN経路上の構成要素です。

それでも、

自宅VPNのためにHome RouterへInbound Portを公開しない

という点は、Direct型とは明確に違います。

19. Free Wi-Fiには自宅IPを直接見せない。でもInternetへは自宅回線から出られる

Direct WireGuardなら、

Free Wi-Fi
    ↓
Home Public IPv4 / IPv6

です。

VPN内部は暗号化されても、VPN接続先としてHome側のAddressが見えます。

HomeGrid VPNでは、

Free Wi-Fi
    ↓
Cloud Hub
    ↓
Home Grid

となります。

Remote側のFree Wi-Fiから見えるVPN接続先はCloud Hub側で、自宅Public IPv4やGlobal IPv6をVPN Tunnelの宛先として直接見せる必要がありません。

では、Web ServiceからもCloud HubのData Center IPに見えるのでしょうか。

そうではありません。

Home GridをInternet Exitとして利用する場合は、

Remote
   ↓
Cloud Hub
   ↓
Home Grid
   ↓
Residential ISP
   ↓
Internet

となります。

ここで重要なのは、

Cloud Hub ≠ Internet Exit

という点です。

Cloud HubはVPN経路上の構成要素ですが、Home GridをExitとして使う場合、Internetへの出口はHome側の家庭用回線です。

つまり、

Free Wi-FiにはHome Public IPをVPN接続先として直接見せない。
その一方で、Internetへは実際にHome側の回線から出る。

という構成にできます。

まとめ：見るべきなのは「接続性・露出・長期運用」の3つ

自宅VPNを考えるとき、今は単に、

「WireGuardが動くか」

だけでは足りません。

見るべきなのは3つです。

接続性。
CGNAT、MAP-E、P2P NAT Traversal、IPv6など、Direct接続を成立させる条件。

露出。
Direct接続によって、Home / OfficeのPublic IPv4やGlobal IPv6をRemote側Networkへ直接見せること。

長期運用。
Security Patch、OS Upgrade、Router、Hardware、複数拠点、定型外障害を何年も維持すること。

これらを一つずつ解決し、管理し続ける方法もあります。

もう一つは、

Home ──Outbound──▶ Cloud Hub ◀──Outbound── Remote

と、HomeへのInboundそのものを成立条件から外す方法です。

HomeGrid VPNは後者の考え方を採用しています。

「自分の回線だとどういう構成になるのか」

「自宅・実家の家庭用回線をInternet Exitにすると、通信はどう流れるのか」

「実際にはどんな機器を置いて、どうセットアップするのか」

が気になったら、公式サイトで仕組みを確認できます。

→ HomeGrid VPN 公式サイト

自宅・実家の家庭用回線をInternet Exitとして使う考え方については、こちらの記事でも詳しく整理しています。

→ 自宅・実家の「家庭用IP」を自分専用のVPN出口にする方法

→ 自宅VPNをDIYできる回線・できない回線｜2026年の日本では何が現実的なのか