
ポート開放したのにWireGuardが外からつながらない。まず「回線」を疑ってみる
追記:ポート開放に頼らず自宅VPNを作る方法
「原因は分かった。でも、回線やルーターの設定とこれ以上格闘したくない」という方向けに、ポート開放・固定IPv4・DDNSなしで、自宅VPNを約10分で用意する方法をこちらにまとめました。
→ [自宅VPNを作ろうとして「詰んだ」人へ。ポート開放できない回線でも約10分で使える方法]
自宅にWireGuardを構築した。
LAN内ではつながる。
ルーターのポート開放も設定した。
DDNSも設定した。
それなのに、スマホをWi-Fiからモバイル回線に切り替えた途端につながらない。
こうなると、
「WireGuardの設定を間違えた?」
と考えたくなります。
もちろん、秘密鍵やAllowedIPs、ListenPortなどの設定ミスもあり得ます。
しかし、
LAN内では動くのに、外からは一度もHandshakeしない
のであれば、WireGuardより手前で通信が止まっている可能性があります。
特に日本の家庭用インターネットは、
Public IPv4
CGNAT
MAP-E系
DS-Lite系
マンション一括型
二重NAT
IPv6 IPoE
など、回線によって外部からの到達条件がかなり違います。
今は、
「ルーターでポート開放した=インターネットから自宅へ到達できる」
とは限りません。
今回はWireGuardの設定を何度も書き換える前に確認したいポイントを、順番に整理します。
1. まず「外から自宅までパケットが届く回線なのか」を確認する
最初に見るのはWireGuardではありません。
自宅回線です。
昔ながらのPublic IPv4なら、構成は比較的単純です。
Internet
↓
Public IPv4
↓
Router
↓
WireGuard Server
ルーターがインターネットとの境界にあり、WireGuard用のUDPポートを適切に転送できれば、外部からサーバーへ到達できる構成を作れます。
ところが現在は、必ずしもこうなっていません。
たとえばCGNATなら、
Internet
↓
ISP側NAT
↓
Router
↓
WireGuard Server
となります。
自分のルーターでポートを開けても、その外側にあるISP側のNATは設定できません。
つまり、
ルーターの設定は正しい。
WireGuardも動いている。
でもパケットが家まで来ない。
という状態が起こり得ます。
まずWAN側IPv4を確認する
ルーターの管理画面を開き、WAN側に割り当てられているIPv4アドレスを確認します。
次に、インターネット側から見えているIPv4アドレスと比較します。
両者が違う場合、自宅ルーターより上流にNATやIPv4共有の仕組みが存在している可能性があります。
ただし、IPv4 over IPv6では単純比較だけでは判断できないこともあります。
そこで次に、
契約回線がどの方式でIPv4を提供しているのか
を確認します。
2. IPv4 over IPv6は「MAP-E系」と「DS-Lite系」で事情が違う
日本の家庭用回線では、IPv6 IPoEを使いながら、IPv4通信をIPv6網の上で提供するIPv4 over IPv6も広く使われています。
ここで重要なのは、
「IPv4 over IPv6だからポート開放できない」
と一括りにはできないことです。
方式によって事情が違います。
MAP-E系:使えるIPv4ポートが限定されることがある
MAP-E系では、1つのIPv4アドレスを複数の利用者で共有しながら、利用者ごとに使用可能なポートを割り当てる構成があります。
つまり、
Public IPv4を共有している
↓
自分が使えるポートは決められている
という状態です。
そのため、
「ポート開放はできる。でも好きなポートを自由に使えるとは限らない」
ことがあります。
WireGuardの待受ポートを設定していても、その番号が自分に割り当てられたポートに含まれていなければ、外部からの接続には使えません。
自分が使えるポートを確認する
ここは回線サービスやルーターによって異なります。
対応ルーターでは、管理画面に利用可能なIPv4ポート番号・ポート範囲が表示される場合があります。
方式によっては、割り当てられたIPv6プレフィックスなどの情報から、利用可能なポートを算出することもできます。
まず、
ISPのIPv4 over IPv6サービスの説明
↓
利用しているルーターの対応状況
↓
ルーター管理画面
の順で確認します。
WireGuardのデフォルトポートをそのまま転送して、
「設定したのにつながらない」
となっているなら、ここは確認する価値があります。
DS-Lite系:通常のIPv4ポート開放では解決しない
DS-Lite系では事情が異なります。
IPv4通信はIPv6網を経由し、ISP側のAFTRと呼ばれる装置を通ってIPv4インターネットへ出ていきます。
そのため、自宅ルーターに自分専用のPublic IPv4が直接割り当てられ、それに対して自由にポート転送する従来型の構成とは異なります。
つまり、通常の構成では、
Internet
↓
Public IPv4
↓
自宅RouterのPort Forward
↓
WireGuard
というIPv4のInbound経路を作れません。
この場合、
WireGuardのListenPortを変える
ルーターのポート転送を何度設定し直す
といった作業を続けても、根本的な解決にはなりません。
「IPv6 IPoEを使っている」だけで判断せず、
自分のIPv4通信がMAP-E系なのか、DS-Lite系なのか
まで確認するのがポイントです。
3. マンション回線では、自分のルーターが「一番外側」とは限らない
マンション一括型のインターネットでは、さらに別の問題があります。
部屋には普通のWi-Fiルーターがある。
管理画面にも入れる。
ポート転送の項目もある。
だから、
「ここでUDP 51820を開ければいい」
と思います。
ところが実際には、
Internet
↓
建物側ネットワーク設備
↓
自室Router
↓
WireGuard Server
という構成になっていることがあります。
自分が管理しているルーターが、インターネットとの境界ではないわけです。
自室ルーターでポートを開けても、その上流でInbound通信が止まっていればWireGuardまでは届きません。
自分でルーターを追加して、
ONU / Home Gateway
↓
追加Router
↓
WireGuard Server
となっている二重NATでも、似た問題が起こります。
ここで確認すること
自室ルーターのWAN側アドレスを確認します。
さらに、ルーター機能を持つ機器が、
自分のWireGuard Serverより上流に何段あるのか
を確認します。
マンション側設備については、利用者が管理できない場合もあります。
この場合も、
WireGuardが壊れているのではなく、WireGuardまで通信が届いていない
可能性があります。
4. DDNSが正しくても「到達できる」とは限らない
次にDDNSです。
自宅のIPアドレスが変わるため、
example.ddns.net
のようなホスト名をWireGuardのEndpointに設定している人もいると思います。
DDNSがしてくれるのは基本的に、
「現在のIPアドレスを名前から引けるようにすること」
です。
外部からそのIPアドレスへ到達できることまでは保証してくれません。
つまり、
DDNS更新成功
≠
WireGuardへ外部から到達可能
です。
本当に家まで届いているか確認する
まず、DDNSのホスト名がどのIPアドレスを返しているか確認します。
次に、自宅Wi-Fiを切ったスマートフォンなど、完全に自宅LANの外側からWireGuardへ接続を試します。
同時にWireGuard Server側でパケットを確認します。
LinuxでUDP 51820を使っているなら、たとえば、
sudo tcpdump -ni any udp port 51820としておきます。
その状態で外部からHandshakeを発生させます。
パケットが見えるなら、
Internet → 自宅 → WireGuard Server
まで通信が届いている可能性が高くなります。
何も来なければ、
ISP側
上流NAT
MAP-Eの割り当てポート
ルーターのPort Forward
ファイアウォール
など、WireGuardより手前を疑います。
外部のポート確認サービスやncなどを補助的に使う方法もありますが、UDPはTCPほど単純に「OPEN / CLOSED」を判断できません。
最終的には、実際に外部からパケットを送り、サーバー側で見えるか確認する
方が切り分けやすいでしょう。
5. パケットが届いているなら、そこでWireGuardを確認する
ここまで確認して、
外部から到達可能な経路がある
必要なUDPポートを利用できる
上流NATに問題がない
DDNSが正しい
外部からのUDPパケットがサーバーまで届く
となったら、そこでWireGuard側を詳しく見ます。
代表的なのは、
Endpoint
ListenPort
AllowedIPs
秘密鍵・公開鍵
OSのファイアウォール
UDPポート転送
IP forwarding
NAT / masquerade
などです。
特に、
LAN内では接続できる。
外部からのUDPもサーバーまで届く。
でもHandshakeしない。
のであれば、WireGuard側を調べる意味が出てきます。
逆に、
外部から送ったUDPがサーバーに一切届かない
のであれば、秘密鍵やAllowedIPsを何度書き換えても状況は変わりません。
この順番が大切です。
「じゃあIPv6で直接つなげばいい」は可能?
ここまでIPv4を中心に説明しました。
では、
「IPv4のポート開放が難しいなら、IPv6でWireGuardへ直接つなげばいいのでは?」
と思うかもしれません。
実際、環境によっては可能です。
IPv6では、WireGuard ServerにグローバルIPv6アドレスが割り当てられ、外部IPv6ネットワークから直接到達できる構成を作れる場合があります。
ただし、
「IPv6が使える」
=
「外部からWireGuardへ入れる」
ではありません。
ここにも確認すべきポイントがあります。
IPv6では「ポート開放」よりファイアウォールを見る
IPv4のNAT環境では「ポート開放」という言葉をよく使います。
IPv6では考え方が少し違います。
WireGuard ServerにグローバルIPv6が付いていても、ルーターのIPv6ファイアウォールが外部から開始された通信を遮断している場合があります。
その場合は、たとえば、
WAN → LAN
UDP
WireGuard ServerのIPv6
Port 51820
Allow
のようなInbound許可ルールを作れる必要があります。
ルーターの管理画面やマニュアルで、
IPv6 Firewall
IPv6 Filter
IPv6 Packet Filter
IPv6 Inbound
IPv6 Access Control
などを確認します。
重要なのは、
「IPv6ファイアウォール ON / OFF」
というスイッチがあることではありません。
WireGuard用のUDPだけを個別に許可できるか
です。
機種や回線構成によっては、IPv6の外部着信を遮断できても、利用者が任意のInbound許可ルールを作れない場合があります。
IPv6パススルー / ブリッジか、IPv6ルーティングか
もう一つ確認したいのが、ルーターがIPv6をどう扱っているかです。
製品によっては、
IPv6パススルー
IPv6ブリッジ
などの名称で、IPv6通信をLAN側へ通す機能があります。
概念的には、
Internet
↓
Router
↓ IPv6 pass-through / bridge
WireGuard Server
という構成です。
一方、ルーター自身がIPv6をルーティングし、ファイアウォールで外部着信を制御する構成もあります。
Internet
↓
Router + IPv6 Firewall
↓
WireGuard Server
この場合は、先ほどのIPv6 Inboundルールが重要になります。
つまり確認するのは、
「IPv6対応ルーターか?」
だけでは足りません。
IPv6で確認する順番
① WireGuard ServerにグローバルIPv6があるか
↓
② ルーターがIPv6をどう扱っているか
↓
③ IPv6 Firewallで必要なInboundを許可できるか
↓
④ 実際に外部IPv6回線からUDPが届くか
です。
Linuxなら、
sudo tcpdump -ni any 'ip6 and udp port 51820'として、外部のIPv6回線からWireGuardのHandshakeを試すと確認できます。
IPv6でInboundを許可するときは、IPv4の感覚で考えない
ここはセキュリティ上、注意が必要です。
一般的なIPv4のNAT環境では、明示的にポート転送などを設定しない限り、インターネット側からLAN内の端末へ新しい接続を開始することは通常できません。
そのため、結果としてLAN内の端末が直接外部から到達されにくい状態になっています。
IPv6ではNATを前提としないため、同じ感覚では考えられません。
グローバルIPv6を持つ端末へのInbound通信をファイアウォールで許可すれば、その許可した通信についてはインターネット側から直接到達可能になります。
だから、
「IPv6ならポート開放がいらないから、ファイアウォールを切ればいい」
という設定は避けた方がいいでしょう。
WireGuardを公開するなら、必要なUDPポートだけを許可し、それ以外のInbound通信は遮断する。
さらにルーターだけに頼らず、WireGuard Server自身のOSファイアウォールも含めて制限する。
IPv6 DirectはIPv4側の制約を避ける有力な方法ですが、
「外から自宅へ直接到達させる」
という設計であること自体は変わりません。
結局、確認すべきなのは「ポート開放できる?」ではない
ここまでを見ると、自宅VPNのトラブルを、
「ルーターでポート開放できるか?」
だけで判断するのは少し危険です。
本当に確認したいのは、
「インターネットからWireGuard Serverまで、必要なUDP通信を通せる構成なのか?」
です。
IPv4なら、
Public IPv4なのか
CGNATなのか
MAP-E系なのか
DS-Lite系なのか
二重NATなのか
マンション側に上流設備があるのか
を見る。
IPv6なら、
グローバルIPv6があるか
IPv6パススルー / ブリッジなのか
IPv6 Firewall型なのか
必要なInboundルールを設定できるか
を見る。
そして最後は、実際に外部回線から通信を発生させて、
WireGuard ServerまでUDPパケットが届いているか
を確認する。
ここまでやれば、
回線の問題なのか
ルーターの問題なのか
WireGuardの問題なのか
をかなり切り分けられます。
IPv6なら解決する?
IPv4のポート開放ができなくても、IPv6で直接WireGuardへ接続できる場合があります。ただし、IPv6 Firewall、パススルー、接続元のIPv6対応など別の条件があります。
→ 「IPv6ならポート開放不要」は本当?
それでもInboundできない回線だったら?
前述のとおり、IPv6で直接到達できる環境ならIPv6 Directも選択肢になります。
しかし、
IPv4ではInboundできない。
IPv6でも必要なInboundを通せない。
という環境もあります。
その場合は、「どうやってポートを開けるか」ではなく、そもそもInboundに依存しない構成を考える方法があります。
P2P / NAT traversalを利用する
P2P型・メッシュ型VPNでは、NAT traversalを使ってDirect接続を試みるものがあります。
条件が合えば、手動のポート開放なしで接続できます。
ただし、
ポート開放不要
=
どんな環境でも必ずDirect
ではありません。
NATやファイアウォールの組み合わせによってDirect接続が成立しなければ、Relayへフォールバックする方式もあります。
自宅側から先に接続しておく
もう一つは、発想を逆にする方法です。
従来型は、
外出先
↓
自宅Public IP / IPv6
↓
WireGuard Server
という「外から自宅へ入る」構成です。
これを逆にして、
自宅 → Hub ← 外出先
とします。
自宅側から先にOutboundでトンネルを確立しておけば、自宅ルーターが外部から新しい接続を受け付けることを前提にしなくて済みます。
つまり問題を、
「どうやってInboundを通すか」
ではなく、
「そもそもInboundを必要としない構成にできないか」
と考え直すわけです。
HomeGrid VPNは「自宅へ入れるか」を前提にしない
HomeGrid VPNは、このOutbound型の考え方を採用しています。
自宅側のApplianceからCloud HubへWireGuard UDPの接続を確立するため、自宅ルーターに外部から新しい接続を受け付けることを前提にしません。
そのため、
ポート開放不要
固定IPv4不要
DDNS不要
という構成にできます。
自宅側には、有線LANで接続できる余剰PCやミニPCなどをApplianceとして設置します。
セットアップ後は、外出先の専用アプリから接続し、自宅回線を経由してインターネットへ出る構成です。
これは、
「WireGuardをどう設定すればInboundできない回線でもInboundできるのか」
という解決ではありません。
そもそも、
「外から自宅へ到達できることを前提にしない」
という設計です。
WireGuardが外からつながらないとき、設定ファイルを何度も書き換える前に確認したいのは、
そのパケット、本当に家まで届いていますか?
ということ。
IPv4でもIPv6でも、まずそこを確認する。
それだけで、延々とWireGuardの設定と格闘せずに済むかもしれません。
👉 [自宅VPNを作ろうとして「詰んだ」人へ。ポート開放できない回線でも約10分で使える方法]