WireGuardが外からつながらない｜LANでは動くのに接続できない原因と確認手順

WireGuardがLAN内では動くのに外からつながらないときは、鍵を作り直す前に、外から送ったUDPが自宅のサーバーまで届いているかを確認します。ハンドシェイクが成立しない問題と、成立してもLANへ届かない問題を分けることで、回線・Firewall・経路のどこを調べるべきか絞れます。

自宅にWireGuardを入れた。LAN内では接続できた。ルーターのポート開放も設定した。

それなのに、スマートフォンをモバイル回線に切り替えるとつながらない。

この場合、鍵や設定ファイルを作り直す前に、確認したいことがあります。

外から送ったパケットは、自宅のWireGuardまで届いているでしょうか。

LAN内での成功は、インターネットから自宅へ到達できることまで保証しません。家庭用回線の方式や上位ルーターによっては、自宅のルーターだけを設定しても届かないことがあります。

この記事では、まず接続できない場所を切り分けます。そのうえで、外部からの接続を受ける構成を運用し続けるか、Home側から接続する構成へ変えるかを考えます。

まず「つながらない」を2つに分ける

WireGuardアプリのスイッチがONでも、相手との通信が成立しているとは限りません。

最初に見るのは、直近のハンドシェイクです。LinuxのWireGuardサーバーなら、次のコマンドで確認できます。

sudo wg show wg0

wg0は実際のインターフェース名に置き換えてください。Windowsやスマートフォンでは、利用しているアプリのハンドシェイク時刻やログを確認します。

VPN内の相手IPなど、トンネルを通す設定になっている宛先へ通信を試し、その前後を比べます。WireGuardは通信が不要なときには静かなため、操作していない間の古い時刻だけで障害とは判断できません。

試した結果	次に確認する場所
ハンドシェイクが更新されない	Endpoint、UDPの到達性、待受ポート、Firewall、鍵
ハンドシェイクは更新されるがNASに届かない	AllowedIPs、経路、IP転送、戻り経路、NAS側の許可
IPアドレスでは使えるが名前では使えない	DNSや名前解決
小さな通信はできるが、一部のWeb表示や転送が止まる	MTUや経路上の制限

ハンドシェイクの成立は、NASやインターネット出口まで使えることの証明ではありません。まず、この境目を分けます。

参考：WireGuard公式 Quick Start

1. 自宅Wi-Fiを切って、外側から試す

自宅Wi-Fiにつないだまま、自宅のPublic IPやDDNS名に接続していないでしょうか。

LAN内から自宅のPublic IPへ折り返す通信は、ルーターのNATループバック機能などに左右されます。LAN内で失敗しても、外部からも失敗するとは限りません。

逆に、EndpointをサーバーのLAN内IPにしたテストで成功しても、ポート開放やISP側の条件は確認できていません。

スマートフォンのWi-Fiを切り、モバイル回線から試します。このときEndpointが、外部から到達するためのIPアドレスやホスト名になっているかも確認してください。

以下はIPv4の例です。vpn.example.comは説明用なので、実際の名前へ置き換えます。

[Peer]
Endpoint = vpn.example.com:51820

51820はよく使われる例で、必須の番号ではありません。ルーター側の外部ポートと、クライアントが接続するポートを合わせます。

DDNSを使っている場合は、その名前が現在の自宅Public IPを指しているかも確認します。

2. 自宅の回線でIPv4の着信を受けられるか確認する

一般的なIPv4のポート転送は、次の経路を想定しています。

外出先の端末
    ↓ UDP
自宅ルーターのPublic IPv4
    ↓ ポート転送
WireGuardサーバーのLAN内IP

自宅ルーターの外側に、さらにNATがある場合は、その手前で止まる可能性があります。

WAN側IPv4と、外部から見えるIPv4を比べる

ルーターの管理画面で、WAN側のIPv4アドレスを調べます。続いて、自宅回線からIPv4のIP確認サービスなどを使い、外部から見えるIPv4と比べます。ブラウザがIPv6を使った結果と混同しないようにしてください。

WAN側が次の範囲なら、一般的なPublic IPv4ではありません。

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
100.64.0.0/10（100.64.0.0〜100.127.255.255）

前の3つはプライベートアドレスです。最後の範囲は、ISPのCGNなどで使われる共有アドレス空間です。RFC 6598

