ポート開放の代替手段としてのCloudflare Tunnel

ポート開放なしのCloudflare Tunnelの仕組み解説

従来のポート開放では、外部のクライアントがルーターやサーバーのパブリックIPアドレスに直接接続します。その後、ルーターは着信トラフィックを内部ネットワーク上のサービスに転送します。ある Cloudflare Tunnel この接続確立のプロセスを逆転させる：コネクタ cloudflared アクセス可能な内部ネットワーク上で動作し、Cloudflare へのアウトバウンド接続を自ら確立します。

たとえば、ユーザーが管理ポータルにアクセスすると、Cloudflareはそのホスト名に対するリクエストを受け取り、既存のトンネル接続を介してコネクタに転送します。コネクタは、設定された宛先サービス（例えば http://localhost:8080. したがって、Originについては、インターネットから直接アクセス可能なIPアドレスも、このサービスに対するファイアウォールの受信許可も必要ありません。

だからといって、ネットワークルールが不要になるわけではありません。次の設定を持つホストは cloudflared Cloudflareが外部にアクセスできる必要があります。 Cloudflareのドキュメントによると、これにはTCPまたはUDPのポート7844が使用され、それぞれHTTP/2およびQUICが採用されています。アウトバウンドトラフィックは、ローカルファイアウォール、ルーター、および必要に応じて企業のプロキシを通じて許可されている必要があります。これが、「ポート開放なし」という表現の実際の限界となります。

DNSエントリだけでは、この保護された接続経路は確立されません。DNSは単に名前を宛先アドレスに割り当てるだけであり、プライベートネットワークから接続を開始したり、ローカルサービスを仲介したりすることはありません。その 出力コネクタ これが決定的な要素です。このコンポーネントは、内部のターゲットサービスを認識しており、内部から外部へと至る経路を開放した状態に保ちます。どのユーザーがこの経路を利用できるかは、これとは別に設定する必要があります。

トンネルはアクセス保護ではない

トンネルはオリジンのネットワーク上の直接的な可視性を低減しますが、それ自体でアクセス権限を決定するものではありません。Web管理パネルがパブリックホスト名を介してルーティングされる場合、その前にAccessアプリケーションが配置されていない限り、原則として任意のインターネットユーザーからアクセスされる可能性があります。 そのため、Cloudflareでは、本番環境のトンネル経路の前にAccessを設定することを推奨しています。トンネルは伝送経路であり、アクセス制御そのものではありません。

特権付きの管理パネルには、 アクセスポリシー 明確に定義された個人またはグループのみを許可します。「Include」、「Require」、「Exclude」の基準に加え、「Allow」、「Block」、「Bypass」、「Service Auth」などのアクションも利用可能です。MFAは、連携されたIDプロバイダーを介して、あるいは追加の認証要素として強制適用できます。 電子メールドメイン内のすべてのアカウントに一律に適用されるルールは、高権限のインターフェースにおいては、多くの場合、範囲が広すぎます。

アクセス層は、アプリケーションの堅牢化を補完するものであり、それに取って代わるものではありません。 管理パネルには、引き続き安全なログイン、タイムリーな更新、適切なセッションルール、および権限の慎重な付与が必要です。また、ローカルユーザーアカウント、ロール、および管理権限も依然として重要です。ユーザーがAccessへのログイン後にアプリケーションへのアクセス権を取得した場合でも、そのユーザーが自動的にそれ以上の管理権限を付与されることはあってはなりません。

さらに、アプリケーションがアクセス・トークンを検証しているか、あるいはトークン検証用に用意されたトンネル・オプションを利用しているかを確認する必要があります。 これにより、アプリケーションは上流の本人確認プロセスに紐付けられ、オリジンへの意図しない代替アクセス経路によるリスクを軽減できます。階層化された構成が有効です。具体的には、公開範囲の制限、MFA（多要素認証）による本人確認、最小限のアプリケーション権限、そして内部からアクセス可能で一般に公開されていないターゲットサービスといった構成です。

HTTP、SSH、RDP、TCPの分類

