TLS インスペクションプロキシを設定する
Cherri Bot のデスクトップアプリは、各メンバーのデバイスから2つの宛先に接続します。1つはチャット、サインイン、承認のための *.cursor.sh の Cherri Code API、もう1つはコンピューターのセットアップ、画面、シェルのための *.*.cursorvm.com というネストされたホスト名のメンバーのホストされたコンピューターです。TLS を検査するセキュア Web ゲートウェイは、前者は通過させても後者を遮断することが多くあります。その場合、デスクトップアプリはコンピューターのセットアップ中に停止したりエラーになったりします。構成によっては、チャットは動作し続けるのにコンピューターには接続できないという状態になります。最も一般的な例は Zscaler で、このページでは具体例として Zscaler を取り上げますが、TLS を再署名したりレスポンスをバッファリングしたりするゲートウェイであれば同じ手順が当てはまります。このページは、ゲートウェイを運用する IT チーム向けです。共通のドメイン一覧とストリーミングのテストはエンタープライズのネットワーク設定を参照してください。ここでは Cherri Bot 固有の内容を扱います。
このページは、メンバーのデバイスから Cherri Code までの経路についての説明です。ホストされたコンピューター自体の接続先が変わるわけではありません。そちらは ネットワークポリシーで扱います。コンピューターからプライベートネットワーク上のサービスに到達する方法については、 プライベートネットワークに接続するを参照してください。
症状
- コンピューターのセットアップが途中で止まる、または失敗する。 app の computer への接続が完了しません。チャットは
api2.cursor.shに到達できるため引き続き動作する場合もあれば、一緒に止まる場合もあります。いずれにせよ、computer の接続にはcursorvm.comが必要です。 - テザリングや個人デバイスでは動作する が、社内ネットワーク上やゲートウェイクライアントを実行している状態では失敗する。
- オフィスでは動作するが、自宅では失敗する。 例外設定がオフィスの拠点にのみ適用されています。すべてのプロファイルに適用するを参照してください。
- サインインやチャットも止まる。
cursor.shに対して TLS インスペクションまたはレスポンスのバッファリングがまだ有効になっています。
これらのドメインパターンを許可する
以下のすべてを、ゲートウェイおよび DNS フィルタリングで許可してください。ホスト名を個別に列挙するのではなく、ワイルドカードの使用を推奨します。コンピューターのホスト名はコンピューターごとに生成されます。
| パターン | 用途 |
|---|---|
*.cursor.sh | チャット、サインイン、承認、その他の Cherri Code API |
*.cursor-cdn.com | 静的アセット |
*.cursorapi.com | 拡張機能マーケットプレイスおよび関連 API |
*.cursorvm.com | ホストされたコンピューターとそのコントロールプレーン |
*.*.cursorvm.com | 同上、1 階層深いもの。必須です。 |
cursor.com、downloads.cursor.com | デスクトップアプリのインストールと更新 |
cursorvm.com の 2 つのパターンは両方とも追加してください。コンピューターのホスト名は
cursorvm.com の下に 2 つのラベルを持ち、<computer>.<cluster>.cursorvm.com
の形式になるため、1 階層のワイルドカードでは一方しか一致しません。
*.cursorvm.com だけを設定したゲートウェイは一見正しく見えますが、
コンピューターには到達できないままです。cursor.sh がすでに許可されている
ネットワークでコンピューターのセットアップが失敗する原因のほとんどはこれです。
同じドメインを TLS インスペクションとバッファリングの対象外にする
トラフィックを許可するだけでは不十分です。上記のすべてのドメインについて、次の設定を行ってください。
- TLS (SSL) インスペクションをバイパスする。 ゲートウェイが独自の証明書で接続を再署名すると、ホスト名が許可されていてもコンピューターのセットアップ ハンドシェイクが失敗します。Cherri Code の接続はもともとエンドツーエンドで暗号化されています。
- レスポンスのバッファリングを無効にする。 チャットとコンピューターのリンクはストリーミングで動作します。レスポンスが完了するまで保持するゲートウェイを挟むと、アプリはいつまでも届かない出力を待ち続けることになります。
すべてのトラフィックの検査がポリシー上必須の場合は、ゲートウェイが SSL インスペクションと DLP に記載の要件を満たす必要があります。すなわち、HTTP/2 または Cherri Code の HTTP/1.1 フォールバック、バッファリングなしの Server-Sent Events パススルー、強制タイムアウトのない長時間接続です。
オフネットワークを含むすべてのプロファイルに適用する
Zscaler Client Connector はデバイスがオフィスを離れても動作し続け、独自のオフネットワークプロファイルを適用します。オフィスの拠点や個別のポリシーに追加した例外は、デバイスが自宅に移動すると引き継がれません。許可ルール、TLS インスペクションの除外、DNS の例外は、ローミングやオフネットワークを含め、Cherri Bot のメンバーが該当するすべての拠点、プロファイル、ポリシーグループに適用してください。オンネットワークとオフネットワークで別々のポリシーを持つ他のゲートウェイについても、同様の対応が必要です。
見分け方: ゲートウェイクライアントは動作しているのに、同じノートパソコンでオフィスでは Cherri Bot が使えて自宅では失敗する場合です。
メンバーのデバイスから確認する
IT が変更を適用した後、ゲートウェイクライアントが動作しているメンバーのデバイスで以下を実行します。
証明書の発行者を確認する
curl -v # |& grep -C1 issuer:発行者は Amazon RSA になっているはずです。Zscaler やご利用のゲートウェイ
ベンダー名が表示される場合、このデバイスのプロファイルでは cursor.sh に対する
TLS インスペクションがまだ有効です。
コンピューターのホスト名が解決できるか確認する
nslookup test.us9.cursorvm.comアドレスが返ってくるはずです。名前解決に失敗する場合は
nslookup test.us9.cursorvm.com 1.1.1.1 を試してください。パブリックリゾルバーは応答するのに
デフォルトのリゾルバーが応答しない場合、原因はデバイスの DNS またはゲートウェイの
プロファイルであり、そこに *.*.cursorvm.com のネストした例外が設定されていません。
ストリーミングをテストする
プロキシ接続のテスト にある HTTP/1.1 および HTTP/2 のストリーミングテストを実行します。 出力は一度にまとめてではなく、1 行ずつ届くはずです。
アプリで再試行する
同じデバイスで Cherri Bot デスクトップアプリを開き、コンピューターに接続します。 それでも失敗する場合は、そのデバイスで各チェックを繰り返してください。 テザリングでは成功し、社内ネットワークでは失敗するなら、ネットワークが 原因だと確認できます。
適用範囲
混同しやすい制御が3つあります。
| 目的 | 使用するもの |
|---|---|
| メンバーのデバイスからゲートウェイ経由でCherri Codeおよびホストされたコンピューターに接続できるようにする | このページ |
| ホストされたコンピューターが接続できる送信先を制限する | ネットワークポリシー (エンタープライズのみ) |
| ホストされたコンピューターのトラフィックをメンバーのデバイス経由でルーティングする | デスクトップ経由でトラフィックをルーティングする |
| すべてのホストされたコンピューターにネットワーククライアントをインストールする | Team Setup (エンタープライズのみ) |
デフォルトでは、ホストされたコンピューター自体のトラフィックはCherri Codeの共有静的エグレスIPから送出され、メンバーのデバイス上のゲートウェイは経由しません。メンバーがこのコンピューター経由でトラフィックをルーティングを有効にすると、ルーティングされたトラフィックはそのデバイスのネットワークを使用し、そのゲートウェイのポリシーが適用されます。
FAQ
よくある原因は2つあります。1つは、ネストされた *.*.cursorvm.com のパターンが不足しており、
computer のホスト名が一致しないケースです。もう1つは、ドメインは許可されていても
TLS インスペクションの対象のままになっており、ゲートウェイの証明書によってセットアップのハンドシェイクが失敗するケースです。
ネストされたパターンを追加し、両方のパターンをインスペクションの対象外にしたうえで、
チェックを実行してください。
使用するホスト名が異なるためです。チャット、サインイン、承認の接続先は
api2.cursor.sh で、ほとんどのゲートウェイではすでに許可されています。一方、computer の接続先は
ネストされた cursorvm.com のホスト名で、個別の許可ルールとインスペクションの
対象外設定が必要です。そのため、一部のネットワークではチャットは動作し続けるのに
computer はまったく接続できない、ということが起こります。
自宅でもゲートウェイのクライアントは動作しており、例外設定が反映されていない オフネットワークプロファイルが適用されています。ローミング用および社外ネットワーク用の プロファイルにも例外を適用してください。
その場合、ゲートウェイはストリーミングを一切変更せずに通過させる必要があります。 要件は SSL インスペクションと DLP を参照してください。確実なのは Cherri Code のドメインを対象外にする方法です。Cherri Code の接続は すでにエンドツーエンドで暗号化されています。
はい。
エンタープライズのネットワーク設定
と同じリストです。エディターのチャットと Tab の機能は cursorvm.com のパターンがなくても
動作します。そのため、エディターでは問題のないゲートウェイでも
Cherri Bot が動作しなくなることがあります。
関連ページ
- エンタープライズのネットワーク設定
- チームおよびエンタープライズ向けCherri Bot
- Cherri Bot のセキュリティ
- プライベートネットワークに接続する
- ネットワーク、プロキシ、リモート接続
ゲートウェイの設定でお困りですか？
デプロイの支援や優先サポートについては、当社チームまでお問い合わせください。