たとえば、自分のルーターの上にホームゲートウェイがある二重NATなら、上位機器の転送設定やルーター構成の見直しで解決できる場合があります。

一方、ISP側のCGNATやマンションの共用設備は、利用者が自由に設定できるとは限りません。アドレスの比較は手がかりなので、最終的には契約サービスと接続方式も確認します。

MAP-EとDS-Liteを同じ扱いにしない

「IPv4 over IPv6だからポート開放できない」と一括りにすると、判断を誤ります。

方式・構成	確認する条件
MAP-EでIPv4を共有する構成	利用可能なポートの範囲と、ルーターのポート転送対応
一般的なDS-Liteサービス	ISP側のNATと、外部からの着信・ポート割り当ての提供有無
自宅内の二重NAT	上位と下位の両方を管理できるか
マンション側の上位NAT	共用設備側で着信を許可・転送できるか

MAP-Eでは、割り当てられたポートの範囲内で利用できる場合があります。いつもの51820が使えないだけなら、利用可能な外部UDPポートを選ぶ方法もあります。外部と内部で番号を変えられるかはルーターの仕様によります。

DS-LiteはISP側にIPv4のNATを置く仕組みです。一般的なサービスでは、自宅ルーターで任意の転送ルールを作るだけでは外部からの着信を成立させられません。ISPが提供する機能や契約条件を確認してください。

参考：MAP-E：RFC 7597、DS-Lite：RFC 6333

3. ポート転送はUDP・宛先IP・待受ポートを合わせる

着信を受けられる回線なら、ルーターの転送設定を確認します。

プロトコルがUDPになっているか
転送先がWireGuardサーバーの現在のLAN内IPか
転送先ポートとWireGuardの待受ポートが一致しているか
クライアントのEndpointに正しい外部ポートを設定したか

サーバーのLAN内IPがDHCPで変わった場合、転送先だけが古いまま残ることがあります。DHCP予約などでアドレスを安定させると管理しやすくなります。

WireGuardがルーター自身で動いている場合は、LAN内サーバーへの転送ではなく、ルーター自身へのUDP着信を許可する設定を確認します。

Dockerや仮想マシンで動かしているなら、ホストからコンテナ・ゲストまで届くかも確認対象です。Dockerのポート公開はTCPとUDPを区別します。

4. tcpdumpで「サーバーまで届いたか」を見る

ここで、設定画面から実際の通信へ視点を移します。

Linuxサーバーで、次のようにWireGuardの待受ポートを観測します。例はUDPの51820です。

sudo tcpdump -ni any 'udp port 51820'

その状態で、外部の端末からWireGuard接続を有効にし、VPN内の宛先へ通信を試します。止めるときはCtrl+Cです。

コンテナ内でWireGuardが動いている場合は、まずホスト側、必要に応じてコンテナ側でも観測します。別のネットワーク名前空間で動くインターフェースは、ホストのanyだけでは直接見えない場合があります。

試した時刻に、外部端末からのUDPが見えない

Endpointの宛先、外部ポート、ルーターの転送、上位NAT、接続元ネットワークのUDP制限などを調べます。

ただし、フィルターのポート番号や観測場所が違っていても表示されません。表示されないことだけで、ISPが遮断したとは断定できません。

UDPは見えるのに、ハンドシェイクが更新されない

少なくとも、その観測地点まではパケットが届いています。次はサーバーOSのFirewall、実際の待受ポート、Peerの公開鍵、設定している場合は事前共有鍵の一致を確認します。

パケットがキャプチャに見えても、その後にOSのFirewallで破棄される可能性があります。また、届いたUDPが正しいWireGuardの認証要求であるとは限りません。

Firewallを丸ごと無効にするのではなく、対象のUDPポートに関するルールやカウンターを確認します。

「UDPポートチェックで閉じている」は決め手にならない

TCPの接続確認と同じ感覚で、UDPをOPEN/CLOSEDと判断しないようにしてください。TCP専用のチェックサイトではWireGuardを検査できません。

WireGuardは認証できない要求に通常応答しないため、汎用的なUDPプローブも無応答になることがあります。実際のPeerによる通信と、パケット観測を組み合わせて判断します。

5. ハンドシェイクが成立したら、LANへの経路を見る

ここまででハンドシェイクが更新されるなら、次はトンネルの内側です。

たとえばWireGuardサーバーのVPN内IPには届くのに、別のNASへ届かない場合は、次の項目を確認します。

