「IPv6ならポート開放不要」は本当？ 自宅WireGuardで見落としやすいIPv6 Firewallの話
「IPv4でポート開放できないなら、IPv6を使えばいい」
自宅にWireGuard Serverを立てようとして、CGNATやIPv4 over IPv6にぶつかると、一度はこの方法を考えると思います。
実際、IPv6なら解決できるケースがあります。
IPv4のようにNAT越えやPort Forwardをするのではなく、WireGuard Server自身が持つグローバルIPv6アドレスへ直接接続できるからです。
ただし、ここで一つ勘違いしやすいことがあります。
グローバルIPv6アドレスがある
＝
インターネットからWireGuard Serverへ接続できる
ではありません。
その間には、
ISP側のIPv6ネットワーク
ルーターのIPv6 Firewall
Server自身のFirewall
があります。
さらに、ルーターによっては「IPv6パススルー」という、扱いに注意したい機能もあります。
今回は、
「IPv6は使えているのに、なぜ外からWireGuardへつながらないのか？」
を実際に切り分けながら、IPv6で自宅VPNを公開するときに確認したいポイントを整理します。
先に確認するポイント
IPv6で自宅WireGuardへ接続するなら、まず次の順番で確認すると切り分けやすくなります。
WireGuard ServerにグローバルIPv6があるか
ISP側から自宅までIPv6 Inboundが到達できるか
ルーターで必要なIPv6 Inboundだけを許可できるか
IPv6 Pass-throughでLAN側を必要以上に露出していないか
WireGuard Serverまで実際にUDPパケットが届いているか
外出先から自宅のIPv6 Endpointへ到達できるか
最後の6番は意外と重要です。
自宅側が完璧にIPv6対応していても、接続する側から自宅のIPv6へ到達できなければ、VPNトンネルそのものを張れません。
IPv4の「ポート開放」とIPv6の「Inbound許可」は少し違う
まず、IPv4の典型的な自宅VPNを考えてみます。
Internet
↓
Public IPv4
↓
Router
↓ Port Forward
WireGuard Server家庭内のWireGuard Serverは、通常プライベートIPv4を持っています。
そのため、ルーターのPublic IPv4に届いたUDP通信を、
UDP 51820 → WireGuard Server
のように転送します。
これが一般的な「ポート開放」です。
IPv6では構造が変わります。
WireGuard Server自身がグローバルIPv6アドレスを持てるため、
Internet
↓
Global IPv6
↓
WireGuard Serverのように、NATによるIPv4アドレス変換を前提としない通信が可能です。
それなら、
「IPv6ならポート開放はいらない」
という説明も間違いではありません。
ただし、この図には重要なものが抜けています。
IPv6でもFirewallは残る
実際の経路は、もっとこう考えた方が分かりやすいです。
Internet
↓
ISP IPv6 Network
↓
Router IPv6 Firewall
↓
Server Firewall
↓
WireGuardIPv6アドレスがインターネットからルーティング可能だからといって、新しいInbound通信を何でも通す必要はありません。
家庭用ルーターでは、IPv6でも外部から開始された通信をStateful Firewallなどで遮断していることがあります。
その場合、
IPv6は普通に使える。
Webも見られる。
WireGuard ServerにもグローバルIPv6がある。
それでも、
外からWireGuardにはつながらない
という状態になります。
WireGuardの設定を何度見直しても直らないのは、このためです。
まず「グローバルIPv6があるか」を確認する
最初に確認したいのは、WireGuard Server自身のIPv6アドレスです。
Linuxなら、たとえば、
ip -6 addrで確認できます。
ここで重要なのは、
IPv6アドレスが表示されるか
だけではありません。
fe80::から始まるアドレスはリンクローカルアドレスです。
同じリンク内で利用するためのもので、そのままインターネットからWireGuardへ接続するためのアドレスには使えません。
また、fc00::/7のULA（Unique Local Address。一般にはfd00::/8側が使われます）も、ローカルネットワーク内で利用するためのアドレスで、グローバルIPv6ではありません。
つまり、
「IPv6アドレスが表示された」だけでは判断できません。
WireGuard Serverに、インターネットからルーティング可能なグローバルIPv6アドレスが割り当てられているかを確認します。
次にルーターの「IPv6 Firewall」を見る
ここが一番のポイントです。
ルーターの管理画面を開き、
IPv6 Firewall
IPv6 Filter
IPv6 Inbound
IPv6 Access Control
などの項目を探します。
メーカーによって名前は違います。
確認したいのは、
IPv6 Firewallがあるか
だけではありません。
さらに重要なのは、
必要なInbound通信だけを許可できるか
です。
たとえば、
Internet
↓
IPv6 Firewall
↓
UDP 51820 ONLY
↓
WireGuard Serverのようなルールを設定できるか。
これなら、WireGuardに必要な通信だけを許可できます。
逆に、
Firewall ON / OFF
しか選べない場合は注意が必要です。
WireGuardを使いたいからといって、IPv6 Firewall全体をOFFにするのは別の話になってきます。
「IPv6パススルー」を安易にONにするのは注意
ルーターによっては、
IPv6 Pass-through
のような設定があります。
名前だけを見ると、
「これをONにすればIPv6で直接つながるのでは？」
と思うかもしれません。
ただし、ここは注意が必要です。
IPv6では、LAN内の端末自身がグローバルIPv6アドレスを持つことがあります。
ルーターの実装によっては、IPv6パススルーを有効にすることで、ルーターのIPv6 FirewallによるInbound制御を迂回したり、LAN側へのIPv6通信を広く通したりする構成になる場合があります。
すると、
IPv6 Network
↓
Home Router
↓
IPv6 Pass-through
↓
Home LANとなり、WireGuard Serverだけではなく、LAN内の他のIPv6端末への到達可能性まで変わることがあります。
これは、
UDP 51820 → WireGuard Server
だけを許可するIPv6 Firewall Ruleとは意味が違います。
WireGuardの1ポートだけを使いたかったのに、設定によってはLAN側へのIPv6 Inboundを必要以上に広げてしまう可能性があります。
そのため、
「WireGuardがつながらないから、とりあえずIPv6パススルーをON」
とするのは避けたいところです。
IPv6 Pass-throughという名称でも、実際の動作はルーターによって異なります。
有効にする前に、
IPv6 Firewallは引き続き機能するのか
LAN側への新規Inbound通信をどこまで通すのか
端末単位・ポート単位で制限できるのか
を、その機種の仕様で確認した方が安全です。
ISP側でFirewallされていれば安全？
ここでもう一つ考えたいのが、ルーターより上流です。
IPv6の経路は、
Internet
↓
ISP IPv6 Network
↓
Home Router
↓
LANです。
ISPやIPv6の提供方式によっては、上流側でInbound通信に何らかの制限やフィルタリングが行われる場合もあります。
そのため、
IPv6パススルーをONにした
＝
必ずインターネット全体からLANへ到達できる
と一律に断定することもできません。
しかし、逆も重要です。
「ISP側でたぶん止めてくれているから大丈夫」
と考えて、自宅LANのFirewall代わりにするべきでもありません。
ISP側のネットワーク設計やフィルタリング方針は、自分が管理しているFirewallではないからです。
ISP内の別ユーザーからはどうなる？
さらに細かく考えると、
Internetから自宅
だけを考えればいいとも限りません。
概念的には、
Another Subscriber
↓
ISP IPv6 Network
↓
Your IPv6 Prefix
↓
Home Router
↓
LANという経路も考えられます。
仮にISPが外部Internetから加入者へのInboundを何らかの方法で制限していたとしても、
加入者A → ISP内部 → 加入者B
まで同じポリシーで遮断されているとは限りません。
実際に加入者間通信が可能かどうかは、ISPやIPv6提供方式の実装によって異なります。
確認したい場合は、可能であれば同じISPの別契約回線など、確認したい経路から自宅のグローバルIPv6アドレスへ実際に通信を送る方法があります。
WireGuard Server側で後述するtcpdumpを動かしておけば、その経路からUDPパケットが到達しているか確認できます。
ただし、単に別のISPやモバイル回線から試すだけでは、
「同じISP内の加入者間通信が許可されているか」
の確認にはならない点には注意が必要です。
だからこそ、
「ISP側にFirewallがあるらしい」
という情報だけを、自宅LANのセキュリティ境界として期待するのは避けた方が分かりやすいです。
自分で管理できるIPv6 Firewallを残し、
必要な通信だけを許可する
方が、セキュリティ境界を把握しやすくなります。
tcpdumpで「本当に届いているか」を見る
設定画面だけを見ていても、どこで止まっているのか分からないことがあります。
WireGuardがUDP 51820で待ち受けているなら、Server側で、
sudo tcpdump -ni any 'ip6 and udp port 51820'を実行します。
その状態で、自宅Wi-Fiではない別のIPv6対応ネットワークからWireGuardへ接続してみます。
結果は大きく2つに分かれます。
パケットが見える
IPv6の経路はWireGuard Serverまで到達しています。
この場合は、
WireGuardの鍵
ListenPort
AllowedIPs
Server側Firewall
ルーティング
などを確認する段階です。
何も見えない
WireGuardの設定より前を疑います。
たとえば、
ルーターのIPv6 Firewall
IPv6 Inbound Rule
IPv6アドレス
ISP側のIPv6ネットワーク
上流側のフィルタリング
などです。
ここで注意したいのは、
tcpdumpで何も見えない
＝
自宅ルーターが落としている
とは断定できないことです。
その前のISP側ですでに止まっている可能性もあります。
大事なのは、
「WireGuardが応答しない」
と
「WireGuardまでパケットが届いていない」
を分けることです。
自宅がIPv6でも、外出先からIPv6で到達できなければつながらない
IPv6で自宅WireGuardを公開する場合、もう一つ大きな条件があります。
接続する側からも、自宅のIPv6 Endpointへ到達できる必要がある
ということです。
たとえば自宅側が、
Global IPv6
↓
IPv6 Firewall
↓ UDP 51820
WireGuard Serverまで完璧に設定されていたとします。
それでも、ホテルなどの接続元からIPv6を利用できなければ、
Hotel
IPv4 only
↓
×
Home IPv6 Endpointとなります。
自宅側にグローバルIPv6があるだけでは解決しません。
モバイル回線、ホテル、カフェ、海外のネットワークなど、利用する場所によってIPv6接続性は異なります。
つまりIPv6による自宅VPNは、
「自宅がIPv6対応しているか」
だけではなく、
「実際に使う場所から、自宅のIPv6 Endpointまで到達できるか」
まで含めて成立する方法です。
モバイル回線ならIPv6でつながる場合もある。でも通信量は？
ホテルやカフェのWi-FiからIPv6を利用できなくても、スマートフォンのモバイル回線がIPv6に対応していれば、テザリング経由で自宅WireGuardのIPv6 Endpointへ接続できる場合があります。
Laptop
↓
Tethering
↓
Mobile IPv6
↓
Home IPv6
↓
WireGuardこれなら、
「ホテルWi-FiはIPv4 onlyだから自宅IPv6へつながらない」
という問題を回避できる場合があります。
ただし、別の問題が出てきます。
モバイル回線のデータ容量を消費します。
VPNトンネルを確立する通信だけではありません。
その後、
Laptop
↓
Mobile Network
↓
WireGuard
↓
Home
↓
Internetと自宅をExit Nodeとして使えば、そのVPNを通るInternet通信もモバイル回線上を流れます。
動画、ファイル転送、OSアップデート、クラウド同期などを行えば、その分もデータ容量を消費します。
国内の大容量・定額プランなら、それほど問題にならない場合もあるでしょう。
しかし、特に気になるのが海外ローミングです。
海外のホテルで、
ホテルWi-Fiならデータ容量を気にせず使える。
でもホテルWi-FiはIPv4 only。
自宅WireGuardはIPv6でしか待ち受けていない。
という状況を考えてみます。
モバイル回線へ切り替えればIPv6で接続できるかもしれません。
しかし、それでは海外ローミングやSIM/eSIMのデータ容量を消費します。
Hotel Wi-Fi
IPv4 only
↓
×
Home IPv6
Mobile / Roaming
IPv6 available
↓
○
Home IPv6
↓
Mobile data used「ギガを節約するためにホテルWi-Fiを使いたい」
という場面では、モバイル回線へ切り替えることでIPv6 Directを成立させる方法は、目的と噛み合わないことがあります。
つまりIPv6 Directによる自宅VPNでは、自宅側だけでなく、
そのとき使っているアクセス回線
まで接続条件の一部になります。
IPv6でVPNにつないでも、IPv4サイトが使えないという意味ではない
ここは混同しやすいので、分けて考えます。
先ほど問題にしたのは、
VPNトンネルを張る前の入口
です。
Remote
↓ IPv6
Home WireGuard Endpointこの経路にIPv6到達性が必要、という話です。
いったんWireGuardトンネルが成立した後、その中を流す通信までIPv6だけに限定されるわけではありません。
たとえば、
Remote
│
│ WireGuard over IPv6
▼
Home WireGuard Server
│
│ IPv4 forwarding / NAT
▼
Home Router
│
▼
IPv4 Internetという構成も可能です。
つまり、
WireGuardの外側：IPv6
WireGuard内のInternet通信：IPv4
という構成は成立します。
自宅をExit Nodeとして使う場合、接続後のIPv4通信を自宅回線のIPv4経路からInternetへ出すこともできます。
ここで必ずNAT64を使う、という意味でもありません。
NAT64は一般に、
IPv6-only Client → IPv4-only Destination
をIPv6/IPv4間で変換する仕組みです。
WireGuard EndpointへIPv6で接続したというだけで、家庭用ルーターによるNAT64が必要になるわけではありません。
したがって、
「外出先がIPv4 onlyだと困る」
というのは、
自宅WireGuardのIPv6 Endpointへ最初のVPN接続を張れない
という入口の問題です。
VPN接続後にIPv4のWebサイトへアクセスできるかどうかとは、別の問題です。
IPv6では「NATによる副次的な壁」がなくなる
ここはセキュリティ上、特に注意したいところです。
典型的な家庭用IPv4では、
Internet
↓
Router / NAT
↓
Private IPv4という構成になっています。
Port Forwardなどを設定しない限り、インターネット側から家庭内端末へ新しい通信をそのまま開始することは通常できません。
NATはFirewallそのものではありませんが、結果として外部から直接到達しにくい構造になっています。
IPv6ではNATを前提にしません。
そのため、グローバルIPv6アドレスを持つLAN端末については、
どのInbound通信をFirewallで許可するか
を明示的に考える必要があります。
WireGuard用UDPだけを適切に許可すること自体は、普通の構成です。
ただし、
「つながらないからIPv6 Firewallを全部OFF」
「IPv6パススルーにして、あとはISP側に任せる」
という解決方法は別です。
ルーター側だけでなく、WireGuard Server自身のOS Firewallも含めて必要な通信だけを許可する方が、どこがセキュリティ境界なのか分かりやすくなります。
では、IPv6を使えば自宅VPN問題は解決？
条件が揃えば、解決できます。
たとえば、
WireGuard ServerにグローバルIPv6がある
↓
ルーターで必要なIPv6 Inbound Ruleを設定できる
↓
上流側でその通信が遮断されていない
↓
外出先から自宅IPv6へ到達できる
↓
UDPパケットがServerまで届く
という環境なら、IPv4のPort Forwardに依存せずWireGuardへ接続できます。
CGNATなどでIPv4 Inboundが難しい環境では、有力な選択肢です。
なので、
「IPv6では自宅VPNを作れない」
という話ではありません。
自分でFirewallやネットワークを管理できるなら、十分に検討できる方法です。
ただし、ここで一つ残るものがあります。
IPv6はPort Forwardをなくせても、「Inbound」までなくすわけではない
ここが今回の一番重要なところです。
IPv4では、
Internet
↓
Port Forward
↓
WireGuardでした。
IPv6では、
Internet
↓
IPv6 Firewall
↓ ALLOW UDP
WireGuardにできます。
NATによるPort Forwardはなくなりました。
しかし、どちらも基本的には、
外部から自宅へ新しい通信を到達させる
という設計です。
つまり、
IPv6は「ポート開放できない」を解決できることがある。
でも「Inboundが必要」という前提までなくなるわけではない。
そして、
「IPv6ならポート開放不要」
と
「IPv6なら何も開放しなくていい」
は、まったく別の話です。
では、IPv4でもIPv6でもInboundを作らない方法は？
ここで発想を逆にしてみます。
外出先から自宅へ接続するのではなく、
自宅側から先に外へ接続しておく
方法です。
従来型は、
Remote
↓
Internet
↓
Homeです。
これを、
Home → Hub ← Remoteにします。
自宅側はInternetから新しい接続が来るのを待ちません。
自分からHubへOutbound接続を確立します。
Remote側も同じHubへ接続します。
この構成なら、自宅側でInternetからの新規Inbound接続を受け付けることを前提にしなくて済みます。
さらに、
Remote側から自宅のIPv6 Endpointへ直接到達すること
も前提にしません。
たとえばホテルWi-FiがIPv4しか使えなくても、
そのネットワークからHubへ必要なOutbound通信ができる
のであれば、自宅IPv6へのDirect接続とは別の経路を作れます。
つまり、
「ホテルWi-FiではIPv6がないから、モバイル回線へ切り替える」
ことを前提にしない構成にできます。
HomeGrid VPNはIPv4 / IPv6のInboundを前提にしない
HomeGrid VPNは、このOutbound型の構成を採用しています。
自宅側のApplianceからCloud HubへWireGuard UDPで接続を確立し、外出先の端末もHubへ接続します。
構成としては、
Home Appliance
↓
Outbound
↓
Cloud Hub
↑
Outbound
↑
Remote Deviceとなります。
そのため自宅側では、
IPv4 Port Forward
IPv6 Inbound Rule
DDNS
を前提にしません。
また、Remote Deviceから自宅のグローバルIPv6アドレスへDirect接続することも前提にしません。
これは、
「IPv6より安全」
という意味ではありません。
設計思想が違います。
自分でIPv6 WireGuard Serverを公開する場合は、
必要なInboundだけをどう安全に許可するか
を考える。
HomeGrid VPNでは、
そもそも自宅側に新しいInboundを作らない
という方向から同じ問題を考えます。
IPv6が使えるならIPv6。Inboundを持ちたくないなら別の構成
自宅WireGuardがIPv4でつながらないとき、
「IPv6ならどうだろう？」
と考えるのは正しい方向です。
実際、IPv6によってCGNATやIPv4 Port Forwardの問題を回避できる場合があります。
そのとき確認したいのは、
グローバルIPv6があるか
↓
ISP側で通信が到達可能か
↓
IPv6 Inbound Ruleを設定できるか
↓
外出先から自宅IPv6へ到達できるか
↓
UDPパケットがServerまで届いているか
↓
必要な通信だけを安全に許可できているか
です。
IPv6パススルーを使う場合も、
どこまで通信を通す設定なのか
を理解してから使う必要があります。
そして実際に外で使うことまで考えるなら、
ホテルやカフェのWi-FiにIPv6がないときどうするか
も無視できません。
モバイル回線やテザリングへ切り替えれば接続できる場合があります。
しかし海外ローミングや容量制限のあるSIM/eSIMでは、今度はデータ容量を気にする必要があります。
そこで、もう一つの選択肢として、
そもそも自宅へのInboundや、自宅IPv6へのDirect到達を必要としない構成にする
という方法があります。
IPv4かIPv6か。
Port Forwardできるかできないか。
それだけでなく、
「自宅側でInboundを待ち受ける設計にするのか」
「接続元から自宅へDirectに到達できることを前提にするのか」
まで考えると、自宅VPNの選択肢はもう少し広がります。
WireGuardがLAN内では動くのに外からつながらない場合は、IPv6だけでなくCGNAT、IPv4 over IPv6、二重NATなども含めて経路を切り分ける必要があります。
