🧠 概要：
概要
この記事は、Nuro光のルーター交換に伴い、MAP-E方式に切り替わり、自宅のWebサーバへのアクセスができなくなった著者が、VPN（WireGuard）を使用して自宅サーバを復旧させる過程を詳細に説明しています。最終的には、Google Cloud Platform（GCP）を使用して公開用サーバを構築し、WireGuardトンネルを介して自宅サーバを安全に接続する手法が紹介されています。
要約（箇条書き）
- Nuro光のルーター交換後、MAP-E方式に切り替わり、自宅のWebサーバに外部からアクセスできなくなった。
- MAP-Eは、プロバイダ側で多数のユーザーの通信をまとめる仕組みで、固定グローバルIPが割り当てられない。
- 自宅サーバの公開不能状態に直面し、Google Cloud Platformの無料枠（米国リージョン）を利用して新たにサーバを構築。
- AWS S3を使用して一時的に静的サイトへ移行し、CloudFrontでSSLを設定。
- GCPのVMをリバースプロキシとして設定し、WireGuardで自宅サーバと接続。
- HAProxyがリクエストを自宅サーバのOpenLiteSpeedに振り分け、SSL証明書はOpenLiteSpeedで管理。
- Route53でドメイン管理を行い、複数ドメインも容易に運用可能に。
- 現代的なシステム構成により、自宅サーバ公開を再実現。
書くのは久しぶりです。今回はタイトルのお話です。
自宅の光回線が不調になり、Nuro光のONUIルータが原因と判明。サポートに依頼し、ルータ交換を依頼したが、ここで機種がこれまでのHG8045QからSGP200Wへと変更となった。
これによりNuroのネットワーク構成が「デュアルスタック（IPv4/IPv6）」から**MAP-E（IPv4 over IPv6, DS-Lite）**へと自動的（強制的に）に切り替わりました。
この「MAP-E」方式は、従来のように自宅ごとに専用のグローバルIPv4アドレスが割り当てられず、プロバイダ側で多数ユーザーの通信をひとまとめにして“共有グローバルIP”でインターネットに接続する仕組みです（いわゆる“キャリアグレードNAT”）。
その結果、筆者の自宅Webサーバに外部からアクセスできなくなりました。（MAP-Eはポート開放も不可、サーバ公開もほぼ機能しない）
DMZ設定は不可
ポートマッピング設定は不可
ルータ交換後、設定のために管理画面にログイン。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に変更
＜構成＞インターネット|v[ GCP (無料枠VM, 米国リージョン) ]| (Nginxリバースプロキシ)v===[ WireGuard VPNトンネル ]===v[ 自宅サーバ群 ]├─> [ HAProxy (中継) ]| || v| [ OpenLiteSpeed ]
| (WordPress, SSL終端)
■ なぜこの構成で自宅サーバ公開ができるのか？
-
独自ドメインは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化・マルチドメイン」全て維持し続ける道はある。
同じ悩みを持つ方のヒントや勇気になれば幸いです。
Views: 0