クライアントのAllowedIPsに、NASのIPや自宅LANの範囲が含まれているか
サーバー側のPeer設定で、クライアントのVPN内IPを正しく許可しているか
WireGuardサーバーで必要なIP転送と転送Firewallの許可があるか
NASからVPNクライアントへの戻り経路があるか
戻り経路をSNATで処理する設計なら、その設定があるか
NAS側のFirewallやサービスが、接続元を許可しているか
外出先LANと自宅LANのアドレス範囲が重複していないか

AllowedIPsは、送信先のPeer選択と、受信したトンネル内パケットの送信元チェックに関わります。加えてOS側の経路も必要です。wg-quickは通常AllowedIPsから経路を作りますが、利用ツールや設定で動作は異なります。

参考：WireGuardのCryptokey Routing、wg-quick公式マニュアル

最初からDNSやMTUを一度に変更せず、「VPN内IP」「NASのIP」「NASの名前」の順で試すと、原因を絞りやすくなります。

Docker Desktopで小さい通信だけ通るなどの症状がある場合は、Docker DesktopでWireGuardのMTUが大きくなる事例も参考になります。同記事の値がすべての環境の正解になるわけではありません。

IPv6なら解決する？ポート転送不要でもInboundは残る

IPv4の着信に制約があっても、IPv6で直接接続できる場合があります。

ただし「NATのポート転送が不要」と「外部からの着信を考えなくてよい」は別です。

確認するのは、サーバーに外部到達可能なGlobal IPv6があるか、ルーターとOSの両方で対象UDPのInboundを許可できるか、ISP側から到達できるかです。fe80::で始まるLink Localや、ULA（fc00::/7、一般にfd…）だけでは、インターネットからの直接接続先にはなりません。

旅行先のFree Wi-Fiでは、IPv6対応を当てにしない

見落としやすいのが、外出先のネットワークです。IPv6で自宅へ直接接続するには、接続元にもIPv6接続性が必要です。

ホテルやカフェなどのFree Wi-Fiには、IPv4 onlyの環境がかなり多くあります。旅行先の空港・カフェ・ホテルで使うなら、IPv6で自宅へ直接接続できることを当てにした構成は避けたいところです。 自宅のWireGuardサーバーにGlobal IPv6があり、Firewallを正しく設定していても、接続元がIPv4 onlyならIPv6の接続先へ直接つながりません。

NDSS 2025の論文「Off-Path TCP Hijacking in Wi-Fi Networks: A Packet-Size Side Channel Attack」では、カフェ・ホテルなどを含む80の実環境Wi-Fiを調査し、74ネットワーク（92.5％）がIPv4 only、IPv6対応は6ネットワーク（7.5％）だったと報告しています。世界全体の正確な割合としては使えませんが、公衆Wi-FiではIPv4 onlyが多く、IPv6対応を期待できない場面が多いことを示唆する結果です。論文のFigure 10と本文（PDF・11ページ）

背景には、既存機器に加え、ログイン・利用規約への同意を求める「Captive Portal」の対応もあります。たとえばpfSenseの公式資料には、Captive PortalはIPv6非対応と記載されています。このように、単に回線がIPv6に対応しているかだけでなく、利用者認証を含むWi-Fiシステム全体の対応が必要です。pfSense公式資料：Captive Portalの制約

ホテルのWi-Fi（IPv4 only）
    ✕ IPv6の接続先へ直接到達できない
自宅のWireGuard（Global IPv6）

「モバイル回線ではつながるのに、ホテルのWi-Fiではつながらない」場合は、鍵や自宅側の設定だけでなく、接続元でIPv6が使えるかも確認してください。Wi-FiでWebサイトが開けることだけでは、IPv6が使えるとは判断できません。

IPv6が利用できるモバイル回線やテザリングへ切り替える方法もありますが、その分モバイルデータを消費します。海外ローミングの容量を節約したい場面では、ホテルのWi-Fiを使えないことが制約になります。

たとえば、海外のホテルでは無料Wi-Fiで仕事をしようと考えていたのに、自宅への接続先をIPv6だけにしたため、そのWi-FiからVPNへ届かない。代わりにIPv6が使えるモバイル回線へ切り替えると、ファイル転送やリモート作業も契約プランのデータ容量を使います。容量の追加購入やローミング料金が必要になる場合があり、無料Wi-Fiを利用するつもりだった費用計画が変わります。