HTTP(S)アプリケーションと管理プロトコルでは、アクセスモデルが異なります。内部のWebインターフェースは、ホスト名を通じて公開し、オリジンに対してAccessで保護することができます。 SSH、RDP、および特定のTCPサービスもトンネル経由でアクセス可能ですが、プロトコルによっては、クライアント側で追加のソフトウェアやブラウザベースのアクセスが必要になる場合があります。Web経由でのログインを行ったからといって、それが自動的に任意のネイティブネットワークアクセスになるわけではありません。

普段使っているローカルターミナルでSSHを使用する場合、クライアント側で cloudflared Accessと連携して接続を確立します。また、Cloudflareでは、ブラウザ経由のSSH接続を独自のアクセス方法として文書化しています。 これら2つの方式は、クライアントのワークフロー、ローカルのSSH設定、および操作方法において異なるため、一律に互換性があるわけではありません。インフラストラクチャや証明書モデルに関する詳細な記述については、その最新かつ関連するドキュメントを別途確認した上で、計画に盛り込む必要があります。

ブラウザでレンダリングされるSSHターミナルは、ローカルのSSHクライアントが準備されていない場合、サポートや時間的制約のある緊急アクセスに便利である。 ただし、導入前には、監査要件、操作手順、ローカル鍵方式、およびファイル転送について評価を行う必要があります。RDPやその他のTCPサービスについても、Webインターフェースと同様に一律に扱うのではなく、アプリケーションごとに個別に検証すべきです。

Tunnelは、あらゆるネットワーク接続の完全な代替手段というわけではありません。VoIPやSIPのようなサーバー主導のプロトコルはサポートされていません。また、長時間継続し、中断に敏感なTCPセッションについても、適合性の確認が必要です。 さらに、SSH、RDP、TCPの場合、Originは元のクライアントIPアドレスではなく、コネクタを認識します。HTTPの場合、アプリケーションは CF-Connecting-IP 評価する。IPベースの許可リストやフォレンジックログは、この制限を考慮に入れる必要がある。

複数のサービスを安全に割り当てる

ローカルのIngressファイルは、公開された各ホスト名を内部の宛先に1対1で割り当てます。管理パネルとSSHには別々の名前を付けることが推奨されます。これにより、権限、ログ、および今後の変更が明確に区別されます。 cloudflaredはルールを上から順に評価し、最初に一致したルールが宛先を決定します。

以下の例は、ローカルで管理されるトンネルの設定テンプレートです。ここでは意図的に example.invalid また、アクセス情報も実際のドメインも含まれていません。このWebサービスは localhost:8080 アクセス可能；SSHはローカルのSSHサービスに転送されます。

tunnel: <TUNNEL-UUID>
credentials-file: /etc/cloudflared/<TUNNEL-UUID>.json

ingress:
  - hostname: admin.example.invalid
    service: http://localhost:8080
  - hostname: ssh.example.invalid
    service: ssh://localhost:22
  - service: http_status:404

最後のルールは次の通りです。 包括的規則. これはローカルのIngressファイルに必要であり、ここでは http_status:404 未知のホスト名が、誤って最初のサービスやその他の内部サービスに到達しないようにするためです。特に管理用宛先に対しては、広範囲にわたるデフォルトの転送は不必要なリスクとなります。

このファイルは、トンネルからOriginへの経路のみを定義するものです。DNSエントリの設定や、Cloudflare Accessによるホスト名の保護は行いません。したがって、本番環境でのルーティングを行う前に、ホスト名とアクセスポリシーを別途設定する必要があります。また、ローカル環境においても、cloudflaredが実際に必要とする場所でのみ、宛先ポートにアクセスできるようにする必要があります。

実行前に、設定を変更することなく順序を確認できます。最初のコマンドはIngressの設定を検証し、2番目のコマンドは指定されたアドレスに対してどのルールが適用されるかを表示します。

cloudflared tunnel ingress validate
cloudflared tunnel ingress rule https://admin.example.invalid

SSHアクセスを適切に選択する

トンネル経由のSSHは、統一されたアクセス方法ではありません。 適切な方式は、管理者がローカル端末を引き続き使用するかどうか、あるいは障害発生時にあらかじめ準備されたクライアントなしで作業しなければならないかどうかに依存します。利用可能なモデルは、クライアント、認証方法、操作手順において異なりますが、具体的なSSHDの設定やローカルの権限管理はこれらとは別個に扱われます。

