NuroのMAP-E化で詰んだ自宅公開WEBサーバをVPN（WireGuard）経由で完全復旧した話

2025年5月21日 05:28

■ はじめに

Note書くのは久しぶりです。今回はタイトルのお話です。

自宅の光回線が不調になり、Nuro光のONUIルータが原因と判明。サポートに依頼し、ルータ交換を依頼したが、ここで機種がこれまでのHG8045QからSGP200Wへと変更となった。
これによりNuroのネットワーク構成が「デュアルスタック（IPv4/IPv6）」から**MAP-E（IPv4 over IPv6, DS-Lite）**へと自動的（強制的に）に切り替わりました。

この「MAP-E」方式は、従来のように自宅ごとに専用のグローバルIPv4アドレスが割り当てられず、プロバイダ側で多数ユーザーの通信をひとまとめにして“共有グローバルIP”でインターネットに接続する仕組みです（いわゆる“キャリアグレードNAT”）。

その結果、筆者の自宅Webサーバに外部からアクセスできなくなりました。（MAP-Eはポート開放も不可、サーバ公開もほぼ機能しない）

ルータ交換後、設定のために管理画面にログイン。DMZ設定およびポートマッピング設定で「MAP-E機能動作中のため本機能は設定できません」との表示。これで「外部から自宅のWebサーバにつながらない」ことを理解。MAP-E特有の**“NAT越え不能・グローバルIP未割当”**問題に直面。サーバ運用者なら一度は遭遇する「公開不可」という“詰み”状態に陥りました。

■ “疑似グローバルIP”公開の鍵は「GCPの無料枠（米国リージョン）」だった

自宅サーバ公開を復旧させるため、Google Cloud Platform（GCP）の無料枠（Free Tier）──米国リージョンの最小スペックVM（f1-micro）を活用。
これでコストをかけずに「固定グローバルIP付きの公開用サーバ」を用意し、このVPNサーバを経由することで再び外部公開が可能となりました。
こちらのWEBサイトです。

■ サーバ公開“詰み”からの再構築ロードマップ

1. まずはAWS S3で“静的サイト”として退避

ルータ設定の際にWEBサーバ公開不能に気付いたタイミングで、急遽「**静的サイトとしてS3に逃がす」**作戦を決行。
S3は手軽・堅牢だが、そのままではSSL（HTTPS）が使えないため、独自ドメイン＋HTTPSの運用が困難。

2. CloudFront導入でSSL＆高速配信に対応

S3直アクセスではSSL不可なため、AWS CloudFront（CDN）をS3前段に設定。
CloudFront経由でSSL証明書自動発行＋HTTPS公開を実現。
DNS（Route53）でA/CNAMEレコードをCloudFrontに切替。

3. 静的サイト化プラグインが使えず、独自スクリプトでS3転送・文字化けも手作業で回避

本来はWordPressの「Simply Static」等のプラグインで一括静的出力したかったが、環境依存や大量記事でエラー多発、断念。
結局、自作スクリプトで公開ディレクトリをS3に手動同期。
ここで日本語ページや画像の文字化け発生。
　- S3アップ時に「Content-Type: text/html; charset=utf-8」をスクリプトで明示。
　- ファイル名もURLエンコードで統一し、表示崩れを防止。

＜構成＞
インターネット
|
v
[ CloudFront (CDN, SSL対応) ]
|
v
[ AWS S3 (静的サイト, 文字コード/エンコード対策済) ]

■ 恒久対策：「GCP＋WireGuard＋Nginx＋HAProxy」で自宅サーバを復活

1. GCPに「公開用サーバ（リバースプロキシ）」を新設（無料枠／米国リージョン）

パブリックIP・必要なポート（UDP 51820, TCP 80/443）を開放。
GCPの「無料枠（Free Tier）」を利用することで、サーバ費用はほぼゼロ。

2. GCPと自宅サーバ間にWireGuard VPNトンネルを構築

GCPサーバと自宅サーバが仮想的に同一ネットワークに。
自宅側のWireGuardクライアントにはこれまで利用していたHAProxyのサーバを中継として挟むことで、
　Nginx（GCP）→WireGuard→HAProxy（自宅）→OpenLiteSpeedのリバースプロキシ構成を実現。

3. GCP側Nginxでリバースプロキシ設定

GCPグローバルIPへのアクセスをWireGuard越しで自宅のHAProxyへ中継。
HAProxyが各種リクエストをOpenLiteSpeedサーバに振り分け。

4. SSL証明書（Let’s Encrypt）はOpenLiteSpeed側で運用

外部からのリクエストはGCP-Nginxで一度受けたあとWireGuardトンネルを経由して自宅へ。
SSL終端はOpenLiteSpeedで完結させているため、GCP側はリバースプロキシのみ。

5. DNS（Route53）でAレコードをGCPグローバルIPに変更

AWS Route53で全ドメイン管理を一元化。

■ なぜこの構成で自宅サーバ公開ができるのか？

独自ドメインはRoute53上で管理。GCP（無料枠）のグローバルIPをAレコードに設定。GCPが“公開窓口”となり、インターネット経由のアクセスを受付。
WireGuard（VPN）でGCPと自宅LANが内部IPで安全に直結。
GCP-Nginxは「公開窓口」、HAProxyで細かいリクエスト制御、最終的にOpenLiteSpeed（自宅サーバ）に到達。
SSLは自宅サーバ側（OpenLiteSpeed）で完結しているため、証明書管理もシンプル。

■ 運用Tips・注意点

SSL証明書（Let’s Encrypt）はOpenLiteSpeed側で自動取得・更新。
GCPコストは無料枠・microプラン活用で実質ゼロ運用が可能。
自宅サーバはグローバル公開不要、セキュリティも向上。
Route53管理なら複数ドメインの一元化も容易。
静的サイト退避時は**「ファイル名のエンコード」「文字コード・Content-Type」指定**も要チェック。

■ エピソード：プラグイン断念、自作スクリプトで地道に転送

ルータ交換後しばらくして「外から自宅サイトが見えない」ことに気付く。
WordPress静的化プラグインではうまく変換できず、独自スクリプトでS3に手動転送＆Content-Type修正を地味に繰り返す日々。
CloudFrontとRoute53連携でSSLも維持し、Web公開はギリギリ継続。
最終的にはGCP無料枠＋WireGuard＋Nginx＋HAProxy＋OpenLiteSpeedという「現代的で安全な公開経路」を獲得できた。

■ まとめ：MAP-E時代の“自宅サーバ運用”生存戦略

IPv6＋MAP-E時代、従来方式の自宅サーバへのダイレクト公開は消滅に近い。でもGCP/AWS/VPS＋VPNトンネル＋Nginx＋HAProxy＋OpenLiteSpeed＋Route53という組み合わせで
「疑似グローバルIP・SSL化・マルチドメイン」全て維持し続ける道はある。

同じ悩みを持つ方のヒントや勇気になれば幸いです。