逆向思维による家庭WinNASの安全な外部ネットワークアクセスの実現：CDNポート削除 + HTTPS暗号化ソリューションと見落とされがちなリスク

前回の家庭ストリーミングソリューション - Jellyfin：私🈶独自の使用方法 - zfsjlll の自留地でストリーミングをいじった後、私の WinNAS は実家に長期設置されました。ネットワーク環境やプロバイダーのサービスの変化により、家の回線は 1Gbps から 300Mbps に変わり、動的なパブリック IPv4 がなくなったため、リモートアクセスの計画を再設計する必要がありました。
（以前の計画は Cloudflare CDN オープンポート - zfsjlll の自留地を参照）

1. ニーズシナリオと痛点の分析#

家庭 NAS のリモートアクセスの典型的な困難：
- 動的パブリック IP の安定性の問題
- プロバイダーによる 80/443 ポートのブロックの厄介さ
- HTTP の平文送信のセキュリティリスク

ユーザーログインのシミュレーション

  リクエストURL：http://vulnerable-site.com/login
  フォームフィールド：username=admin&password=123456

Wireshark で HTTP パケットをキャプチャし、プライバシーが漏洩する

POST /login HTTP/1.1
Host: vulnerable-site.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 28

username=admin&password=123456

2. 技術的ソリューションの全景図#

[ユーザーブラウザ] --HTTPS(443)--> [CDNノード] --HTTP(カスタムポート)--> [リバースプロキシサーバー] --> [WinNASサービス]

主要技術コンポーネントの説明：
- CDN はもちろん、サイバー大善人 Cloudflare を選択します。個人のウェブマスターに非常に優しく、いくつかの技術的なハードルがありますが、すでに無料ですので、他に何が必要でしょうか（笑）
- リバースプロキシは一般的な Nginx/Caddy を使用せず、最近 Lucky が NAS 界隈で特に人気があります。以下の機能を実現できます：ソフトハードルーターのパブリック神器、IPv6/IPv4 ポート転送、リバースプロキシ、DDNS、WOL、IPv4 STUN 内部貫通、cron、acme、アリババクラウドドライブ、FTP、WebDAV、filebrowser。機能は十分であり、初心者にも非常に優しい、グラフィカルなインターフェース操作、公式サイト：Lucky

3. 実戦デプロイメントステップ#

3.1 基本ネットワークアーキテクチャの構築
具体的なデプロイメントチュートリアルはインターネットで検索できますが、ここでは実用的な内容だけを話します。全て進化したプレイです。

動的ドメイン名解決の計画（Lucky ツールを Windows サービスに静かにデプロイ）
リバースプロキシの設定（引き続き Lucky）
DDNS とリバースプロキシモジュールの他にも、ポート転送、リモートネットワークウェイクアップ、ネットワークストレージ（WebDAV、FTP などのプロトコルのサーバー実装、私はすでに Alist をデプロイ済みで、今は必要ありません）など、非常に多くの実用的な機能を探求できます。（ソフトルーターの ALL IN ONE に似ていますか？私はソフトルーターをデプロイしたことがないので、間違っていたら指摘してください）

3.2 CDN 層のセキュリティ改造

ポート隠蔽術：CDN の「ページルール」を通じて URL リダイレクトを実現（Cloudflare を例に）：
1. ルールを作成して実現：*.yourdomain.com/* → http://nas.yourdomain.com:yourport$1に転送

ルール-ルールを作成画像の説明

テンプレート-ポートを変更

カスタムフィルタ式を設定し、最初のルールでワイルドカードを選択してすべてのサブドメインにマッチさせ、個別のニーズがあればルールを追加します。図の中の jellyfin サービスはリダイレクトを行わず、「CDN の速度低下」を避けます。

表現式

最後に、リダイレクトが必要なドメインに「小さな雲」をオンにするだけです。

Always Use HTTPS を有効にして強制リダイレクト

SSL 証明書の自動化：
- acme を使用して Let's Encrypt のワイルドカード証明書を申請
- 証明書の自動更新
- 証明書の申請が失敗した場合、プロキシの設定が必要な場合があります

3.3 攻撃面の縮小戦略

IP ホワイトリストの強化：CDN ファイアウォールを通じてソースサイトへのアクセスを制限（CDN ノード IP のみ許可）

# Windowsファイアウォールの受信ルール（管理者PowerShell）
New-NetFirewallRule -DisplayName "Allow_CDN_IPs" -Direction Inbound -LocalPort 8765 -Protocol TCP -Action Allow -RemoteAddress 173.245.48.0/20,103.21.244.0/22

プロトコルのセキュリティ強化：
- TLS 1.0/1.1 を無効にする
  Lucky で TLS の最小バージョンを TLS1.2 に設定するだけです
- HSTS ヘッダーを設定

リバースプロキシモジュールに応答ヘッダーを追加

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";

preload オプションを設定する前に詳細を理解することをお勧めします。すべてのサブドメインが HTTPS に準拠している必要があり、一度でも HTTPS に準拠していないサブドメインが見つかると、削除プロセスは非常に遅く、苦痛です。

4. 読者とのインタラクションセクション#

オープンディスカッション：
"物理サーバーリソースがある場合、WireGuard を使用して VPN トンネルを構築しますか？なぜですか？"

5. 技術的詳細の強化提案#

トラフィック偽装のテクニック：CDN 設定に偽装の/health-checkパスを追加し、虚偽の 404 ページを返してスキャナーを混乱させる
fofa などのスキャナーの脅威に対処する：リバースプロキシのデフォルトルールを「接続を閉じる」に設定、詳細は：Windows で Lucky を使用してリバースプロキシを設定し、安全な WEB アクセスを実現する - 哔哩哔哩