Lucky STUN + Cloudflare 302 実践：動的な公開ポートを固定ホスト名から開く

本稿の中心は通常の DDNS ではなく、任意の STUN ポートを Cloudflare のリバースプロキシへ通す方法でもありません。Lucky が STUN で 公開 IP:動的ポート を取得し、マッピングの変更時に Webhook で Cloudflare Single Redirect の転送先を更新する構成です。

利用者が覚えるのは go.example.com だけです。ブラウザーは最初に Cloudflare へアクセスして一時リダイレクトを受け取り、その後は現在の STUN エンドポイントへ直接接続します。参照記事の 301 と同じ発想ですが、本稿では 302 を使います。NAT マッピングは一時的な値であり、ブラウザーや検索エンジンに恒久的な移転先として記憶させるべきではありません。

本稿は Lucky 2.27.2 と Cloudflare Dashboard の実画面を使い、双方の公式ドキュメントで仕様を照合しています。文章中の例には example.com、192.0.2.0/24 など文書用の値だけを使用します。実写画像には実際のドメイン、IP、ポート、インスタンス名、通信量、Token を残さず、元の管理データがあった領域は不可逆な強いぼかしで処理しました。

結論：ブラウザー用の一時入口には 301 ではなく 302 を使います。Cloudflare Single Redirect が現在正式に対応するのは 301、302、307、308 で、303 は利用できません。アプリ、API、リモートデスクトップ、非 HTTP プロトコルには、307、Cloudflare Tunnel、VPN、またはプロトコル固有の転送方法を検討します。

実際のリクエスト経路

最初のリクエスト

ブラウザーが https://go.example.com/photos?id=42 を開く
  └─ Cloudflare Single Redirect が 302 を返す
       Location: http://203.0.113.10:45678/photos?id=42
        └─ ブラウザーが STUN マッピングへ直接接続
             └─ Lucky 内蔵転送（またはルーターのポート転送）
                  └─ 内部 Web サービス

マッピングが変わったとき

Lucky が 203.0.113.10:51234 を取得
  └─ STUN Webhook が Cloudflare Rulesets API を PATCH
       └─ 次回アクセスから新しい Location を返す

ここでいう「ポートなしのドメインアクセス」は、利用者が最初に入力する URL にポートがないという意味だけです。転送後のアドレスバーには実際の IP または転送先ホスト名とポートが表示されます。Cloudflare が処理するのは最初のリクエストだけであり、アプリ通信は Cloudflare を通りません。したがって WAF、Cache、Access、オリジン隠蔽は2本目の接続を保護しません。

経路1：Lucky STUN を設定する

1. 最初にネットワーク条件を確認する

Lucky の STUN 公式ドキュメントは対象環境を NAT1 と説明し、公開ポートが固定される保証はなく、変更間隔にも規則性がないと明記しています。NAT タイプの呼び方は製品によって異なるため、ルーターに表示された文字だけで判断せず、Lucky のルールログと外部回線からの実接続で確認します。

ルールを作る前に、次を確認します。

1. ONU/光モデム側で接続している場合、Lucky の案内どおり DMZ をメインルーターへ向けます。ルーター側で接続している場合は不要です。
2. Lucky をメインルーターで動かす構成が最も単純です。LAN 内ホストで動かす場合は、メインルーター側でも UPnP、ポート転送、または慎重に限定した DMZ が必要です。
3. OS カーネルとファイアウォールが対象の TCP/UDP 動作を許可しているか確認します。プロキシ、二重 NAT、マルチ WAN は結果を変えることがあります。
4. 最初の公開テストに Lucky の管理画面を使わないでください。機密データがなく、すぐ停止できるテストサービスを使います。

2. STUN モジュールを有効化する

次の画面を開きます。

Lucky → イントラネット貫通 → STUN → 設定

モジュールを有効化し、グローバル STUN サーバー一覧を確認します。画面には公開の動作確認済み STUN ホスト一覧へのリンクがあります。数が多ければ安定するとは限りません。自分の回線から到達でき、実際にテストしたサーバーを残し、出所不明の一覧を本番環境へ一括投入しないようにします。

⌕ クリックしてプレビュー

実画面のキャプチャです。公開 STUN サーバーのアドレスだけを含み、プライベートネットワーク値や認証情報はありません。

Webhook は公開マッピングの変化を外部システムへ通知できます。具体的な自動化が必要な場合だけ有効にし、URL、ヘッダー、本文に含まれる秘密情報がログやスクリーンショットへ入らないようにします。

