View a markdown version of this page

プライベート接続のトラブルシューティング - AWS DevOps エージェント

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

プライベート接続のトラブルシューティング

このページでは、 プライベートにホストされたツールへの接続 for AWS DevOps Agent の作成時または使用時に発生する可能性がある一般的な問題とその解決方法について説明します。各セクションでは、症状、最も可能性の高い原因、およびその修正手順について説明します。

プライベート接続の仕組みの概要については、「」を参照してくださいプライベートにホストされたツールへの接続。

DNS ホストアドレスが解決しない、またはトラフィックが間違った場所に到達する

症状

ホストアドレスの DNS 名を使用してプライベート接続を作成しましたが、接続がサービスに到達できません。これは、ターゲットサービスがセルフホスト GitLab インスタンス、内部 Application Load Balancer (ALB)、またはホスト名が VPC 内にのみ存在する MCP サーバーである場合に最もよく発生します。

DNS 解決に失敗しても、DNS に言及するメッセージは生成されません。代わりに、機能プロバイダーを登録または使用すると、一般的な到達可能性またはプロバイダーエラーとして表示されます。たとえば、Could not complete request to provider.、Unable to connect to the MCP server at <endpoint>. The connection was interrupted.、または などの認証エラーが表示される場合があります。メッセージが Authentication with provider failed. DNS を指さないため、次のチェックを使用して原因を確認します。

原因

デフォルトでは、プライベート接続はパブリック DNS () を使用してホストアドレスを解決しますdnsResolution: PUBLIC。ホスト名にプライベートホストゾーン、Amazon Route 53 Resolver ルール、またはオンプレミス DNS サーバーにのみレコードがある場合、パブリック解決は失敗し、接続はサービスに到達しません。

DNS が原因であることを確認する方法

  • ホストアドレスが VPC 内でのみ解決されるかどうかを確認します。同じ VPC 内の Amazon EC2 インスタンスまたは AWS CloudShell セッションから、 を実行しますnslookup <your-host-address>。パブリック DNS からではなくそこで解決され、プライベート接続が を使用する場合dnsResolution: PUBLIC、DNS 解決が原因です。

  • 名前の代わりに IP アドレスを使用してテストします。DNS 名の代わりにホストアドレスにターゲットのプライベート IP アドレス (またはロードバランサー IP) を使用するプライベート接続を一時的に作成します。接続がサービスに到達した場合、以前の障害はネットワークパスやサービス自体ではなく DNS 解決でした。

解決策

  • ホスト名が VPC 内でのみ解決される場合は、接続の作成時に DNS 解決モードを VPC 内 (IN_VPC) に設定します。このモードでは、ホストアドレスは VPC コンテキスト内から解決されるため、プライベート専用ホスト名は正しく解決されます。「プライベート接続を作成する」を参照してください。

  • DNS 解決モードは作成時に選択され、指定したホストアドレスに適用されます。作成後にサービスマネージドリソースゲートウェイが DNS を解決する方法を変更することはできないため、事前に正しいモードを選択してください。間違ったモードを選択した場合は、接続を削除し、正しいモードで再作成します。

  • ホストアドレスに (DNS 名ではなく) IP アドレスを指定した場合、DNS 解決モードは効果がなく、トラフィックはその IP に直接送信されます。

  • セットアップIN_VPCに を使用できない場合は、代わりにホストアドレスをターゲットのプライベート IP アドレス、またはパブリックに解決可能だがプライベート IP に転送されるロードバランサーの DNS 名にポイントできます。

接続が「作成に失敗しました」でスタックしています

症状

プライベート接続を作成すると、コンソールにステータスが Connection Failed と表示されます ( のステータスdescribe-private-connectionが返されますCREATE_FAILED)。

原因

作成が失敗した場合、ほとんどの場合、サービスエラーではなく、リクエストまたは VPC の設定の問題が原因です。接続のステータスが失敗すると、 AWS DevOps Agent は failureMessageフィールドに理由を説明するため、チェックリストを進める前にそのフィールドを読んでください。

解決策

