外出先から自宅LAN・クラウドVPCへ安全にアクセスするには？ ポート開放に頼らないPrivate Network設計
自宅にNASや開発用PCがある。
クラウドには検証用のVPCや社内向けサーバーがある。
そして外出先のノートPCやスマートフォンから、それらを使いたい。
こうした環境を作ろうとすると、最初に思いつくのがVPNです。
ただし、ここで少し厄介なのが、
「VPNを使えば全部つながる」わけではない
ということです。
自宅LANとクラウドVPCでは、外部からアクセスするための条件が少し違います。
この記事では、
自宅LAN
クラウドVPC
外出先のPC・スマートフォン
を、必要な範囲だけ相互に到達できるPrivate Networkとして扱うには、どんな方法があるのかを整理します。
一般的なWireGuardによるDIY構成から、IPv6 Direct、VPSをHubにする方法、そしてInboundそのものを前提にしないHub & Spoke型まで順番に見ていきます。
自宅LANとクラウドVPCには共通点がある
一見すると、
自宅のNAS
自宅の開発PC
AWSやGoogle CloudなどのVPC
は、まったく別のものに見えます。
しかしネットワークの観点では、かなり似ています。
どちらも、
Internetへそのまま公開するのではなく、Private Networkの内側で使いたいリソース
を置く場所だからです。
たとえば、
NAS
Gitサーバー
開発環境
管理画面
データベース
検証用サーバー
などです。
こうしたサービスを使うたびにInternetへ直接公開するのではなく、必要な端末だけPrivate Networkへ入れる構成にした方が管理しやすい場合があります。
VPNは、そのPrivate Networkへ入るための代表的な方法です。
自宅にWireGuardを置くなら、まずInboundを成立させる必要がある
自宅VPNの一般的な構成はシンプルです。
Remote
↓
Internet
↓
Home Public IP
↓
Router
↓
WireGuard Server
Public IPv4を持っていて、RouterでPort Forwardできる環境なら、この方法は今でも有効です。
WireGuard ServerまでUDPパケットが届けば、自宅LANへ暗号化された経路を作れます。
ただし家庭用回線では、ここに条件があります。
たとえば、
CGNAT
MAP-E
DS-Lite
IPv4 over IPv6
二重NAT
マンション側の上位Router
などです。
こうした環境では、自宅RouterでPort Forwardを設定しても、Internet側からパケットが届かない場合があります。
そのため、
LAN内ではWireGuardが動くのに、外からは接続できない
という現象が起こります。
この場合、WireGuardの設定だけを見るのではなく、
外から送ったUDPパケットがWireGuard Serverまで届いているか
を切り分けることが重要です。
RouterのWAN側にPublic IPv4があるのか、上位に別のNATが存在しないか、Server側でtcpdumpを実行したときにパケットが見えるか、といった順番で確認していきます。
IPv4 over IPv6やPort Forwardが難しくなる理由については、こちらの記事でも詳しく扱っています。
【全滅】自作VPN、P2P、ポート開放、DDNSが現代の高速光回線（IPv4 over IPv6 / 10Gbps）で物理的に死亡する理由
IPv6 Directという方法もある
「IPv4でPort Forwardできないなら、IPv6で直接つなげばいいのでは？」
これは有効な選択肢です。
自宅のServerにGlobal IPv6が割り当てられていて、外部から到達できる環境なら、IPv4 NATを経由せずにWireGuard Serverへ接続できます。
Remote IPv6
↓
Internet
↓
Home Global IPv6
↓
WireGuard Server
IPv6では、IPv4 NATを前提にしないため、IPv4でいうPort Forwardそのものは不要です。
ただし、
Port Forward不要 = Inboundを考えなくてよい
ではありません。
確認したいのは、
ServerにGlobal IPv6があるか
fe80:: のLink Localだけではないか
fd00::/8 のULAだけではないか
RouterのIPv6 FirewallでInboundを許可できるか
Server OS側のFirewall
ISP側から実際に到達可能か
Remote側にもIPv6接続性があるか
です。
特に最後は見落としやすいポイントです。
Home側がIPv6対応でも、ホテルやカフェなどRemote側のネットワークがIPv4 onlyなら、IPv6 Directは利用できません。
つまりIPv6 Directは、
条件が揃えば非常にシンプルだが、Home側とRemote側の双方にIPv6到達性が必要
という方法です。
クラウドVPCの場合も「どうPrivate Networkへ入るか」が必要
クラウドVPCは、Private Networkそのものを作るのは比較的簡単です。
しかし、
VPCを作っただけでは、外出先のPCからそのPrivate Networkへ入れるわけではありません。
一般的には、
VPN Gateway
WireGuard Gateway
Site-to-Site VPN
Bastion Host
Zero Trust系のRemote Access
などを用意します。
構造としては、
Remote
↓
VPN / Gateway
↓
Cloud VPC
↓
Private Resources
となります。
つまり、自宅LANとクラウドVPCでは実装方法は違っても、問題の本質は似ています。
Private Networkは作れても、Remoteからそこへ到達する経路は別途設計する必要がある
ということです。
自宅LANとクラウドVPCを「別々の島」と考えない
ここで、自宅LANとクラウドVPCを別々の場所として考えるのをやめてみます。
たとえば、
Remote
│
▼
Private Network
┌────┴────┐
▼ ▼
Home LAN Cloud VPC
という考え方です。
自宅には、
NAS
開発PC
GPUマシン
クラウドには、
検証サーバー
DB
管理用サービス
がある。
Remote端末は、それぞれをInternetへ公開するのではなく、Private Network経由で必要な場所へアクセスする。
この記事でいう「デジタル秘密基地」は、特別な製品や技術の名前ではありません。
自宅とクラウドに分散したPrivate Networkを、自分が必要な場所から使える1つのネットワークとして考える
という設計思想の比喩です。
DIYならVPSをHubにする方法もある
この構成は、特定のVPNサービスを使わなくても作れます。
たとえばPublic IPを持つVPSを1台用意し、そこをWireGuard Hubにします。
Remote
│
▼
VPS Hub
/ \
/ \
▼ ▼
Home LAN Cloud VPC
Home側はVPSへ接続する。
Cloud VPC側もVPSへ接続する。
Remote端末もVPSへ接続する。
こうすれば、RemoteからHome Public IPv4へ直接接続する必要はありません。
Home側から見ると、
Home
↓
Outbound
↓
VPS Hub
となるため、Home側へのInboundを前提にしない構成にできます。
これは技術的には十分DIY可能です。
一方で、自分で構築するなら、
WireGuard設定
Routing
Firewall
NAT
Key管理
DNS
Hub Serverの更新
障害時の復旧
VPS料金やegress料金
なども自分で管理することになります。
「作れるか」と「長期間運用したいか」は、別の問題です。
1つにつないでも、全部へアクセスできるようにする必要はない
ここで重要なのが、到達範囲です。
自宅LANとクラウドVPCをPrivate Networkでつないだからといって、Remote端末からすべてのSubnetへ自由にアクセスできるようにする必要はありません。
たとえば、
Remote Laptop
│
├── Home NAS Subnet Allow
│
├── Development Subnet Allow
│
└── Other LAN Subnet Deny
という設計もできます。
VPNは「通信経路」を作ります。
しかし、
その経路を使って、どこまで到達してよいか
は別の問題です。
そのためPrivate Networkを設計するときは、
Authentication
MFA
Firewall
LAN ACL
Cloud側のSecurity GroupやFirewall
なども組み合わせて考えます。
特に、
VPNへ接続できた = LAN全体へアクセスしてよい
とは限りません。
HomeGrid VPNでもLAN ACLを使い、到達を許可するSubnetを制御できます。
VPNを単なる「暗号化された土管」として終わらせず、必要なネットワークだけへ到達させるという考え方が重要になります。
Hub & SpokeならHome側へのInboundを前提にしなくてよい
ここまでのDIY構成を整理すると、1つ重要な考え方が見えてきます。
従来型の自宅VPNは、
Remote
↓
Internet
↓
Home
と、RemoteからHomeへ入っていきます。
一方、Hub & Spokeでは、
Remote ───► Cloud Hub ◄─── Home
のように、それぞれが中央のHubへ接続します。
Home側からCloud HubへOutboundで接続しておけば、RemoteからHome Public IPv4へ直接パケットを届ける必要がありません。
そのためHome側では原則として、
IPv4 Port Forward
DDNS
Remote → Home Public IPv4のDirect接続
Remote → Home Global IPv6のDirect接続
を前提にしない設計にできます。
CGNATやIPv4 over IPv6環境だからといって、必ずこの方式を使わなければならないわけではありません。
Public IPv4が使えるならDirect WireGuard。
双方にIPv6接続性があるならIPv6 Direct。
自分で運用したいならVPS Hub。
それぞれ選択肢があります。
Hub & Spokeは、その中の
「Home側へのInbound条件をなくす」
という別の設計思想です。
HomeGrid VPNもHub & Spoke型
HomeGrid VPNもHub & Spoke型の構成を採用しています。
Home側とRemote側はCloud Hubへ接続します。
Remote
│
▼
Cloud Hub
│
▼
Home
Home側はCloud HubへのOutbound通信を利用するため、自宅Routerで外部からのVPN接続を直接待ち受けることを前提にしません。
ここで注意したいのは、
Cloud Hub = Internet Exitではない
ことです。
たとえばHomeをInternet Exitとして利用する場合、通信経路は、
Remote
│
▼
Cloud Hub
│
▼
Home
│
▼
Residential ISP
│
▼
Internet
となります。
Internetへの出口はHome側です。
そのため接続先から見えるPublic IPも、Cloud HubのデータセンターIPではなくHome側の回線になります。
Cloud Hubは通信経路上に存在しますが、Internetへの出口とは役割が異なります。
Homeだけでなく、クラウド側もPrivate Networkとして考える
この考え方を広げると、
Remote
│
▼
Cloud Hub
/ \
/ \
▼ ▼
Home LAN Cloud VPC
という構成を考えられます。
VPC側では、Private Networkへ接続するGatewayとなるホストを用意し、そこから対象Subnetへの経路を構成します。
するとRemoteから見れば、
自宅NAS
自宅開発環境
クラウド上の検証環境
管理用Server
などが、「Internetへ公開された別々のServer」ではなく、
Private Networkの先にあるResource
として扱えるようになります。
ただし、ネットワーク同士を接続したからといって、すべてのResourceを相互到達可能にする必要はありません。
Home側ではLAN ACL、クラウド側ではSecurity GroupやFirewallなどを使い、用途に応じて到達範囲を制御する設計が重要です。
では、どの方法を選べばいいのか
ここまでの方法を整理すると、それぞれ向いている環境が違います。
Public IPv4 + WireGuard Direct
Remote
↓
Home
シンプルです。
Public IPv4があり、Port Forwardできるなら有力な選択肢です。
IPv6 Direct
Remote IPv6
↓
Home IPv6
IPv4 Port Forwardは不要です。
ただし双方にIPv6接続性があり、IPv6 Firewallを適切に設定できることが条件です。
VPS HubをDIY
VPS
/ \
Remote Home
Home側へのInboundを避けられます。
その代わりHub ServerやRouting、Firewallなどを自分で運用します。
Hub & Spoke型サービス
Cloud Hub
/ \
Remote Home
Hubの運用や接続管理までサービス側に任せたい場合の選択肢です。
HomeGrid VPNはこの方式です。
重要なのは、
どれが唯一の正解かではなく、自分の回線条件と運用条件にどれが合うか
です。
「どこに置くか」より「どうつなぎ、どこまで許可するか」
自宅LANとクラウドVPC。
物理的にはまったく違う場所にあります。
しかしネットワーク設計では、どちらもPrivate Resourceを置く場所として考えることができます。
そのうえで比較すべきなのは、
RemoteからInboundするのか
OutboundでHubへ接続するのか
Direct接続を使うのか
Hubを自分で運用するのか
どのSubnetまで到達を許可するのか
Internet Exitをどこにするのか
です。
自宅LANとクラウドVPCを1つにつなぐこと自体が目的ではありません。
必要な端末から、必要なPrivate Networkだけへ到達できる経路を作る。
そこまで含めて設計すると、VPNは単なる「暗号化された土管」ではなく、分散したPrivate Networkを扱うための基盤になります。