3. 最初のルールはシンプルモードで作る

貫通ルール一覧で「ルールを追加」を選び、初回テストはシンプルモードを使います。

⌕ クリックしてプレビュー

フォームは空欄です。背景の実ルール名、IP、ポート、通信量は不可逆な強いぼかしで処理しました。

完全に架空の TCP 例です。

貫通タイプ：IPv4-TCP
ローカルチャネルポート：12080
転送先アドレス：192.0.2.10
転送先ポート：8080

192.0.2.10:8080 は RFC 5737 の文書用アドレスであり、チュートリアル用の値です。実際の内部 IP とポートは、スクリーンショットやログを公開する前にセットで隠してください。この組み合わせだけでサービスを推測できる場合があります。

4. 根拠なくカスタムモードを調整しない

Lucky 2.27.2 のカスタムモードには、IP/インターフェース固定、IP 許可・拒否、TCP 接続数、UDP セッション数、暗号化、STUN 待機時間、ハートビート間隔、再試行、ログなどがあります。これらは相互に関係し、ある環境の初期値を別の環境へコピーする根拠にはなりません。

再現可能な理由がある場合だけ変更します。

• マルチ WAN やポリシールーティングでのみ、IP やインターフェースを固定する。
• 接続数と UDP セッション数は、サービスの同時利用数と機器資源に合わせて上限を設ける。
• 待機、ハートビート、再試行は一度に1項目だけ変え、変更前後のログを残す。
• 自動再試行は可用性を高める一方、誤設定による通信を継続させることもある。
• TLS やストリーム暗号化は、アプリ側の認証・認可の代わりにはならない。

5. 実際の外部回線でテストする

保存後はルール固有のログを確認します。続いて Wi-Fi を切り、モバイル回線または別の固定回線から接続し、少なくとも次を確認します。

1. Lucky が公開マッピングを取得したか。
2. 外部接続がルールログに現れるか。
3. ファイアウォールまたはルーターが正しい Lucky ポートへ転送したか。
4. サービスが期待したアドレスとネットワーク名前空間で待ち受けているか。
5. 公開ポート変更時に、クライアントや自動化へ新しい値を伝えられるか。

ログに外部からの試行が一切ない場合は、転送先サービスを何度も変える前に、ISP の NAT、モデム/ルーターのマッピング、ファイアウォールを調べます。

中心となる構成：Cloudflare 302 で STUN の動的ポートを追従する

STUN が返すのは公開 IP と公開ポートです。A/AAAA レコードが保存できるのは IP だけで、通常のブラウザー URL にポートを動的に付加できません。参照構成の要点は、DNS が固定入口を Cloudflare まで届け、現在の IP:ポート をリダイレクトレスポンスの Location に保存し、Lucky Webhook がそれを更新し続けることです。

1. 301 や 303 ではなく 302 を選ぶ理由

Cloudflare の Single Redirect 設定が現在列挙するのは 301、302、307、308 です。Cloudflare の一般的な 3xx 文書が 303 の HTTP 意味を説明していても、Rulesets API の http_request_dynamic_redirect が 303 を受け付けることにはなりません。以下の JSON を status_code: 303 に変更すると、API 検証で拒否される可能性があります。

303 が必須なら Cloudflare Worker または自分のオリジンで生成します。それは Single Redirect とは別の設計です。通常のブラウザー GET ページには 302 を使い、POST/PUT 本文を維持すべき API は、単純に 307 へ置き換える前に構成自体を再検討します。

2. 入口と直接接続先を別ホスト名にする

Cloudflare は Single Redirect の対象となる受信ホスト名がプロキシされていることを要求します。そのため go.example.com はオレンジクラウドにします。ルールが一致すれば、レコードのオリジンへ接続する前に 302 を返します。一致しない通信はオリジンへ進む可能性があるため、ホスト名全体を確実に対象にし、漏れたリクエストが管理画面へ届かず安全に失敗するようにします。

転送先には2つの形があります。

最も単純： http://公開IP:動的ポート/path
HTTPS 向け： https://origin-direct.example.com:動的ポート/path

HTTPS の IP へ直接転送すると、証明書のホスト名検証に失敗しやすくなります。HTTPS では Lucky DDNS で DNS only の転送先を更新し、origin-direct.example.com を含む証明書を用意します。どちらの場合も2本目の接続では IP とポートが公開され、Cloudflare WAF と Access を経由しません。

