# プロキシ構成 ## 概要 エンタープライズ環境では、ネットワークセキュリティポリシーにより、インターネット通信を企業のプロキシサーバー経由にする必要がある場合があります。Keeperゲートウェイは、環境変数およびコマンドラインパラメータによる標準的なHTTP/HTTPSプロキシ設定に対応しており、企業ネットワーク構成との互換性を確保します。 プロキシ対応を有効にすると、ゲートウェイは以下の通信を含むすべてのアウトバウンド接続を、指定したプロキシサーバー経由で送信します。 * KeeperサーバーへのWebSocket接続 * HTTP/HTTPSのAPI呼び出し * ヘルスチェックのエンドポイント * バージョン確認リクエスト * TURNの認証情報リクエスト * RBI (Chromium) セッションから対象のウェブサーバーへのトラフィック {% hint style="info" %} 現在、プロキシ対応は検出およびローテーションの操作で利用できます。一方、PAM接続セッション (SSH、RDP、VNC、データベース接続など) は、WebRTCメディアトラフィックのルーティングが複雑なため、現時点ではプロキシ経由には対応していません。WebRTC接続では、直接のネットワークアクセスか、TURNサーバーのいずれかの構成が必要です。 {% endhint %} ## 対応プロキシの種類 Keeperゲートウェイは、以下のプロキシ構成に対応しています。 * **HTTPプロキシ**: 標準的なHTTPプロキシサーバー (Squid、Apache Traffic Serverなど) * **HTTPSプロキシ**: TLSによるセキュアなプロキシ接続 * **認証付きプロキシ**: ユーザー名とパスワードによる認証が必要なプロキシ * **バイパスリスト**: 特定のドメインまたはIPアドレスをプロキシ経由の通信から除外する設定 プロキシ設定は、環境変数**または**コマンドラインパラメータの**いずれか**で構成できます。両方を指定した場合は、コマンドラインパラメータの設定が優先されます。 ### オプション1: 環境変数 環境変数を使用すると、ネットワーク通信を行うすべてのアプリケーションに対して、標準的な方法でプロキシ設定を構成できます。これらの変数は、多くのネットワークツールやライブラリで認識されます。 #### 対応環境変数 Keeperゲートウェイでは、以下の環境変数が認識されます (優先順位順)。 1. `HTTPS_PROXY` または `https_proxy`: 主に使用されるプロキシ設定 (推奨) 2. `HTTP_PROXY` または `http_proxy`: フォールバック用のプロキシ設定 3. `NO_PROXY` または `no_proxy`: プロキシを経由しないホストを指定するバイパスリスト {% hint style="info" %} 多くのアプリケーションやプログラミング言語で使われている標準的な環境変数名です。Keeperゲートウェイはこの業界標準に準拠しており、既存のインフラストラクチャとも整合しやすくなっています。 {% endhint %} #### **環境変数の設定方法** Linux/macOS ```bash export HTTPS_PROXY="http://proxy.company.com:8080" export NO_PROXY="localhost,127.0.0.1,.local" ``` Windows (コマンドプロンプト) ```cmd set HTTPS_PROXY=http://proxy.company.com:8080 set NO_PROXY=localhost,127.0.0.1,.local ``` Windows (PowerShell) ```powershell $env:HTTPS_PROXY="http://proxy.company.com:8080" $env:NO_PROXY="localhost,127.0.0.1,.local" ``` 認証ありの場合 プロキシURLに認証情報を含めます。 ```bash export HTTPS_PROXY="http://username:password@proxy.company.com:8080" ``` {% hint style="info" %} パスワードに含まれる特殊文字はURLエンコードする必要があります。たとえば、`p@ssw0rd` は `p%40ssw0rd` になります。 {% endhint %} ### オプション2: コマンドラインパラメータ コマンドラインパラメータを使用すると、より柔軟に設定できます。また、環境変数と併用した場合は、コマンドラインパラメータの設定が優先されます。 #### 利用可能なパラメータ
パラメータ説明例
--proxy-urlオプションの認証情報を含む完全なプロキシURLhttp://proxy.company.com:8080
--proxy-hostプロキシサーバーのホスト名またはIPアドレスproxy.company.com
--proxy-portプロキシサーバーのポート番号8080
--proxy-username認証用ユーザー名 (必要な場合)myuser
--proxy-password認証用パスワード (必要な場合)mypassword
--no-proxyバイパスするホストのカンマ区切りリストlocalhost,127.0.0.1,.internal
## Dockerでのデプロイ (プロキシ) DockerでKeeperゲートウェイをデプロイする場合は、`docker-compose.yml` ファイルでプロキシ設定を構成します。 #### Docker Compose構成 ゲートウェイサービスにプロキシの環境変数を追加します。 ```yaml services: keeper-gateway: platform: linux/amd64 image: keepersecurityinc/gateway:latest environment: GATEWAY_CONFIG: # プロキシ構成 HTTP_PROXY: http://proxy:3128 HTTPS_PROXY: http://proxy:3128 NO_PROXY: localhost,127.0.0.1,db-mysql,server-ssh,server-rdp networks: - internal-network depends_on: - proxy ``` {% hint style="info" %} プロキシサーバーは、ゲートウェイコンテナからアクセスできる必要があります。外部プロキシを使用する場合は、ネットワーク接続が確保されていることを確認してください。同じDocker Composeスタック内にプロキシコンテナを配置する場合は、`depends_on` セクションに含めてください。 {% endhint %} #### エアギャップ化されたDocker環境の例 完全なネットワーク分離を実現する場合は、専用のプロキシコンテナと併せてゲートウェイをデプロイします。 ```yaml networks: # インターネットアクセスのない内部ネットワーク airgapped-internal-network: internal: true ipam: config: - subnet: 10.99.0.0/24 # 公共ネットワーク（プロキシ専用） public-internet-network: driver: bridge services: # HTTPプロキシ（ネットワークをブリッジ） proxy: platform: linux/amd64 image: ubuntu/squid:latest networks: - airgapped-internal-network - public-internet-network ports: - "3128:3128" volumes: - ./squid.conf:/etc/squid/squid.conf:ro # Keeperゲートウェイ（エアギャップ化） keeper-gateway: platform: linux/amd64 image: keepersecurityinc/gateway:latest environment: GATEWAY_CONFIG: HTTP_PROXY: http://proxy:3128 HTTPS_PROXY: http://proxy:3128 NO_PROXY: localhost,127.0.0.1,internal-service networks: - airgapped-internal-network # 公共ネットワークは含めない depends_on: - proxy ``` この構成では、以下のようになります。 * ゲートウェイコンテナはインターネットへ直接アクセスできません (`internal: true` のネットワークのみを使用) * すべてのインターネット通信は、必ずプロキシコンテナを経由します * プロキシコンテナが、エアギャップ環境とパブリックネットワークを中継します * 内部サービス (データベース、アプリケーションサーバーなど) は、プロキシを経由せずに通信します 複数の構成ソースが存在する場合、Keeperゲートウェイでは以下の優先順位 (上位から下位) で設定が適用されます。 1. 個別のコマンドラインパラメータ (`--proxy-host`、`--proxy-port` など) 2. `--proxy-url` コマンドラインパラメータ 3. `HTTPS_PROXY` 環境変数 4. `https_proxy` 環境変数 5. `HTTP_PROXY` 環境変数 6. `http_proxy` 環境変数 バイパスリストは、以下の優先順位で適用されます。 1. `--no-proxy` コマンドラインパラメータ 2. `NO_PROXY` 環境変数 3. `no_proxy` 環境変数 ### プロキシURL形式 プロキシURLは以下の標準URI構文に従います。 ``` [scheme://][username:password@]hostname:port ``` #### 例 基本的なHTTPプロキシ ``` http://proxy.company.com:8080 ``` HTTPSプロキシ ``` https://proxy.company.com:8080 ``` 認証付きプロキシ ``` http://username:password@proxy.company.com:8080 ``` パスワードに特殊文字を含むプロキシ ``` http://user:p%40ssw0rd%21@proxy.company.com:8080 ``` > **注:** ユーザー名とパスワードに含まれる特殊文字は、パーセントエンコーディングでURLエンコードします (例: `@` は `%40`、`!` は `%21`)。 ### NO\_PROXYバイパスリスト `NO_PROXY` 設定を使用すると、特定のホストをプロキシ経由の通信から除外できます。同一ネットワーク上の内部サービス、プロキシを経由する必要のないローカルリソース、プロキシ経由では動作しないサービスなどで有用です。 #### バイパスリストの形式 バイパスリストは、カンマ区切りで指定します。 * **完全一致のホスト名**: `localhost`, `internal-server` * **IPアドレス**: `127.0.0.1`, `192.168.1.100` * **ドメインサフィックス**: `.internal.com`, `.local`（すべてのサブドメインに一致） #### 例 基本的なバイパスリスト ```bash NO_PROXY=localhost,127.0.0.1 ``` ドメインサフィックスを含める場合 ```bash NO_PROXY=localhost,127.0.0.1,.corp.internal,.local ``` Docker内部サービスを除外する場合 ```bash NO_PROXY=localhost,127.0.0.1,db-mysql,server-ssh,server-rdp,server-vnc ``` {% hint style="info" %} スペースは自動的に削除されます。そのため、`localhost, 127.0.0.1` と `localhost,127.0.0.1` は同じ動作になります。 {% endhint %} ### 検証とテスト #### 手順1: 構成の確認 プロキシ設定を適用してゲートウェイを起動した後、ログを確認して設定が反映されていることを確認します。 ``` INFO - Applying proxy configuration: proxy.company.com:8080 INFO - Using proxy for WebSocket: proxy.company.com:8080 ``` #### 手順2: プロキシ接続のテスト ゲートウェイを起動する前に、プロキシへアクセスできることを確認します。 Linux/macOS ```bash curl -x http://proxy.company.com:8080 https://keepersecurity.com ``` Windows (PowerShell) ```powershell Invoke-WebRequest -Uri https://keepersecurity.com -Proxy http://proxy.company.com:8080 ``` プロキシが認証を要求する場合 ```bash curl -x http://username:password@proxy.company.com:8080 https://keepersecurity.com ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.keeper.io/keeperpam/jp/privileged-access-manager/getting-started/gateways/advanced-configuration/proxy-configuration.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.