IPv6対応Wi-Fiもあるため、IPv6 Directがモバイル通信専用になるわけではありません。それでも、利用先のWi-FiがIPv4 onlyなら、その場所では別のIPv6接続手段に頼ることになります。さらに、モバイル回線や海外ローミングもIPv6対応が保証されるわけではなく、通信事業者・契約・接続先ネットワークの確認が必要です。「自宅をIPv6対応にすれば、旅行先の無料Wi-Fiからも使える」とは限らないことが、実用上の制約です。

IPv6 Directを選ぶ場合は、自宅側の条件に加え、利用する外出先でもIPv6が使えるかを考える必要があります。

IPv6 Pass-throughも、名称だけで安全性や挙動を判断せず、ルーターの仕様とFirewall動作を確認します。LAN全体の到達性に影響する可能性があるため、VPNサーバー1台の接続だけを見て有効にしないようにしてください。

自宅の設定が正しくても、IPv4 onlyのホテル側にIPv6接続性は用意できません。

つながるようにした後も、公開する接続口の管理は続く

ここまでの確認で、自宅WireGuardを外から使えるようになるかもしれません。

ただ、ポート開放やIPv6のInbound許可は、外部から接続要求を受け取れる状態にする変更です。接続が成功した後も、その接続口を維持する責任が残ります。

最近の注意喚起が示す、VPN機器を狙う攻撃

2026年6月22日、シンガポールのCyber Security Agency（CSA）は、インターネットに公開されたFortiGateやVPNポータルに対する認証情報収集の攻撃について注意喚起しました。総当たり、辞書攻撃、他サービスから流出した認証情報の使い回しなどを挙げ、外部管理アクセスの制限・無効化も推奨しています。CSAの注意喚起

また、2025年2月のACSC・CISAなどによる共同ガイダンスは、VPNやルーターなどの境界機器について、脆弱性・設定不備・DoSへの対処や、管理インターフェースをインターネットへ直接公開しないことを勧めています。Security considerations for edge devices

これらは、家庭用WireGuardのUDP待受に同じ攻撃がそのまま成立するという根拠ではありません。WireGuardのPeer認証と、パスワード入力型のVPNポータルや管理画面は異なります。

自宅運用でも確認したいのは、次の点です。

WireGuardだけでなく、OS・ルーター・管理ツールも更新を続けられるか
管理画面、SSH、NASなどを、意図せず一緒に公開していないか
紛失端末や使わなくなった端末の鍵を失効できるか
VPN接続後に、必要以上のLANへアクセスできないか
大量の通信による回線圧迫やサービス停止に、どこまで対応できるか

認証されていない要求に応答しにくいことと、実装上の脆弱性やサービス妨害を含むリスクがないことは別です。WireGuardを使う場合も、必要な待受だけを許可し、管理用の接続口を分けて考えます。

鍵を持たない相手が、開いたポートへ送るだけで正規Peerとして接続できるわけではありません。一方、外部から届くパケットを処理する実装に、認証前に悪用できる脆弱性があれば、鍵認証とは別の経路で侵害される可能性があります。これは現在のWireGuardにそのような脆弱性があるという主張ではなく、公開する機器・OS・周辺ソフトウェアを含めて更新を続ける必要がある理由です。

自宅VPNの運用では、「鍵がある相手だけを通す」ことに加え、外部から届く通信を処理する接続口を維持し続けることになります。

侵入された後、LAN内のどこまでアクセスできるか

公開する接続口だけでなく、その先のアクセス範囲も重要です。

VPN端末の鍵が盗まれたり、VPNサーバー自体が侵害されたりした場合、攻撃者がLAN内のどこまで到達できるかは、経路とアクセス制御によって変わります。

NAS、作業用PC、開発サーバー、ルーターの管理画面などが同じLANにあり、相互の通信を制限していなければ、侵入した地点から複数の機器を探索・攻撃される可能性があります。NASへ接続するために作ったVPNが、ほかの機器へ進む足場になることもあります。このように、侵入後に別の機器へ攻撃を広げる動きを「横展開」と呼びます。

「VPNで認証した端末だから、LAN内はすべてアクセス可能」でよいかを考えてください。