3. Cloudflare に 302 Dynamic Redirect を作成する

次を開きます。

Cloudflare Dashboard → 対象 Zone → Rules → Redirect Rules
→ Create rule → Single Redirects

まずプレースホルダールールを作ります。

ルール名：Lucky STUN temporary redirect
一致式：(http.host eq "go.example.com")
タイプ：Dynamic
転送先式：concat("http://192.0.2.10:12080", http.request.uri.path)
ステータス：302
クエリ文字列を保持：有効

192.0.2.10 は文書用アドレスです。このルールは Cloudflare に ruleset と rule ID を作らせるためのもので、実接続先ではありません。デプロイ後は curl -I で 302 を確認し、Location にパスとクエリが保持されているか調べます。

4. 最小権限の API Token を作成する

Lucky 専用 Token を作ります。

Permissions：Zone → Single Redirect → Edit
Resources：Include → Specific zone → example.com

Global API Key を使わず、DNS、Workers、アカウント管理などの不要な権限を加えません。この Token は公開入口の転送先を変更できるため、漏えいするとフィッシング転送に悪用されます。

Webhook には秘密ではない3つの識別子、ZONE_ID、動的リダイレクトの RULESET_ID、対象の RULE_ID も必要です。Dashboard でルールを編集する際のリクエストから確認するか、API で Zone ruleset を一覧し、phase が http_request_dynamic_redirect の項目とそのルールを読み取ります。公開スクリーンショットではこれらもマスクする方が安全です。

5. Lucky のルールに Webhook を設定する

対象 STUN ルールを編集して Webhook を有効化します。Dashboard 内部の /api/v4/ URL ではなく、公開 API を使います。

URL：
https://api.cloudflare.com/client/v4/zones/<ZONE_ID>/rulesets/<RULESET_ID>/rules/<RULE_ID>

メソッド：PATCH

ヘッダー：
Authorization: Bearer <CLOUDFLARE_API_TOKEN>
Content-Type: application/json

302 のリクエスト本文：

{
  "action": "redirect",
  "description": "Lucky STUN temporary redirect",
  "enabled": true,
  "expression": "(http.host eq \"go.example.com\")",
  "action_parameters": {
    "from_value": {
      "status_code": 302,
      "target_url": {
        "expression": "concat(\"http://#{ipAddr}\", http.request.uri.path)"
      },
      "preserve_query_string": true
    }
  }
}

STUN Webhook 実行時、Lucky は #{ipAddr} を現在の公開アドレスとポートへ置換します。Cloudflare には次のような式が保存されます。

concat("http://203.0.113.10:45678", http.request.uri.path)

DNS only の転送先ホスト名と HTTPS を使う場合、Lucky DDNS でそのホスト名を更新し、式を次のようにします。

"expression": "concat(\"https://origin-direct.example.com:#{port}\", http.request.uri.path)"

#{ipAddr} と #{port} は Lucky Webhook のテンプレート変数であり、Cloudflare Rules 言語の変数ではありません。半角の引用符を使い、JSON 内部の式の引用符にはバックスラッシュのエスケープを残します。

成功判定文字列：

"success": true

レスポンスの整形によって空白が入る場合があります。手動実行が1回成功しただけで長期運用可能と判断せず、Lucky の Webhook ログと Cloudflare API レスポンスを確認し、ルールを再取得して実際に転送先が変わったことを検証します。

6. 別回線から経路全体を検証する

モバイル回線などから最初の応答を調べます。

curl -sS -D - -o /dev/null "https://go.example.com/photos?id=42"

期待する主要部分：

HTTP/2 302
location: http://203.0.113.10:45678/photos?id=42

続けて次を確認します。

1. 古いルールの 301 ではなく 302 である。
2. Location の IP、ポート、パス、クエリが正しい。
3. STUN マッピング更新後、Webhook が新しいポートを公開する。
4. シークレットウィンドウと別端末が恒久リダイレクトのキャッシュを使っていない。
5. 直接公開サービス自体に認証、レート制限、総当たり対策、TLS がある。

curl -I は HEAD のみを検証し、サービスによっては GET と動作が異なります。上記の -D - -o /dev/null は GET を送りつつ、非公開の本文を端末へ出力しません。

7. 302 構成では解決しないこと