よく知られたローカルツールを日常的に使用している小規模なチームの場合、クライアント側のCloudflareが適していることが多い。これにより、SSHポートは内部に留まったまま、接続確立前にAccessが追加の認証レイヤーを設けることになる。ただし、これはすべてのSSH権限を一元管理することとは異なる。

ブラウザ経由でのアクセスは、独立したプロセスとして扱う必要があります。 サポート対応や予期せぬアクセスが必要な場合、あらかじめSSHクライアントが設定されている必要がないため、有用な手段となり得ます。しかし、これが一律に優れた管理手法であるわけではありません。ファイル転送、慣れ親しんだローカル鍵の管理手順、監査要件などを考慮すると、ターミナルクライアントやプライベートアクセスの方が適している場合もあります。

どの方法を選んでも、ローカルの保護レイヤーは維持されます。Linuxアカウント、 sudoのルール、SSHDの設定およびターゲットシステム上の権限によって、ログインに成功したユーザーが実行できる操作は引き続き決定されます。このトンネルは、これらのルールや権限の制限に取って代わるものではありません。

公開されているHTTP以外のサービスについては、クライアント側でcloudflaredが必要になる場合があります。また、SSHではブラウザ経由でのアクセスも可能です。したがって、RDPやその他のTCPサービスについては、SSHの例に倣って安易に計画を立てるのではなく、それぞれのクライアントや運用上の要件に基づいて計画すべきです。

トンネル、VPN、バスティオン、またはポート開放

この選択は、ポートが開いているかどうかという問題だけでなく、どの程度のアクセス範囲を許可するかという点にも関係します。Cloudflare Tunnelは、主に、明確に指定された少数のサービスに適しています。一方、多数の内部システムやネットワークセグメントにアクセスする必要がある場合は、個別の公開設定をまとめて管理するのではなく、プライベートネットワークアクセス用のモデルが必要となる場合がほとんどです。

従来のポート開放が必ずしも間違っているわけではありません。アプリケーションの保護、ファイアウォールの運用、および外部からのアクセス可能性について、意図的に責任を持って管理されている公共サービスにとっては、適切な選択肢となり得ます。これとは対照的に、トンネル方式では、コネクタが内部ネットワーク側から接続を確立するため、オリジンにインターネットから直接アクセスする必要はありません。

単一の管理パネルや、少数の保守対象の場合には、サービスベースの公開が適しています。 IDベースのアクセス 多くの場合、包括的なネットワークトンネルよりも範囲を絞り込みやすい。とはいえ、プロトコルの検証が不要になるわけではない。サーバー主導のプロトコルはサポートされておらず、中断に弱い長時間のTCPセッションでは、別の接続モデルが必要になる場合がある。

従業員が複数のプライベートアプリケーション、アドレス範囲、または内部の依存関係を必要とする場合、VPNの導入は依然として有効です。一方、バスティオンホストはSSHアクセスを単一のエントリポイントに集約しますが、そのエントリポイント自体も入念に強化・運用する必要があります。 一方、リバースプロキシはTLSの終端処理やアプリケーションの提供を行うレイヤーであり、プライベートオリジンへのアクセス方法そのものを解決するものではありません。プロキシ、アプリケーションサーバー、プロセスマネージャーの役割は、 NGINX Unit と PHP-FPM の比較 理解している。.

したがって、実務上の決定は、まず範囲を限定することから始まります。つまり、「どのユーザーが、どのサービスに、どのクライアントを使用してアクセスする必要があるのか」ということです。この回答の範囲が狭ければ狭いほど、正確なホスト名とルールを用いたトンネルを運用しやすくなります。一方、広範なネットワーク要件、特殊なプロトコル、あるいはセッションの安定性に対する高い要求がある場合は、別途評価を行う必要があります。

稼働中のトンネルの安全確保

