海外のFree Wi-Fiで自宅VPNがつながらない？IPv6 DirectとP2P VPNが詰まる理由
海外出張や旅行先のホテルでFree Wi-Fiにつなぐ。
そのまま使うのは少し不安なので、自宅のVPNへ接続し、いつもの自宅回線を経由してInternetへ出たい。
ところが、
自宅では使えていたVPNが、海外のFree Wi-Fiではつながらない。
あるいは、
接続はできるけれど、Remote Desktopや動画が妙に遅い。
こんなことがあります。
原因はWireGuardの設定とは限りません。
特に現在の家庭用回線では、IPv4で自宅へDirect接続できないケースがあります。その場合、次に考えるのがIPv6 DirectやP2P VPNです。
しかし海外のFree Wi-Fiでは、この2つにもそれぞれ別の条件があります。
この記事では、
IPv4で自宅へDirect接続できない環境を前提に、海外のFree Wi-Fiから自宅VPNを使おうとすると何が起きるのか
を整理します。
まず前提：IPv4 Directが使える環境は今回の対象外
従来型の自宅WireGuardは、かなり単純です。
Remote
↓
Home Public IPv4
↓
Port Forward
↓
WireGuard Server自宅にGlobal IPv4があり、RouterでPort Forwardできるなら、この方式は現在でも使えます。
この記事では、この環境は対象外です。
対象にするのは、
IPv4で自宅へDirect Inboundできない家庭用回線
です。
たとえば、
CGNAT
DS-Lite
MAP-EなどのIPv4 over IPv6
二重NAT
マンション側の上位Router
などによって、自宅側へ自由なIPv4 Inbound経路を作れないケースです。
この場合、次の候補は大きく分けて、
IPv6 Direct
または、
Relay / Hubなどの中継経路
になります。
IPv4 / IPv6の両方でDirect Inboundできない場合
ここでいう「Direct Inboundできない」とは、単にRouterの管理画面で手動Port Forwardを設定できないという意味だけではありません。
NAT Traversalなどを含めても、RemoteからHomeまでDirectな通信経路を成立させられない状態
を指します。
この条件なら、
IPv4 Direct
×
IPv6 Direct
×
↓
HomeをDirectなVPN Endpointにできないということになります。
Self-hosted VPNのDirect接続は使えません。
P2P VPNでもDirect Peer接続は成立しないため、利用するならRelay経由になります。
DDNSやSTUNも、この条件そのものを解決するものではありません。
DDNSは現在のIP Addressを名前へ追従させる仕組みです。
STUNは外から自分がどのAddress / Portとして見えているかを調べたり、NAT Traversalを助けたりする仕組みです。
外部からHomeまでDirectな経路そのものを作れない環境で、それを魔法のように通す仕組みではありません。
IPv6 Directが詰まる理由
IPv4 Inboundが使えなくても、自宅側でIPv6 Inboundを利用できるなら、IPv6 Directという選択肢があります。
Remote
↓ IPv6
Home Global IPv6
↓
WireGuardIPv6では、一般的なIPv4 NATのようなPort Forwardは通常必要ありません。
ただし、
「NATのPort Forwardが不要」＝「Inbound設定が不要」
ではありません。
実際の経路は、
Internet
↓
Home Global IPv6
↓
Router IPv6 Firewall
↓
Server Firewall
↓
WireGuardです。
ISPやRouterの仕様上IPv6 Inboundを許可できなければ、ここでIPv6 Directも使えなくなります。
海外Free Wi-FiがIPv4 onlyなら、HomeがIPv6でも届かない
IPv6 Directには、もう一つ重要な条件があります。
接続元側にもIPv6が必要です。
自宅にGlobal IPv6があり、IPv6 Inboundも正しく設定できていたとしても、ホテルやカフェのFree Wi-FiがIPv4 onlyなら、
Hotel Free Wi-Fi
│
│ IPv4 only
▼
Internet
×
Home Global IPv6となります。
Home側だけIPv6に対応していてもDirect接続できません。
Mobile / eSIMへ逃げると、今度はギガを消費する
Mobile回線やTetheringではIPv6を利用できる場合があります。
その場合、
Laptop
↓
Mobile / eSIM
↓
IPv6
↓
Home WireGuardで接続できる可能性があります。
しかし海外では、これが別の問題になります。
プリペイドSIMやeSIMを使っている場合、Remote Desktop、NASへのアクセス、動画などの通信量をそのままMobile Dataで消費します。
つまり、
ホテルにFree Wi-Fiがあるのに、自宅VPNを使うためだけにeSIMのギガを消費する
という状況です。
IPv6そのものがギガを余計に消費するわけではありません。
Free Wi-Fi側でIPv6 Directを使えないため、Mobile回線へ切り替える必要が出る
ことが問題です。
IPv6 Prefixが変わるならDDNSも必要になる
IPv6 DirectにはAddress管理の問題もあります。
ISPから割り当てられるIPv6 Prefixが変わる環境では、WireGuard ServerのGlobal IPv6も変わる可能性があります。
Before
2001:db8:aaaa:...
↓ Prefix change
After
2001:db8:bbbb:...Remote側へ固定IPv6を書いただけでは、変更後に接続できなくなります。
その場合は、IPv6に対応したDDNSなどを使ってAAAA Recordを更新する運用も必要です。
つまりIPv6 Directには、
Home側のGlobal IPv6
ISP側のIPv6到達性
RouterのIPv6 Inbound Rule
Server Firewall
Remote側のIPv6接続性
Prefix変更への対応
必要に応じてDDNS
といった条件があります。
「IPv6ならPort Forwardがないから簡単」ではありません。
Direct VPNではHome Public IPが接続先として見える
WireGuardはVPN内部の通信を暗号化します。
しかし、VPN PacketそのものにもDestinationは必要です。
IPv6 Directなら、
Hotel Wi-Fi
↓
Laptop
↓
Encrypted VPN packets
↓
Home Public IPv6となります。
VPNの中身は暗号化されています。
一方で、利用しているWi-Fiやその上流Networkからは、Home Public IPv6へ通信していること自体は観測され得ます。
暗号化と、接続先IPを隠すことは別問題です。
P2P VPNが詰まる理由
そこで、
「Self-hosted WireGuardが難しいならP2P VPNを使えばいいのでは？」
となります。
P2P VPNは便利です。
STUNやNAT Traversalなどを使ってDirect Peer接続を試し、条件が合えば、
Remote ───────── Home
Directという経路を作れます。
しかし、この記事の前提である、
IPv4 / IPv6ともHomeへのDirect経路を成立させられない環境
ではDirect Peer接続は使えません。
その場合、P2P VPNではDERPのようなRelay経路を利用することになります。
Home ──Outbound──→ Relay ←──Outbound── RemoteHomeをInternet-facingなVPN Endpointにしなくてもつながる。
これは大きなメリットです。
ただし、ここから別の問題が始まります。
P2P VPNは、VPN接続前に認証・シグナリングが必要
TailscaleのようなControl Plane型のP2P VPNでは、いきなりPeer同士が通信を始めるわけではありません。
まずVPNの外側で、
Normal Internet
↓
Identity / Control Plane
↓
User / Device Authentication
↓
Peer / Key / Policy情報
↓
Direct / Relayの経路決定
↓
VPN Overlayという前段処理があります。
たとえば、
User Identity
Device Registration
Node Identity
Peer情報
Public Key
Access Policy
Direct接続候補
Relay情報
などを扱います。
重要なのは、
これらがVPN接続前に行われる
ことです。
VPNを使いたいほど信用しにくいWi-Fiで、VPNの前に認証する
海外のFree Wi-Fiでは、ここが少し皮肉な構造になります。
ホテルのWi-Fiを信用しにくいからVPNを使いたい。
ところが初回登録や再認証が必要になると、
そのVPNがまだ成立していないFree Wi-Fi上で、VPNを成立させるための認証を先に行う
ことになります。
もちろん、HTTPS/TLSが正しく実装され、Certificate Validationも正しく行われていれば、Free Wi-Fi上の第三者がIDやTokenをそのまま盗み見るのは簡単ではありません。
DNS Hijackだけで正しいTLS証明書まで突破できるわけでもありません。
ただし、
「HTTPSだから認証フロー全体が安全」とは限りません。
たとえばFree Wi-Fiでは、
偽Captive Portalへの誘導
本物そっくりのログイン画面
OAuth / OIDC認証を装ったフィッシング
SessionやTokenを狙う攻撃
DNSを偽装して別サイトへ誘導する試み
なども考えられます。
攻撃者は必ずしもTLSそのものを破る必要はありません。
ユーザーを正規の認証フローから外す
という方向から狙うこともできます。
生成AIによって、ホテル名や言語、利用サービスに合わせた自然な偽ログイン画面や案内文を作るコストも以前より下がっています。
つまり問題は、
VPN Data Planeが強固でも、そのVPNを成立させる前のIdentity / Control Planeは別のAttack Surface
だということです。
P2P VPNの初回登録・再認証は出発前に済ませる
既に登録済みのDeviceなら、ホテルWi-Fiへ接続するたびに毎回IDやPasswordを入力するとは限りません。
だからこそ、海外へ出る前に、
自宅などの信用できるネットワークで
Device登録
必要な再認証
接続確認
Relay時の動作確認
まで済ませておく方が安心です。
Free Wi-Fiへ到着してから、
「VPNを使いたいのに、そのVPNを使うためにまずログインし直さないといけない」
という状況を避けられます。
DirectできなければRelay経由になる
次は性能の問題です。
この記事の前提ではHomeへのDirect経路を作れないので、P2P VPNを利用する場合はRelay経由になります。
Remote ─→ Relay ─→ Home接続自体は成立します。
しかし、
Connectedになったことと、Directと同じ性能が出ることは別です。
Relayを経由すれば、
Relayまでの距離
Relayの混雑
Relayの帯域
RelayまでのInternet経路
Relayサービスの可用性
などに通信品質が依存します。
DERPのようなTCP/TLS系Relayでは性能特性も変わる
P2P VPNのRelayには、Firewallを通過しやすくするためTCP/TLS系Transportを利用する実装があります。
この場合、Peer間のVPN通信自体がEnd-to-Endで暗号化されていても、外側のTransportはDirect UDPとは異なります。
概念的には、
Application traffic
↓
VPN encrypted traffic
↓
TCP / TLS Relay transport
↓
Shared Relayとなります。
内側でもTCPを使う通信を、さらにTCPベースのRelay経由で運ぶと、パケットロス時の再送や輻輳制御が重なり、遅延やThroughput低下が大きくなる場合があります。
いわゆるTCP-in-TCPの問題です。
特に、
Remote Desktop
SCP / SFTPなどの大容量転送
NASアクセス
動画
長時間の高帯域通信
ではDirectとの差が出やすくなります。
文字中心のSSHなら十分使える場面もあります。
しかし、
Directできず、常時Relayをデータ経路として使うことが確定している環境で、大容量・低遅延用途まで共用Relayへ依存する構成は積極的にはおすすめしにくい
というのが現実です。
※すべてのRelayがTCPベースという意味ではありません。Transportの実装によって特性は異なります。
共用Relayで「つながる」と「常用したい」は別
P2P VPNのRelayは、多くのユーザーが共同で利用するサービス側のインフラであることがあります。
これは、
他の利用者にVPNの中身を読まれる
という意味ではありません。
Peer間でEnd-to-End暗号化されたPacketをRelayが中継する設計もできます。
問題は、
通信品質を共用Relayインフラへ依存する
ことです。
RelayはDirectできないNetworkでも接続を成立させるという意味では非常に優秀です。
ただ、
そのRelayを、自宅VPNの常用データ経路として選びたいか？
は別の問題です。
海外Free Wi-Fiでは、この問題が重なりやすい
ここまでをまとめると、
海外 Hotel / Cafe Free Wi-Fi
│
├─ IPv4 only
│ ↓
│ IPv6 Direct ×
│
├─ HomeへのDirect経路なし
│ ↓
│ P2P Direct ×
│
└─ P2P Relay
↓
Relay性能に依存さらにP2P VPNでは、その前に、
VPN接続前
↓
Identity / Control Plane
↓
Authentication / Signaling
↓
VPNという前段があります。
Free Wi-Fi側でControl PlaneやRelayへの通信自体が遮断されていれば、Relayへ迂回する以前にVPNそのものを成立させられません。
Directできないなら、最初からDirectを前提にしない
ここまで来ると、考え方を変える方法もあります。
Direct型の自宅VPNでは、
Remote
↓
Home Public IP
↓
Homeという経路を成立させようとしています。
しかし、
そもそもHomeをInternet-facingなVPN Endpointにしない
という設計もできます。
Home側から先にCloud HubへOutbound接続しておきます。
Home ──Outbound──→ Cloud Hub
Remote ─Outbound──→ Cloud HubこうすればHome側で、
IPv4 Port Forward
IPv6 Inbound Rule
DDNSによるHome Endpoint追跡
Remote → Home Public IPへのDirect接続
P2P Direct成立のためのNAT Traversal
を前提にする必要がありません。
この条件ならHomeGrid VPNの設計の方が素直
HomeGrid VPNは、Home側とRemote側がCloud Hubへ接続するHub & Spoke型です。
HomeをInternet Exitとして利用する場合、
Remote
↓
Cloud Hub
↓
Home
↓
Residential ISP
↓
Internetとなります。
ここで重要なのは、
Cloud Hub ≠ Internet Exit
という点です。
Cloud HubはVPN経路上の構成要素ですが、Internetへの出口をHomeにすれば、接続先サービスから見える出口はHome側のPublic IPです。
つまり、
HomeをInternet Exitにすることと、HomeをInternet-facingなVPN Endpointにすることを分離する
という設計です。
P2P Directを成立させるような、VPN接続前の複雑なControl Planeを前提にしない
今回の海外Free Wi-Fiという条件では、ここも違いになります。
HomeGrid VPNは、P2P Directを成立させるような、VPN接続前の複雑な認証・シグナリングを前提にしていません。
最初からCloud HubをVPN経路上の構成要素とするHub & Spoke型なので、
Peer Discovery
STUNを使ったDirect候補探索
NAT Traversal
Direct / Relayの動的な経路切り替え
を前提にしません。
そのため、
VPNを使いたいほど信用しにくいFree Wi-Fi上で、P2P Directを成立させるための複雑な前処理を先に行う
という種類の問題を避けやすくなります。
また、Direct成立条件やRelayへの切り替わりを追いかける必要がないため、運用もシンプルになります。
これは「Control Planeが存在しない」という意味ではありません。
HomeGrid VPNにもDashboard、Activation、Cloud Hubなどの構成要素と信頼境界があります。
違いは、
VPNの外側でP2P Directを成立させるための複雑なControl Planeを必要としない
ことです。
HomeGrid VPNのOutbound Onlyは、検閲回避という意味ではない
HomeGrid VPNのOutbound Onlyは、
Home側にInternet-facingなInbound Endpointを作らなくてよい
という設計です。
Home側からCloud HubへOutboundでVPN経路を作るため、IPv4 Port ForwardやIPv6 Inbound Ruleを前提にしません。
ただし、これは、
検閲やFirewallからVPN通信そのものを隠す機能
ではありません。
ホテルや企業Network、あるいは国・地域のネットワーク制限によって、RemoteやHomeからCloud Hubへの必要なOutbound通信そのものが遮断されていれば、VPNは成立しません。
また、暗号化されているからといって、VPNを利用していること自体まで見えなくなるわけでもありません。
外側のNetworkからは、接続先IP、通信量、接続時間などが観測される可能性があります。
つまり、
Inbound不要と、検閲やFirewallを回避できることは別問題
です。
Cloud Hubへの経路が途中で切れたら？
もう一つ分けて考えたいのが、
「VPNが使えなくなること」と「TrafficがVPN外へ漏れること」
です。
Cloud Hubへの経路が途中で利用できなくなれば、当然そのVPN経路では通信できなくなります。
ただし、HomeGrid VPNではKill Switchを利用し、VPN経路が利用できない場合に通常のInternet経路へTrafficを自動的に逃がさない構成を取れます。
VPN path available
↓
Traffic → VPN
VPN path unavailable
↓
Traffic → BLOCK
通常回線へ自動Fallbackしないそのため、
接続が切れたことと、Trafficが通常回線へ漏れることは同じではありません。
WireGuardはUDPベースなので、TCPのような「相手とのConnection Sessionが常時成立していること」を前提にしたTransportではありません。
ただし、Traffic漏洩を防ぐ本質はUDPであることそのものではなく、
RoutingとKill Switchによって、VPN経路が使えないときに通常回線へFallbackさせないこと
です。
海外へ出る前に確認しておきたいこと
海外で自宅VPNを使うなら、出発前に一度確認しておくのがおすすめです。
まず自宅側。
IPv4 Direct Inboundできるか
IPv6 Direct Inboundできるか
IPv6 Prefixが変わるか
IPv6 DDNSが必要か
Router / Server Firewallはどうなっているか
P2P VPNを利用するなら、
DirectなのかRelayなのか
Relay時のRemote Desktopは実用になるか
大容量転送の速度は問題ないか
Device登録や再認証が必要になっていないか
も確認しておきます。
特に初回登録や再認証は、可能なら自宅などの信用できるネットワークで済ませておく方がよいでしょう。
まとめ
IPv4 Directが使えない家庭用回線では、自宅VPNの構成は一気に複雑になります。
IPv6 DirectならIPv4 Port Forwardは不要になりますが、
Home側のIPv6 InboundとRemote側のIPv6接続性
が必要です。
海外Free Wi-FiがIPv4 onlyなら、それだけで使えません。
P2P VPNならDirectできない環境でもRelay経由で通信できます。
しかし今回のようにIPv4 / IPv6ともDirect経路を作れないなら、P2P Directは使えず、常時Relay経由になります。
さらにP2P VPNでは、
VPN接続前のIdentity / Control Planeによる認証・シグナリング
という別の前提もあります。
そしてRelayでConnectedになっても、Directと同じ性能になるとは限りません。
そこで、
Direct Inboundを何とか成立させるのではなく、最初からHome側からOutboundでVPN経路を作る
という考え方があります。
今回のように、
海外のFree Wi-Fiから、自宅の家庭用回線をInternet Exitとして使いたい
のであれば、P2P Direct成立やRelayへのフォールバックを前提にするより、HomeGrid VPNのように最初からOutbound型のHub & Spokeとして設計された構成の方が、仕組みとして素直で運用もしやすくなります。
HomeGrid VPNのOutbound Onlyは、検閲を回避したりVPN通信そのものを隠したりするための仕組みではありません。
一方で、
Home側にInternet-facingなInbound Endpointを置かず、P2P Directを成立させるためのVPN接続前の複雑なControl Planeにも依存しない
という設計上の違いがあります。
大事なのは、
「VPNにつながったか」だけではなく、その前に何を認証し、どの経路を使い、どこを信頼して通信しているのか
まで見ることです。