• ポートを本当に隠すものではなく、アドレスバーと Location に表示される。
• 家庭回線の公開 IP を隠さず、利用者はそこへ直接接続する。
• アプリ、テレビクライアント、リモートデスクトップ、独自プロトコルへ HTTP リダイレクト対応を追加しない。
• 2本目のリクエストを Cloudflare WAF、Cache、Access の背後へ置かない。
• Cookie Domain、CORS、CSRF、絶対 URL、Host 検証、TLS 証明書を自動解決しない。
• HTTP/HTTPS の入口用であり、UDP セッションを HTTP 302 で確立することはできない。

Cloudflare Redirect は STUN ポート用のオレンジクラウドプロキシではありません。オレンジクラウドが処理するのは固定入口への最初の HTTP リクエストだけです。

代替案：Lucky で Cloudflare Tunnel を動かす

Web、API、管理画面では Cloudflare Tunnel の方が単純なことが多いです。cloudflared が内部から外向きに接続するため、公開 IP もルーターのインバウンドポートも不要です。仕組みは Cloudflare Tunnel 公式概要で確認できます。

1. Cloudflare でリモート管理 Tunnel を作る

Cloudflare Dashboard で次を開きます。

Networking → Tunnels → Create a tunnel → Cloudflared

自宅住所、機器シリアル、個人名を含まない名前を付けます。作成後、Dashboard は Tunnel Token を含むインストールコマンドを表示します。Lucky に必要なのは Token の値だけです。コマンド全体のスクリーンショットや長期保存は避けます。

⌕ クリックしてプレビュー

実画面のキャプチャです。名前は未入力で、Token は生成されず、Tunnel の作成も実行していません。アカウントのサイドバーは折りたたまれています。

Tunnel Token は新しい cloudflared コネクターをその Tunnel へ参加させられるため、パスワードとして扱います。

• Markdown、シェル履歴、Git、Dockerfile、公開環境変数へ書かない。
• ブラウザー側コードへ渡さない。
• Tunnel ごとに別の Token を使う。
• 漏えい時は Tunnel 詳細で Token を更新し、古い接続を削除する。Cloudflare も定期的な Tunnel Token のローテーションを推奨しています。

2. Lucky に Tunnel インスタンスを追加する

次を開きます。

Lucky → イントラネット貫通 → Cloudflared → インスタンスを追加

「Tunnel」モードを選び、次を設定します。

⌕ クリックしてプレビュー

Tunnel Token と API Token は空欄です。背景の既存インスタンス情報は不可逆な強いぼかしで処理しました。

Lucky からアプリケーションルートと DNS を自動管理する場合は、Tunnel Token とは別の Cloudflare API Token を設定します。現在の Lucky 画面では次の権限が案内されています。

• Account → Cloudflare Tunnel → Edit
• Zone → DNS → Edit
• Account と Zone の範囲を実際に使う対象へ限定

自動管理が不要なら API Token を空欄にし、Cloudflare Dashboard 側でルートと DNS を管理できます。「All」を選ぶ便利さより、最小権限を優先します。

3. アプリケーションルートを追加する

Tunnel インスタンスの「Application routes」で、次のようなマッピングを追加します。