以下を順番に検証します。

  1. 接続の詳細failureMessageを読み取ります。このフィールドでは、接続のステータスが失敗し、ステータスが CREATE_FAILEDまたは の場合に存在する理由について説明しますDELETE_FAILED。

aws devops-agent describe-private-connection \ --name my-mcp-tool-connection

failureMessage は の出力にも表示されますlist-private-connections。フィールドで原因に名前を付けた場合は、それに対処します。フィールドがない場合、理由が返されなかったため、残りのチェックを続行します。

  1. ポート範囲は有効な形式を使用します。各ポート範囲を単一のポート ( など443) または異なる開始ポートと終了ポートを持つ真の範囲 ( など) として指定します8080-8090。開始と終了が同じ (例: 443-443) である「範囲」は拒否されます。最大 11 個のポート範囲を指定できます。

  2. サブネットには使用可能な IP アドレスがあります。リソースゲートウェイは、指定したサブネットに Elastic Network Interface (ENIs) をプロビジョニングします。これらのサブネットを使い果たすと、作成は失敗します。空きアドレス空間があるサブネットを選択します。

  3. サブネットはサポートされているアベイラビリティーゾーンにあります。Amazon VPC Lattice は、すべてのアベイラビリティーゾーンをサポートしているわけではありません。以下を実行し、「プライベート接続の作成」に記載されているサポートされていないゾーンと比較します。

aws ec2 describe-subnets \ --subnet-ids <your-subnet-ids> \ --query 'Subnets[*].[SubnetId,AvailabilityZoneId]'

  1. Amazon VPC Lattice サービスクォータに達していません。Amazon VPC Lattice クォータ、特にリソースゲートウェイの制限に対してアカウントを確認します。

  2. IAM ポリシーまたは SCP がサービスにリンクされたロールをブロックしていません。サービスマネージドリソースゲートウェイは、サービスにリンクされたロールを介して作成されます。組織に Amazon VPC Lattice または Amazon EC2 API アクションを制限するサービスコントロールポリシー (SCPs) がある場合は、サービスにリンクされたロールがこれらのリソースを作成することを許可していることを確認してください。

これらの項目をすべて検証した後も接続が失敗し続ける場合は、 AWS サポートにお問い合わせください。

接続はアクティブですが、到達可能性エラーで機能登録が失敗する

症状

プライベート接続はアクティブ状態になりますが、それを使用する機能プロバイダー (MCP サーバーなど) を登録すると、登録は失敗します。MCP サーバーの場合、エラーメッセージは到達可能性チェックが失敗した方法を示します。次のいずれかが表示されます。

  • The MCP server at '<endpoint>' timed out while initializing the session. (類似バリアントはリソースの一覧表示を指します)

  • Unable to connect to the MCP server at <endpoint>. The connection was interrupted. Verify the server is running and accessible, then try again.

  • Unable to access tools from the MCP server at '<endpoint>' ...

  • Could not complete request to provider. ( として表示される場合もありますAPI error: 504)

原因

Active に到達するプライベート接続は、VPC へのネットワークパスが確立されていることを確認します。ターゲットサービスが予想されるアドレスとポートで応答していることは確認されません。機能プロバイダーを登録すると、 AWS DevOps Agent はエンドポイントが到達可能で応答していることを検証します。ここで、ターゲットの設定ミスが表示されます。メッセージは、失敗したレイヤーを示します。

  • タイムアウトメッセージは、接続がリッスンサービスに到達しなかったことを意味します。ほとんどの場合、接続のポート範囲にエンドポイントのポートが含まれていないか、ホストアドレスまたは DNS 解決が正しくないか、セキュリティグループがトラフィックをブロックしています。

  • 接続が中断されたメッセージは、通常、TLS ハンドシェイクの失敗またはサービスが接続を閉じることによって、接続がリセットまたは削除されたことを意味します。

  • ツールにアクセスできないメッセージは、エンドポイントがリクエストに応答したが拒否したことを意味します。これは通常、ネットワークの問題ではなく、認可またはプロバイダー側のエラーです。

  • プロバイダーメッセージへのリクエストを完了できませんでした。これは、プライベート接続を介してエンドポイントへのリクエストを完了できなかった一般的な障害です。以下の解決手順を確認します。