ただし、ネットワーク上で到達できることと、ファイルを読める・管理者として操作できることは別です。各サービスの認証やOSのFirewallは引き続き働きます。それでも、到達できる機器が多いほど、盗まれた認証情報や別の脆弱性を試される範囲は広がります。

ここで役立つのが、Default Deny（原則拒否）で、必要なSubnetだけを許可する考え方です。接続できた端末へ、すべてのLANへの経路を自動的に開放しないことに意味があります。

鍵認証は「接続している相手」を確認するものです。その端末に「どのLANへのアクセスを許可するか」は、別の認可です。たとえば、自分のPCには仕事用LANを許可し、別の端末には許可しない。この区別を、VPNへの接続可否とは別に管理します。

普段使うLANはSubnet単位で許可すれば、機器を追加するたびにVPN側の個別設定を増やさずに済みます。一方、アクセスする必要のないLANは未許可のままにします。仕事用と家庭用など、守る範囲が異なる場合はSubnetを分け、境界でも通信を制限します。

もちろん、許可したLAN内の端末が踏み台になれば、その端末から到達できる範囲へ攻撃が広がる可能性は残ります。だから制限が無意味なのではなく、最初から到達できる範囲を必要なLANに限定することが、Default Denyの役割です。 ただし、許可した端末が別LANへの経路を持っていれば、そちらを経由される可能性もあるため、LAN間の境界でも制御が必要です。

DIYのWireGuardでも、PeerとVPN内IPの対応付け、転送Firewall、VLANなどを組み合わせて実現できます。ただし、端末の追加・削除や鍵の失効に合わせ、アクセス許可も管理する必要があります。Firewallが単に「VPNからLANへ許可」となっていれば、入口を通った通信はそのルールに従います。クライアント側のAllowedIPsだけに頼らず、アクセスを受ける側・転送する側で認可を強制することが大切です。

また、VPNサーバー自体が侵害されると、その機器上の制御を変更される可能性があります。重要な機器を別のセグメントへ分けるなど、侵害された機器だけに依存しない境界も検討します。

公開するVPN接続口があり、接続後はLAN全体へ広く到達でき、さらに別の境界でも制限していない。この構成では、入口の侵害が複数の機器への攻撃へつながる可能性があります。自宅VPNを動かす作業だけでなく、侵入された場合の到達範囲まで管理する必要がある点が、運用上の負担です。

自宅の接続先IPは、GeoIPによる地域推定の手がかりにもなる

もう一つ考えたいのが、自宅のPublic IPを外出先からの接続先にすることです。

WireGuardで通信内容を暗号化しても、外側のIPヘッダーにある接続先IPまで隠れるわけではありません。外出先のWi-Fi管理者など、通信経路を観測できる立場には、そのIPへ通信していることが見える場合があります。これはIPv4でもIPv6でも同じです。

観測したIPをGeoIPデータベースで調べると、国・地域の推定情報が得られます。ASNやISPの情報と組み合わせれば、どのネットワークへ接続しているかを調べる手がかりにもなります。

ただし、GeoIPの表示位置が、そのまま自宅の所在地を示すわけではありません。 MaxMindも、自社のGeoIPデータは特定の世帯・個人・番地を特定できる精度ではないと説明しています。推定地域が実際の場所と異なる場合もあります。MaxMind：Geolocation accuracy

リスクは「IPが見えたら住所が分かる」と断定することではなく、自宅回線のIPと外出先の通信記録が結び付く手がかりを残すことです。Wi-Fiの利用者情報や繰り返し同じIPへ接続する記録と組み合わせられる可能性があります。ただし、IPだけから、その接続先が本人の自宅だと確定できるわけではありません。

この点は、ポート番号を変更しても解消しません。公開する接続口の管理に加えて、自宅IPを直接の接続先にする必要があるかも検討します。

WireGuardを破らず、家庭用ルーターの別の機能を狙われる可能性

自宅側の接続先IPが知られることの影響は、WireGuardへの攻撃だけではありません。そのIPで外部から到達できる管理画面や別のサービスがあれば、攻撃者がそちらを調べる手がかりにもなります。

たとえば、自宅ルーターのWAN側管理画面が公開されていて、そこに悪用可能な脆弱性があれば、WireGuardの鍵認証を突破せずにルーターを侵害される可能性があります。JPCERT/CCも、2025年7〜9月の定点観測レポートで、管理画面がインターネットからアクセス可能なルーターについて、未更新の脆弱性による不正ログインや踏み台化のリスクを説明しています。JPCERT/CCの観測レポート

