> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloud.cdata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Private Cloud Connector トラブルシューティング

> Private Cloud Connector 実行時によくある問題と、その診断および解決手順。

## よくある問題

<AccordionGroup>
  <Accordion title="Connector で 'tunneling configuration' のタイムアウトが発生する、または繰り返し再起動する。">
    **症状:** Connector コンテナのログに `ConnectTimeoutException: connection timed out cloud.cdata.com:443` が表示され、コンテナがループで再起動します。Connector は Connect AI で **Success** ステータスに到達しません。

    **手順 1: ホストからの送信を確認する（Docker とは独立）**

    ホストで次のコマンドを実行します：

    ```bash theme={null}
    curl -v https://cloud.cdata.com/api
    ```

    TLS ハンドシェイクが完了し、何らかの HTTP レスポンス（例えば 404）が返れば、ホストからの送信は正常であり、問題はコンテナレベルにあります。企業ファイアウォールが原因ではありません。

    **手順 2: IP フォワーディングを確認する**

    ホストは `cloud.cdata.com` に到達できるがコンテナは到達できない場合、ホストで IP フォワーディングを確認します：

    ```bash theme={null}
    sysctl net.ipv4.ip_forward
    ```

    これが `0` を返す場合、ホストはコンテナのアウトバウンドトラフィックをインターネットにルーティングできません。Docker では IP フォワーディングが有効になっている必要があります。有効化するには：

    ```bash theme={null}
    sudo sysctl -w net.ipv4.ip_forward=1
    ```

    次のリトライでConnector が再接続します。再ビルドやイメージの再プルは不要で、ローカルイメージと構成には影響しません。
  </Accordion>

  <Accordion title="再起動、パッチ適用、およびセキュリティ強化（ハードニング）の過程で、Connector の接続を維持できない問題が発生する。">
    `net.ipv4.ip_forward` は、OS の再起動、パッチサイクル、セキュリティハードニングのベースラインによって `0` にリセットされることがよくあります。環境が必要とする永続性のレベルを適用してください。

    **再起動後も維持する:** 永続的な sysctl 設定を追加します：

    ```bash wrap theme={null}
    echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-ip-forward.conf
    sudo sysctl --system
    ```

    **パッチ適用およびセキュリティハードニング（CIS / DISA STIG 環境）にも耐える:** 多くのハードニング済みイメージ（例：企業の RHEL ビルド）は、標準のセキュリティコントロールとして IP フォワーディングを無効化し、パッチ適用または構成管理の実行のたびにそのコントロールを再適用します。このような環境では、上記の sysctl ファイルが上書きされる可能性があります。再発を防ぐには、ハードニングベースラインを管理するチームがホストレベルの例外を追加する必要があります：

    * Docker がコンテナ接続に IP フォワーディングを必要とすることを理由に、Connector を実行するホストでは `net.ipv4.ip_forward=1` を許可する。
    * グローバルにフォワーディングを無効のままにする必要がある場合は、Docker ブリッジサブネットから `cloud.cdata.com` のポート 443 へのアウトバウンドのみを許可するスコープ付きフォワード/マスカレードルールを適用する。

    どちらも狭く意図的な例外であり、ホスト全体のハードニング状態を低下させるものではありません。

    **何が値をリセットしているかを特定するには:**

    ```bash wrap theme={null}
    grep -rns 'ip_forward' /etc/sysctl.conf /etc/sysctl.d/ /usr/lib/sysctl.d/
    ```

    `99-ip-forward.conf` より後のロード順序で `net.ipv4.ip_forward = 0` を設定しているハードニングファイルが、例外で上書きすべき対象です。
  </Accordion>

  <Accordion title="Connector が接続と切断を繰り返す / SSL ハンドシェイクが失敗する。">
    **症状:** Connector コンテナのログに次のようなエントリが繰り返し表示されます：

    ```
    SSLHandshakeException: Abruptly closed by peer
    java.io.IOException: Broken pipe
    Failed to open Azure Relay listener
    Scheduling reconnect in 5 seconds...
    ```

    Connector は Connect AI で断続的に **Success** と表示することがありますが、接続は `HTTP [40005] Invalid HTTP response ... Action impossible while not connected` で失敗します。

    **原因:** エグレスファイアウォールまたはプロキシでの SSL/TLS インスペクションが、Azure Service Bus へのConnector のアウトバウンド WebSocket 接続をインターセプトして終了させています。Connector は Microsoft の Azure インフラストラクチャと直接 TLS ハンドシェイクを完了することを想定しています。インスペクションアプライアンスが代わりに独自の証明書を提示すると、ハンドシェイクは失敗します。

    **対処法:** 次のホスト名について、ネットワーク/セキュリティチームに TLS インスペクションのバイパスを依頼してください：

    * `*.servicebus.windows.net`–Azure Service Bus（Connector のリレートンネル）
    * `*.azurecr.io`–Azure Container Registry（Connector イメージのプル）
    * `*.cdata.com`–CData クラウドインフラストラクチャ

    これらは Microsoft Azure および CData のインフラストラクチャエンドポイントです。これらのホストで TLS インスペクションをバイパスしても、全体的なセキュリティ体制が低下することはありません。Connector がサービスエンドポイントと本来意図された暗号化接続を直接完了できるようになるだけです。

    **代替策:** 完全な TLS バイパスが許可されない場合、ネットワークチームはインスペクションアプライアンスが使用する内部 CA 証明書をエクスポートし、Connector コンテナの Java トラストストアに追加できます。これにより、Connector はインターセプトされた証明書を信頼し、ハンドシェイクを完了できるようになります。この方法についてのガイダンスは、[CData サポート](https://jp.cdata.com/support/) にお問い合わせください。
  </Accordion>
</AccordionGroup>

## Additional Help

追加のサポートが必要な場合は、[CData サポート](https://jp.cdata.com/support/) にお問い合わせください。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.