FRP ポート ガイド: ポート 7000 のリバース プロキシ トンネル

FRP には、frps と呼ばれるサーバー側と、frpc と呼ばれるクライアント側があります。 frps は、到達可能なパブリック アドレスを持つマシン上で実行されます。 frpc はプライベート サービスの近くで実行され、frps に外部接続して認証し、構成されたプロキシを通じてローカル サービスを公開するよう frps に要求します。

このモデルは、ホーム ラボ、ブランチ オフィス、デバイス、テスト環境、またはプライベート ネットワーク サービスが一時的または制御された外部アクセスを必要とする場合に役立ちます。また、これは、frps がインターネットに接続されたエッジになることを意味するため、トークン、TLS、ACL、ログ、およびサービスのスコープがポート自体と同じくらい重要になります。

TCP 7000 は、frpc が制御接続を確立する frps のバインドポートとして通常使用されます。 HTTP および HTTPS リバース プロキシ モードでは、vhost_http_port と vhost_https_port (通常は 80 と 443) が使用される場合があります。TCP および UDP プロキシ マッピングは、ユーザーが直接接続するカスタム リモート ポートを公開できます。

> FRP は、構成に応じて、ダッシュボード、メトリクス エンドポイント、または管理インターフェイスを公開することもできます。これらの管理ポートをパブリック アプリケーション ポートのように扱うべきではありません。信頼できる IP、VPN、ローカルホスト、またはプライベート ネットワークに制限します。

信頼された frpc クライアントがプライベート ネットワークからトンネルを登録する必要がある場合は、frps バインド ポートを開きます。 Web アプリのプレビュー、制御されたトンネルを介した SSH アクセス、Webhook レシーバー、ゲーム サーバーなど、意図的に公開するサービスに対してのみ、ユーザー側のリモート ポートを開きます。

FRP を使用すると簡単になるからといって、幅広いポート範囲や管理インターフェイスを公開しないでください。各リモート ポートはトンネルの背後にある何かへのパブリック エントリ ポイントであり、各マッピングには所有者、目的、アクセス ポリシー、および一時的な場合は削除日が必要です。

ポート 7000 を許可する前に、どのクライアントが接続できるか、どのプロキシ タイプが許可されるか、どのリモート ポートが登録できるか、トラフィックで TLS を使用するかどうかを決定します。認証トークンまたは OIDC 設定、クライアントの命名、および任意のリモート ポートを介した権限昇格が可能かどうかを確認します。

ポート チェッカーは、frps バインド ポートまたは公開されたリモート ポートが到達可能かどうかを確認できますが、FRP 認証、ルートの所有権、またはバックエンド サービスのセキュリティが正しいことを証明することはできません。トンネル制御パスと公開されたアプリケーションの動作の両方を検証します。

クラウド サーバーでは、固定パブリック IP または安定した DNS 名を使用して frps を実行し、必要なバインド ポートと公開サービス ポートのみを許可し、ダッシュボードまたは管理者アクセスをプライベートに保ちます。可能な場合は、HTTP および HTTPS トラフィックを通常の TLS およびホストベースのルーティングの背後に置きます。

Linux または Windows クライアントでは、プライベート アプリケーションの近くでサービスとして frpc を実行します。 local_ip、local_port、プロキシ タイプ、remote_port またはカスタム ドメイン、および資格情報を慎重に構成します。無関係な環境間で同じトークンを再利用することは避けてください。

> FRP が運用環境のようなアクセスに使用されている場合は、プロセスの監視、ログの保存、監視、証明書の更新、および変更制御を追加します。利便性を考えて始まったトンネルが、予想よりも早く重要なインフラになる可能性があります。

パブリック frps ホスト名または IP およびポート 7000 に対する外部ポート チェックから開始します。それが開いている場合、frpc クライアントはコントロール リスナーに到達できる可能性があります。次に、frps ログと frpc ログをチェックして、認証、プロキシ登録、ハートビート ステータスを確認します。

次に、公開されたサービス自体をテストします。 HTTP または HTTPS トンネルの場合は、パブリック ドメインに対してcurl またはブラウザを使用します。 TCP トンネルの場合は、実際のクライアントを使用して設定されたリモート ポートに接続します。制御ポートが正常であっても、バックエンド アプリケーションやリモート ポート マッピングが動作していることは保証されません。

ポート 7000 が閉じられている場合、frps が実行されていないか、localhost にバインドされているか、ホストのファイアウォールまたはクラウド セキュリティ グループによってブロックされている可能性があります。 frpc が接続できない場合は、クライアント側の DNS、server_addr、bind_port、TLS 設定、トークンの不一致、およびネットワーク出力ルールも確認してください。

制御接続は機能するがサービスに到達できない場合は、remote_port の競合、vhost ドメイン ルーティング、HTTP ホスト ヘッダー、ローカル サービス リスナー、frpc 側の NAT、および frpsallow_ports ポリシーを検査します。 FRP の問題の多くは、最初のポート チェック時ではなく、トンネルの登録後に発生します。

frps をパブリック ゲートウェイとして扱います。強力な認証を使用し、トークンをローテーションし、許可されたポートを制限し、未使用のプロキシ タイプを無効にし、ダッシュボードを保護し、クライアント接続とプロキシ登録をログに記録します。追加の認証層を使用せずに、FRP 経由で内部管理ツールを公開しないでください。

機密性の高いサービスの場合は、VPN、アイデンティティ認識プロキシ、mTLS、ファイアウォール ホワイトリスト、またはレート制限のあるリバース プロキシの背後に FRP を配置します。アクティブなトンネルを定期的に確認し、明確な所有者やビジネス目的がなくなったマッピングを削除します。