ただし、VPN接続先のIPが分かっただけで、LAN側だけの管理画面へ届くようになるわけではありません。IPv6ではVPNサーバーとルーターが別アドレスの場合もあり、VPN接続先の発見がそのままルーター管理機能の発見になるとも限りません。実際に到達できる機能、公開設定、脆弱性の条件が必要です。

家庭用回線そのものが、Residential Proxyの足場として狙われる

「自宅には盗まれるようなデータがない」と考えていても、家庭用ルーターやIoT機器が攻撃対象から外れるわけではありません。家庭用IPから通信を出せること自体が、第三者に悪用される場合があります。

2026年7月21日、NICTは総務省・警察庁と共同で、家庭用IoT機器を悪用するResidential Proxyの現状を公表しました。ルーターやネットワークカメラなどを通じて第三者の通信を中継し、不正アクセスや不正送金などで攻撃者の所在を隠す用途に悪用されていると説明しています。NICTの観測では、2026年1月以降、1日あたり最大約2万7千のIPアドレスが出口ノードとして観測されています。この数字は同時期の観測IP数であり、すべてがルーターの脆弱性から侵入された台数という意味ではありません。NICT：家庭用IoT機器を悪用するレジデンシャルプロキシの現状

つまり、守る対象はNASのファイルやPCの情報だけではありません。自宅回線を、知らない誰かの通信の足場にされないことも必要です。

Public IPはVPN通信を観測されなくても探索され得ます。それでも、外出先の利用記録と自宅側IPを結び付ける手がかりを、必要以上に渡す理由はありません。自宅IPをできるだけ直接の接続先として見せないことと、外部から直接到達できる機能を減らすことは、併せて考えたい対策です。

不要なWAN側管理機能を閉じ、ルーターを更新し、サポートが終了した機器を見直します。ただし、最新パッチを適用していても、未修正の脆弱性による侵害リスクは残ります。価格だけで機器の安全性は決まりませんし、更新だけですべての攻撃を防げるとも限りません。

だからこそ、自宅VPNのために外部から直接到達できる接続口を増やさず、アタックサーフェスを減らすことに、更新とは別の価値があります。 WireGuardが安全に動いているかだけで、自宅ネットワーク全体の安全性は判断できません。

自宅でInboundを受ける構成を続けるか、設計を変えるか

Direct型の自宅WireGuardは、回線条件と設定が合えば構築できます。自分で制御したい範囲が広く、更新や鍵管理を続けられる人には選択肢になります。

一方で、次のように感じる場合は、ポート開放の調整を続ける以外の方法も考えられます。

「実家の回線方式やルーターを変えたくない」

「外出先がIPv4 onlyでも使いたい」

「自宅へ直接接続を受けるためのルールを持ち続けたくない」

この場合は、自宅側から外部の中継点へ接続する構成が候補です。

VPSを使って自作することも可能です。その場合は、公開側のVPS、WireGuard、ルーティング、Firewall、鍵、更新、障害対応を自分で管理します。

P2Pの「ポート開放不要」は、外からの直接通信を受けないという意味ではない

P2P型のVPNも候補です。ただし、NAT越えで直接接続する方式では、両側からパケットを送り、NATやFirewallに通信状態を作ることで、相手から届くパケットを受け入れられるようにします。

つまり、手動でポートを開放しなくても、外から内へ、相手のパケットが届く経路を動的に成立させているということです。固定のポート転送で不特定の送信元から着信を受ける設定とは異なりますが、「ポート開放不要だから、Home側で外部からの直接通信を受けない」とは言えません。通信状態の有効期間や受け入れる送信元の範囲は、NAT・Firewallの実装や方式によって異なります。

また、WireGuardが認証できない要求へ通常応答しないことと、実際に行っている通信が観測されないことは別です。ホテルやFree Wi-FiからHomeへ直接通信している間、経路上でパケットを観測できる管理者などには、接続先のPublic IPとUDPポート、通信時刻や通信量が見え得ます。自宅側から外出先へ戻るパケットでは、そのIPとポートが送信元として現れます。