アクティブなトンネルは、単発的な接続一つだけで構成されているわけではありません。Cloudflare のドキュメントによると、各 cloudflared トンネルには、少なくとも 2 つの自社データセンターへの 4 つの長期にわたるアウトバウンド接続が存在します。そのため、個々の接続経路がダウンしても、リクエストは他の既存の経路を経由して送信されることができます。 これにより、コネクターとCloudflare間の経路における依存関係は軽減されますが、内部サービス自体の可用性が向上するわけではありません。

重要なアプリケーションの場合、複数の cloudflared インスタンスが、同じトンネルをレプリカとして利用できます。 これにより、Cloudflareネットワークからプライベートネットワークへの追加の経路が確保されますが、冗長化されたアプリケーションや、データベース・ホスト戦略の代わりとなるものではありません。例えば、管理パネルが設置された唯一のサーバーにアクセスできない場合、そのサーバーや他のホスト上の追加のコネクタは、正常に動作している宛先サービスに実際に到達できる場合にのみ役立ちます。 接続経路 したがって、サービスと可用性は別々に計画する必要があります。

複数のオリジンを個別に検証したり、障害発生時に迂回させたり、ルールに基づいて分散させたりする必要がある場合は、ヘルスチェックやトラフィックステアリングを伴う追加のロードバランシングが必要となります。トンネルだけでは、こうした判断を詳細なレベルで行うことはできません。 また、アーキテクチャでは、障害発生後にターゲットサービスをどのように復旧させるか、および障害発生中も管理用アクセスが引き続き必要かどうかを明確に定義しておく必要があります。

可用性はソフトウェアだけにとどまりません。コネクタとターゲットシステムが専用の技術室に設置されている場合、電源、冷却、空気の質、定期的な点検も運用計画に組み込む必要があります。これに伴いどのような追加的な環境リスクが発生し得るかは、以下の考察から明らかになります。 地下にあるサーバールームの換気. このような対策はレプリカの代わりにはなりませんが、計画されたすべての接続経路が、同じローカルなインフラ依存性によって機能しなくなることを防ぎます。

cloudflaredのアップデートは、予定されたメンテナンス時間帯に行う必要があります。アップデートにより再起動が発生し、その時点で処理中のトラフィックに影響を与える可能性があるためです。 Cloudflareは、中断のないアップグレードの選択肢として、ロードバランシングや複数のcloudflaredインスタンスを挙げています。どの更新方法が適切かは、インストール方法や運用環境によって異なるため、メンテナンスウィンドウの前に文書化しておく必要があります。

各アップデートについて、インストールされたバージョン、担当ホスト、フェイルオーバー手順、およびターゲットサービスへの到達性テストを記録してください。 再起動後は、トンネルの状態だけでなく、定義されたIngressルールが想定通りのサービスに到達しているか、および予定されたアクセス層が引き続き有効であるかについても確認してください。これにより、コネクタ、ターゲットサービス、および権限経路が、個別の運用タスクとして追跡可能になります。

よくある設定ミスを早期に発見する

本番稼働前に、コネクタのトラブルシューティングを開始します。ホストは、ポート7844経由でTCPまたはUDPを使用してCloudflareに接続できる必要があります。 着信ポートの開放がされていないことは想定内ですが、一方、送信を包括的にブロックするファイアウォールは想定外です。cloudflaredが送信接続を確立できるようになって初めて、DNS、ホスト名、およびアプリケーションレベルのアクセスルールを調査する価値があります。

1. ローカルでの到達可能性の確認：Ingressルールで指定されたサービスは、cloudflaredホストから、指定されたローカルまたは内部エンドポイント経由でアクセス可能でなければなりません。
2. DNSとIngressの整合性を確保する：パブリックホスト名は、意図したトンネル経路と一致している必要がある。また、ルール順序は、より一般的なルールよりも、具体的なサービスに関するルールが先に適用されるように設定する必要がある。
3. キャッチオール機能のテスト：最後に「http_status:404」というルールを設定することで、想定外のホスト名が標準サービスに転送されるのを防ぎます。
4. 本番リリース前のAccessの設定：この設定が完了して初めて、権限のあるアカウントと権限のないアカウントの両方を使用して、外部パスを厳密に検証できるようになります。