VPC の Amazon EC2 インスタンスまたは AWS CloudShell セッションからのリクエストが成功すると、そのテスト環境からサービスにアクセスできることが確認されます。リソースゲートウェイが同じエンドポイント URL、ポート、DNS ターゲット、または TLS 設定を使用しているかどうかは確認されません。

確認する方法

  1. パスやデフォルト以外のポートなど、登録した正確なエンドポイント URL を使用してテストを繰り返します。

  2. エンドポイント URL のポートがプライベート接続のポート範囲に含まれていることを確認します。

  3. プライベート接続のホストアドレスが、別のアプリケーションポートのタスクまたはインスタンス IP ではなく、そのポートの TLS を終了するロードバランサーまたはサービスに解決されていることを確認します。

  4. ターゲットが TLS 1.2 以降で HTTPS を提供し、予想される証明書チェーンを提示することを確認します。

  5. リソースゲートウェイセキュリティグループがターゲットポートでのアウトバウンドトラフィックを許可し、ターゲットセキュリティグループが対応するインバウンドトラフィックを許可していることを確認します。

解決策

  • 接続のポート範囲にエンドポイントのポートが含まれていることを確認します。プライベート接続は、作成時に設定したポート範囲のトラフィックのみを転送します。ポート範囲を指定しなかった場合、接続ではポート のみが許可されます443。接続は、説明的なエラーなしでトラフィックを他のポートにドロップします。ドロップされたトラフィックは、タイムアウト、Unable to access toolsエラー、またはCould not complete request to provider.エラーとして表示されます。これは通常、非標準ポート ( などhttps://tools.example.com:8089/mcp) のエンドポイントに影響します。同じ VPC 内の EC2 インスタンスcurlから成功しても、これは除外されません。このテストでは、プライベート接続を完全にバイパスします。作成後にポート範囲を変更することはできません。プライベート接続を削除し、エンドポイント URL のすべてのポートを含むポート範囲を使用して再作成し、機能プロバイダーを再度登録します。

  • リソースゲートウェイがターゲットに到達できることを確認します。これは、ターゲットが別の AWS アカウントまたはオンプレミスで実行される場合に除外する最初のものです。サービスマネージドモードでは、リソースゲートウェイは、VPC がターゲットへのルートを必要とするように、プライベート接続と同じアカウントで、指定した VPC とサブネットに作成されます。アクティブに到達する接続は、ゲートウェイのネットワークインターフェイスが作成され、正常であることを意味します。サービスに到達できるわけではありません。接続のモードとゲートウェイの VPC を確認し、ルートを確認します。

aws devops-agent list-private-connections aws vpc-lattice list-resource-gateways

ゲートウェイの VPC にターゲットへのルートがない場合は、VPC ピアリング、 AWS Transit Gateway、または仮想プライベートネットワーク (VPN) 接続を介してルートを追加するか、セルフマネージドモードを使用してゲートウェイをターゲットのアカウントに移動します。「プライベート接続を作成する」を参照してください。

  • タスクやインスタンスの IP ではなく、ロードバランサーの DNS をポイントします。頻繁な原因は、設定したポート ( など8100) で TLS を終了するロードバランサーではなく、アプリケーションポート ( など) のコンテナタスクまたはインスタンス IP に解決される DNS レコードまたはホストアドレスです443。ホストアドレスが、ターゲットポートで実際に HTTPS を提供するエンドポイントに解決されることを確認します。

  • サービスが設定されたポートで HTTPS を提供していることを確認します。ターゲットは、接続のポート範囲に含まれるポートで、最小 TLS バージョン 1.2 の HTTPS を提供する必要があります。

  • セキュリティグループのルールを双方向で確認します。リソースゲートウェイ ENIs にアタッチされたセキュリティグループがターゲットポートでアウトバウンドトラフィックを許可し、サービスのセキュリティグループがそのポートでインバウンドトラフィックを許可していることを確認します。VPC CIDR 範囲内の Amazon VPC Lattice データプレーン IPs からトラフィックが到着します。セキュリティグループ参照 (ENI セキュリティグループをソースとして許可) を使用するか、VPC CIDR からのインバウンドを許可できます。「プライベート接続のファイアウォールルールの設定」を参照してください。

  • プライベート CA の証明書チェーン全体を検証します。プライベート認証機関がサービスの TLS 証明書を発行した場合は、接続の作成時に PEM エンコードされた証明書チェーン全体を指定します。リーフ証明書を最初に配置し、次に中間、次にルートを配置します。チェーンが不完全な場合、ネットワークパスが上であっても TLS ハンドシェイクは失敗します。が生成するエラーメッセージについては、「プロバイダーの TLS 証明書が信頼されていません」を参照してください。

  • ターゲットが実行されていることを確認します。登録を完了する前に、サービスが稼働していて、予想されるポートで接続を受け入れていることを確認してください。

プロバイダーの TLS 証明書が信頼されていない

症状

機能プロバイダーの登録または使用は、証明書エラーで失敗します。表現は機能タイプによって異なりますが、これらはすべて同じ問題クラスを記述します。

  • Could not establish a trusted TLS connection to the provider host: its certificate could not be validated against a publicly trusted certificate authority.

  • The server is using a self-signed TLS certificate. Use a certificate from a publicly trusted certificate authority.

  • The server's TLS certificate could not be verified. Ensure the full certificate chain is served and issued by a publicly trusted certificate authority.

  • The server's TLS certificate has expired. Renew the certificate.

  • The server's TLS certificate does not match the endpoint hostname. Ensure the certificate covers the endpoint's domain.

原因

AWS DevOps エージェントは、サービスが提示した証明書チェーンを検証できませんでした。一般的な原因は、プライベートまたは内部認証機関 (CA) によって発行された証明書、中間証明書が欠落しているチェーン、チェーン内の期限切れ証明書、またはエンドポイント URL のホスト名をカバーしていない証明書です。

注記

これらのメッセージは、パブリックに信頼された CA からの証明書を要求しますが、プライベート CA はサポートされています。解決ステップで説明されているように、プライベート接続でチェーンを指定します。

確認する方法

ターゲットに到達できる Amazon EC2 インスタンスまたは AWS CloudShell セッションから、設定したポートでサービスが示すチェーンを検査し、その上部に署名した CA を確認します。

openssl s_client -connect <your-host-address>:<port> -showcerts

内部 CA が証明書に署名した場合は、接続でチェーンを指定します。パブリック CA が署名した場合、サービスが送信するチェーンはおそらく不完全です。

解決策

  • プライベート CA からの証明書の場合は、プライベート接続でチェーン全体を指定します。コンソールの証明書パブリックキー、または の certificateフィールドをcreate-private-connection、PEM エンコードされたチェーン全体に設定します。最初にリーフ証明書、次にすべての中間 CA 証明書、次にルートです。「プライベート接続を作成する」を参照してください。

  • パブリック CA からの証明書の場合は、完全なチェーンを送信します。リーフのみではなく、リーフ証明書とすべての中間証明書を送信するようにサービスを設定します。

  • チェーン内の期限切れ証明書を置き換えます。

  • 証明書がエンドポイント URL のホスト名をカバーしていることを確認します。

OAuth トークン交換に到達できない

症状

プライベート接続を介して OAuth ベースの MCP サーバー (クライアント認証情報または 3LO) または OAuth クライアント認証情報を使用するリモートエージェントを登録しましたが、MCP サーバーまたはリモートエージェントエンドポイントに到達可能であってもトークン交換は失敗します。

原因

OAuth ベースの機能プロバイダーの場合、 AWS DevOps Agent はターゲット URL (MCP サーバーまたはリモートエージェントエンドポイント) と交換 URL (OAuth トークン交換エンドポイント) の 2 つのエンドポイントを呼び出します。1 つのプライベート接続を選択すると、両方のエンドポイントに適用されます。2 つのエンドポイントが異なるネットワークパスを介してのみ到達可能な場合、単一のプライベート接続を両方にルーティングすることはできません。

解決策

  • 両方のエンドポイントが同じパス経由で到達可能な場合は、プライベート接続のホストアドレスが MCP サーバーまたはリモートエージェントエンドポイントとトークン交換エンドポイントの両方にルーティングできることを確認します。

  • エンドポイントで異なるネットワークパスが必要な場合は、単一の ではなくエンドポイントごとのフィールドを使用しますprivateConnectionName。targetUrlPrivateConnectionName MCP サーバーまたはリモートエージェントエンドポイントとトークン交換エンドポイントexchangeUrlPrivateConnectionNameに を設定します。1 つだけ設定した場合、もう 1 つのエンドポイントはパブリックインターネット経由で到達し、他のプライベート接続にはフォールバックしません。エンドポイントごとの名前を同じリクエストprivateConnectionNameで と組み合わせることはできません。「Routing the endpoint and the OAuth token exchange through different private connections」を参照してください。

プライベート接続は使用中は削除できません

症状

プライベート接続の削除が で失敗する Private connection '<name>' is in use by one or more services. Deregister the services first.

原因

登録された機能プロバイダーがプライベート接続を参照している間は、プライベート接続を削除することはできません。 AWS DevOps Agent はリソースを削除する前に削除を拒否するため、接続は現在の状態のままになります。

解決策

  1. 接続を使用する機能プロバイダーを特定し、登録を解除するか、使用しないように更新します。

  2. プライベート接続を削除します。

エージェントスペースから機能プロバイダーを削除することは、登録解除とは異なります。登録はアカウントレベルに存在するため、すべてのエージェントスペースから削除してから、接続を削除する前に登録を削除します。

リソースゲートウェイまたは ENIs、接続を削除した後も残ります。

症状

マネージドリソースゲートウェイとその ENIsされることを想定していましたが、VPC には引き続き表示されます。これにより、ENI 料金が発生し、 などのクリーンな VPC に依存するオペレーションがブロックされる可能性がありますterraform destroy。

原因

マネージドリソースゲートウェイと ENIs は、 AWS DevOps エージェントを介してプライベート接続を削除する場合にのみ削除されます。最も一般的な理由は、実際には呼び出DeletePrivateConnectionされなかったこと、またはAWSAIDevOpsManagedタグがマネージドリソースから削除されたため削除を続行できないことです。

重要

AWS DevOps エージェントは、管理するリソース (リソースゲートウェイとその ENIs) に でタグ付けしますAWSAIDevOpsManaged。サービスにリンクされたロールは、このタグを持つリソースでのみ動作するため、AWSAIDevOpsManagedタグ を削除または変更しないでください。タグがない場合、 DeletePrivateConnectionはリソースをクリーンアップできず、削除は失敗します。

解決策

  • AWS DevOps エージェントを介して接続を削除します。コンソール (キャパシティープロバイダー > プライベート接続 > アクション > 削除) または CLI を使用します。

aws devops-agent delete-private-connection \ --name my-mcp-tool-connection

AWS DevOps Agent が VPC からマネージドリソースゲートウェイと ENIs を削除するDELETE_IN_PROGRESSと、ステータスは に変わります。

  • 削除に失敗した場合は、AWSAIDevOpsManagedタグがまだ存在することを確認します。タグがリソースゲートウェイまたはその ENIs から削除された場合は、そのタグをそれらのリソースに再適用し、削除を再度実行します。

  • マネージドリソースゲートウェイを直接削除しないでください。リソースゲートウェイはアカウント内で読み取り専用であり、 AWS DevOps Agent によって完全に管理されるため、Amazon VPC Lattice から自分で削除することはできません。プライベート接続を削除すると、削除がトリガーされます。

  • プライベート接続を削除し、 タグが存在し、削除が完了した後もリソースゲートウェイまたは ENIsが残っている場合は、 AWS サポートに連絡してリソースを調整します。

ヘルプのリクエスト

問題の関連セクションを操作しても問題が解決しない場合は、 AWS サポートにお問い合わせください。サポートがネットワークパスを調査できるように、プライベート接続名、現在のステータス、 AWS リージョン、ターゲットホストアドレスとポートを含めます。