不特定の第三者がスキャンしてVPNの存在を確認できるか、外出先の通信経路上で接続先を観測できるか、観測した通信をWireGuardや本人の自宅と特定できるかは、それぞれ別の問題です。「スキャンに応答しないから、自宅側の接続先IPやポートも知られない」とは言えません。 ただし、IPとポートが見えることだけで通信内容が復号されたり、そのポートが誰からでも利用できると分かったりするわけではありません。

P2PのNAT越えは、手動のポート転送を減らす仕組みであって、直接接続する相手からのパケット処理や端末の更新を不要にする仕組みではありません。通信経路上の攻撃者と、無関係な外部の第三者では到達できる条件も異なりますが、動的に成立した経路だから脆弱性への対処が不要になるわけではありません。

自宅のPublic IPを接続先として相手や経路上の観測者へ見せる点でも、P2Pの直接接続は従来の自宅VPNと共通します。 手動のポート開放が不要でも、自宅IPの露出までなくなるわけではありません。観測したIPを手がかりに、家庭用ルーターの外部公開機能を探索され、悪用可能な脆弱性があれば、WireGuard以外の経路から侵入を試みられる可能性があります。家庭用回線をResidential Proxyの足場として悪用する攻撃に対しても、自宅側のIPを必要以上に直接の接続先として見せないことには意味があります。

直接接続が成立しない場合に中継へ切り替える製品もあります。その場合、外出先で観測される接続先は中継サーバーになります。P2P型という分類だけで一律に判断せず、実際に直接接続しているのか、中継しているのかを確認します。

上段は直接通信の経路、下段の矢印は接続開始の向きです。トンネル内のデータは双方向に流れます。

HomeGrid VPNは、Home側からCloud Hubへ接続する

HomeGrid VPNは、Home側とRemote側がCloud Hubへ接続するHub & Spoke型です。

Remote ──→ Cloud Hub ←── Home
          両側から接続

Home側がOutbound通信を使うため、原則として自宅ルーターのIPv4ポート転送、IPv6のInbound許可、DDNSを前提にしません。RemoteからHomeのPublic IPv4やGlobal IPv6へ直接接続するための設定を整える必要がない設計です。

外出先のWi-Fiから見えるVPN接続先はCloud Hubとなり、自宅のPublic IPへ直接通信する必要がありません。Direct型の自宅VPNやP2Pの直接接続と比べ、自宅IPをそのVPN通信の接続先として見せずに済みます。

ここで減らしたいのは、外出先から自宅へ直接つながる接続口と、その通信によって自宅IPが知られる機会です。家庭用回線がResidential Proxyの足場としても悪用される状況では、自宅IPを必要以上に直接の接続先にせず、公開範囲を小さく保つことにも意味があります。既存のルーター管理画面などを自動的に閉じたり、機器の脆弱性を修正したりする機能ではないため、もともとの公開設定は別途見直します。

判断する点	Direct型の自宅WireGuard	HomeGrid VPN
Home側の接続条件	IPv4の着信・転送、またはIPv6の到達性とInbound許可	Cloud HubへのOutbound接続
回線・ルーターで確認すること	公開アドレス、上位NAT、着信ルールなど	Hubへ接続できること
外出先の接続条件	HomeのEndpointへ到達できること	Cloud Hubへ接続できること
LANへのアクセス許可	PeerとFirewallなどの対応を自分で設計・管理	Default DenyのLAN ACLで端末ごとに宛先LANを許可
WireGuardサーバーの保守	サーバーや関連ソフトウェアを自分で保守	古いPCをアプライアンスにする場合、自分でのWireGuardサーバー保守が不要

自宅回線をインターネット出口にする場合の経路は、次のようになります。

Remote → Cloud Hub → Home → 家庭用ISP → Internet

この場合、接続先から見える出口IPはHome側のPublic IPです。Cloud Hubは経路上の構成要素であり、Homeを出口にした通信のInternet Exitではありません。

外出先のWi-Fiから見える「VPNの接続先」はCloud Hub、Homeを出口にした場合の「インターネット出口」は自宅回線です。この2つは役割が異なります。

古いPCを、USBから起動してアプライアンスにする

手元の古いPCも活用できます。ダッシュボードからISOイメージをダウンロードし、ツールでUSBメモリへ書き込みます。そのUSBメモリからPCを起動して自動インストールを行い、ダッシュボードで取得したトークンを入力して有効化します。LANへ接続すれば、Home側の機器として利用できます。