よくあるセキュリティ上のミスの一つは、アクセス許可範囲が広すぎることです。管理パネルや特定のSSHサービスのみを公開する代わりに、より広範なネットワーク領域へのアクセスを許可してしまうケースです。同様に、特権のあるインターフェースに対して一律のメールドメインルールを適用することも、同様にリスクが高いと言えます。 管理用アクセスについては、小規模で検証可能なグループ、適切な「Require」条件、およびMFA（多要素認証）を設定し、実際の利用者層を正確に反映させる必要があります。 最小限の承認 また、別々のホスト名と宛先サービスを不必要にまとめないことも意味します。

トンネル設定と権限設定は、それぞれ異なる役割を果たします。Ingressルールは、すでに確立された接続がどこへ進むかを決定し、Accessは、その前に誰が認証・認可されるかを決定します。適切なAccessアプリケーションがなければ、公開されたHTTPホスト名はインターネットからアクセス可能になってしまう可能性があります。 したがって、ローカルアカウント、sudoルール、SSHDの設定、およびアプリケーションのセキュリティ強化も、それぞれ独立した検証項目となります。

ログや監査においては、送信元IPの制限が重要です。SSH、RDP、その他のTCP接続の場合、オリジンは元のクライアントIPではなく、コネクタのコンテキストを認識します。そのため、ターゲットシステム上のIPベースの許可リストでは、ユーザーを確実に特定することはできません。 HTTPアプリケーションは、そのロギングおよび信頼チェーンがこれを意図的に考慮している場合に限り、CF-Connecting-IPヘッダーを評価することができます。

適切なアクセスソリューションの選択

単一のWeb管理パネルについては、パブリックなオリジンIPや着信許可を設定することなく、明確なホスト名でサービスにアクセスできるようにしたい場合に、Cloudflare Tunnelが適しています。 適切な構成としては、ターゲットを限定し、その手前に、小規模なIDグループとMFAを備えたアクセス制御アプリケーションを配置することが挙げられます。この手法はネットワーク経路を保護しますが、安全なセッション管理や管理パネル内での権限チェックに代わるものではありません。

慣れたターミナル操作を行う小規模な管理チームは、クライアント側のCloudflareおよびAccessを介してSSHを利用できます。ブラウザでレンダリングされるSSHは、主に事前に準備された緊急時やサポート用のアクセス手段として適しています。 どちらの方法も、クライアントや操作に関する要件が異なります。ファイル転送、ワークフロー、監査要件は、選択した方法に適合している必要があります。集中管理型のSSH権限に関するより高度なモデルについては、その都度、最新の具体的なドキュメントに基づいて決定する必要があります。

多数の内部サービス、セグメント全体、あるいは広範囲にわたる東西方向の通信を必要とする場合は、VPNなどのプライベートネットワークアクセスや、その目的のために設計された接続モデルを検討すべきです。 公開された単一のトンネルが、必ずしもすべてのVPNワークロードの代替となるわけではありません。VoIPやSIPのようなサーバー主導のプロトコルには、トンネルは適していません。また、長時間継続し、中断に敏感なTCPセッションについても、具体的なプロトコルや再接続による影響の可能性を検証する必要があります。

サービスが意図的に直接一般に公開されており、ファイアウォール、オリジン保護、およびアプリケーション認証が適切に運用されている場合、従来のポート開放は妥当な選択肢となり得ます。バスティオンホストはSSHアクセスを一元化しますが、それ自体が特に厳重に保護すべきエントリポイントとなります。 一方、リバースプロキシはTLSの終端処理やアプリケーションの提供を行う層であり、単にプライベートオリジンへのアクセス方法を解決するだけのものではありません。

生産性に関する最低基準は、以下の通りです。必要最小限のターゲット範囲、ID ベースのルール、特権ロールに対する多要素認証（MFA）、テスト済みの Ingress およびキャッチオール設定、計画的な更新プロセス、および文書化された復旧手順。 復旧計画 これには、少なくとも責任の所在、代替経路、およびメンテナンス後にターゲットサービスとコネクタが再び利用可能かどうかを確認することが含まれます。トンネルはネットワークの露出面積を低減しますが、アプリケーションのセキュリティ強化、ローカル権限の設定、あるいは継続的な運用監視に代わるものではありません。