ホスト名：app.example.com
パス：/*
転送先サービス：http://192.0.2.10:8080

転送先サービスにはプロトコルが必要です。HTTP、HTTPS、TCP などの指定方法は Cloudflare Tunnel のルーティング文書を参照してください。一般的なブラウザー公開では HTTP/HTTPS の Published application route を優先します。非 HTTP の公開ホスト名はクライアント側にも cloudflared が必要になる場合があり、任意 TCP/UDP の公開プロキシには Spectrum またはプライベートネットワーク経路が必要な場合があります。

同一ホスト名に複数のパスルールがある場合、具体的なルールを catch-all より前に置きます。たとえば /api/* は /* より前です。広いルールが先に一致すると、後続ルールへ到達しません。

詳細設定は必要な場合だけ利用します。

• Origin Server Name：証明書のホスト名と転送先アドレスが異なる場合。
• Host ヘッダー：転送先が仮想ホストで振り分ける場合。
• HTTP/2 to origin：転送先が対応している場合だけ。
• 接続、TLS、keep-alive timeout：ログとサービス特性に基づいて調整。
• TLS 検証を無効化：一時的な切り分けに限定。Cloudflare も noTLSVerify を本番非推奨の最終手段としています。

4. CNAME を設定する

各 Tunnel には次の形式の転送先が割り当てられます。

<TUNNEL_ID>.cfargotunnel.com

app.example.com の CNAME をこの値へ向けます。Cloudflare Dashboard で Published application route を追加すると、通常は DNS レコードも自動作成されます。Lucky からルートを管理する場合、自動作成されるかは API Token と設定に依存します。保存後は DNS 画面で実際のレコードを確認します。

Tunnel UUID は Token と同じ認証秘密情報ではありませんが、インフラ識別子です。記事で実値を見せる利点はないため、同様に伏せます。

5. 管理画面を Cloudflare Access で保護する

Tunnel は転送先への経路を作りますが、「誰が利用できるか」を自動では決めません。管理画面、監視、個人向けサービスには Access アプリケーションを追加します。

Zero Trust → Access controls → Applications
→ Create new application → Self-hosted and private

Tunnel の公開ホスト名を登録し、メールアドレス、ID プロバイダー、端末状態、Service Token などを使った Allow ポリシーを作ります。Action、Include、Require、Exclude の構造は Access ポリシー公式文書で確認できます。

Access で保護する公開 URL はポート番号に依存させないでください。Cloudflare のポート文書によると、Access は URL のポート番号を除去します。外部には標準 HTTPS ホスト名を公開し、内部ポートは Tunnel の転送先だけに保持します。

トラブルシューティング

一度に変更する変数は1つにし、変更時刻を記録します。ログを共有する前に、公開/内部 IP、ポート、ホスト名、リクエストパス、Cookie、Authorization、Token、インスタンス名を削除します。

スクリーンショット公開前のプライバシーチェック

Lucky のルール一覧は情報量が多く、1枚で家庭内ネットワーク構成が見えることがあります。画像ごとに次を確認します。

• Lucky 管理画面のアドレス、ポート、非公開入口パス。
• 公開 IP、マッピングポート、内部 IP、転送先ポート。
• ドメイン、ホスト名、インスタンス名、ルール名、機器名。
• Tunnel Token、Cloudflare API Token、Access Service Token。
• Account ID、Zone ID、Tunnel UUID、CNAME 転送先。
• リクエストパス、Webhook URL、リクエストヘッダー。
• ログ、訪問者 IP、通信量、オン/オフ状態。
• ブラウザーのタブ、ブックマーク、プロフィール画像、メールアドレス。

Token の中央だけをぼかしても安全とは限りません。実値をすべて app.example.com、192.0.2.10、<TOKEN> に置き換えた再作図の方が安全です。

まとめ

少人数の信頼できる利用者向けブラウザー GET ページで、転送後の IP とポート公開を許容でき、NAT 条件を確認済みなら STUN + Cloudflare 302 を選べます。解決するのは「固定入口を1つ覚える」ことであり、リバースプロキシ、セキュリティゲートウェイ、本当のポート隠蔽ではありません。

メソッド維持が必要なら、クライアントを検証してから 307 を検討します。Single Redirect の JSON に 303 を入れないでください。303 が必須なら Worker またはオリジンで生成し、動的転送先の保存と認証を別途設計します。

標準 HTTPS ホスト名を維持し、Access や WAF を使いたい Web/API には Cloudflare Tunnel を選びます。STUN の成功に依存せず、NAT マッピングが変わっても公開 URL は変わりません。

直接 TCP/UDP、短い通信経路が重要で、Lucky の STUN 条件を満たし、公開ポートの変化、DNS only による転送元の直接公開、認証とファイアウォールの自己管理を受け入れられる場合は STUN を選びます。

STUN 直接接続、STUN + 302 の入口、Cloudflare Tunnel はいずれも内部サービスを公開できますが、アプリ通信が Cloudflare の経路に残るのは最後の方式だけです。301 のリクエスト本文をコピーする前に、プロトコル、クライアント動作、セキュリティ境界を決めます。

参考資料

• Lucky：STUN による NAT 越え
• Lucky：Cloudflare Tunnel
• Lucky：Dynamic DNS
• 参照した方式：Lucky STUN + Cloudflare 301 リダイレクト
• Cloudflare Single Redirect のステータスと動的式
• Cloudflare API で Single Redirect を作成する
• Cloudflare Rulesets API
• Cloudflare の 3xx ステータスコード
• Cloudflare Tunnel 概要
• リモート管理 Tunnel の作成
• Tunnel のルーティングと CNAME
• Cloudflare プロキシ対応ポート
• Tunnel Token の権限とローテーション
• Tunnel の TLS トラブルシューティング