この方法なら、WireGuardサーバーを自分で構築・保守する必要がありません。 自宅で接続を受ける設定に加え、VPNサーバーのメンテナンスも利用者の作業から減らせます。家庭用ルーターのファームウェア更新は、HomeGrid VPNの利用に関係なく行うネットワーク機器の管理です。

接続できても、LANへのアクセスはDefault Deny

HomeGrid VPNのLAN ACLは、VPNに接続する端末ごとに、アクセスを許可する宛先LANを管理します。初期状態はDefault Denyで、VPNにつないだだけでは宛先LANへアクセスできません。新しく登録した端末や追加したLANも、明示的に許可してから利用します。

たとえば「自分のPCは仕事用LANへ許可」「家族のスマートフォンは未許可」という使い分けができます。鍵による接続の認証と、LANへのアクセス認可を分けて管理する仕組みです。

許可先はSubnet単位なので、許可したLANにNASやPCを追加するたびに、その1台ずつをVPN側へ登録する必要はありません。普段使うLANはまとめて利用し、アクセス不要なLANは閉じておく。管理の手間とアクセス範囲の制限を両立する考え方です。機器・ポート単位の細かな制御を提供するという意味ではありません。

許可したLAN内での横展開や、踏み台となった端末から別経路で行われる通信まで防ぐものではありません。各サービスの認証、OSのFirewall、必要に応じたLANの分離と境界での制御も組み合わせます。

設定方法は、LAN ACLで端末ごとに行ける先を決めるで確認できます。

VPN接続だけではLANへアクセスできません。許可先はSubnet単位です。

自分で組み合わせる仕組みを、低コストで利用する

認証とアクセス制御を組み合わせる考え方は、企業向けFirewallやVPN基盤でも使われてきました。自宅WireGuardでも実現できますが、端末の識別と許可ルールを対応させ、変更や失効へ追従する仕組みまで含めて運用する必要があります。

HomeGrid VPNは、Home側からのOutbound接続と、Default DenyのLAN ACLを、家庭や小規模環境でも低コストで利用できる選択肢です。企業向けFirewallの全機能を置き換えるという意味ではなく、今回必要な接続と認可の仕組みをまとめて利用できることに価値があります。現在の料金とプラン条件は、HomeGrid VPN公式サイトで確認してください。

そのうえで、自宅回線の着信条件を整える作業と、Home側の公開接続口の管理を減らし、接続後のLANへのアクセス範囲も見直したいなら、HomeGrid VPNを検討する理由があります。

実家回線を利用する場合は、契約者の同意とISP契約条件の確認が前提です。

まずは到達確認。その結果から構成を選ぶ

WireGuardが外からつながらないときは、次の順に確認してください。

自宅Wi-Fiを切り、外部回線から試す。
通信を発生させ、ハンドシェイクが更新されるかを見る。
更新されない場合は、回線方式・Endpoint・UDP転送を調べる。
tcpdumpで到達を確認し、OSのFirewallやPeer設定へ進む。
成立する場合は、LANへの経路と戻り経路を調べる。

自分で管理できる設定が原因なら、Direct型を直して使えます。ただし、外から届く条件を整えることと、その接続口を管理し続けることは別の仕事です。IPv6で解決しても外出先の接続条件が残り、自宅IPを直接の接続先にする点も変わりません。

P2Pで直接接続する場合も、手動のポート開放が不要になることと、Homeが外部からの直接通信を受けないことは同じではありません。鍵認証や無応答だけで判断せず、パケットを受ける機器の更新、侵入後のLANへの到達範囲、自宅IPの観測、外出先の接続性まで含めて構成を選びます。

回線側の制約がある、現地ルーターを触れない、旅行先のFree Wi-Fiを使いたい。自宅IPを必要以上に直接の接続先として見せず、Home側のアタックサーフェスも減らしたい。さらに、接続した端末へLANを一律に開放せず、Default Denyから必要なSubnetだけを許可したい。

こうした条件なら、Home側から外側の向きへ接続するHomeGrid VPNが選択肢になります。

自宅からHomeGrid VPNへ通信できるかどうかは、公式サイトのトップページから開ける「HomeGrid VPN 接続チェック」で、到達性をチェックできます。導入前に、自宅のネットワークから確認してみてください。

HomeGrid VPNの経路と自宅回線を出口にする仕組みは、HomeGrid VPNとは？自宅回線をVPNの出口にする仕組みで確認できます。