Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Solución de problemas de conexiones privadas
En esta página se describen los problemas comunes que pueden surgir al crear o usar un Conexión a herramientas alojadas de forma privada for AWS DevOps Agent y cómo resolverlos. En cada sección se describe un síntoma, las causas más probables y los pasos para solucionarlo.
Para obtener información general sobre cómo funcionan las conexiones privadas, consulteConexión a herramientas alojadas de forma privada.
La dirección de un host DNS no se resuelve o el tráfico llega al lugar equivocado
Síntoma
Creaste una conexión privada con un nombre DNS para la dirección de host, pero la conexión no puede comunicarse con tu servicio. Esto es más común cuando el servicio de destino es una GitLab instancia autohospedada, un balanceador de carga de aplicaciones (ALB) interno o un servidor MCP cuyo nombre de host solo existe en la VPC.
Un error de resolución de DNS no produce ningún mensaje que mencione el DNS. En su lugar, aparece como un error genérico de proveedor o de accesibilidad cuando registras o utilizas el proveedor de capacidades. Por ejemplo, es posible que veas Could not complete request to provider.Unable to connect to the MCP server at <endpoint>. The connection was interrupted., o incluso, un error de autenticación del tipo «Authentication with provider failed.Como el mensaje no apunta al DNS», realiza la siguiente comprobación para confirmar la causa.
Causa
De forma predeterminada, una conexión privada resuelve la dirección del host mediante un DNS público (dnsResolution: PUBLIC). Si su nombre de host solo tiene un registro en una zona alojada privada, una regla de Amazon Route 53 Resolver o un servidor DNS local, la resolución pública fallará y la conexión nunca llegará al servicio.
¿Cómo confirmar que el DNS es la causa
Comprueba si tu dirección de host solo se resuelve dentro de tu VPC. Desde una instancia o AWS CloudShell sesión de Amazon EC2 en la misma VPC, ejecute.
nslookup <your-host-address>Si se resuelve allí, pero no a partir de un DNS público, y su conexión privada lo utilizadnsResolution: PUBLIC, la causa es la resolución del DNS.Realice la prueba con la dirección IP en lugar del nombre. Cree temporalmente una conexión privada que utilice la dirección IP privada del objetivo (o una IP de balanceador de cargas) como dirección del host, en lugar del nombre DNS. Si la conexión llega entonces a tu servicio, el error anterior se debió a la resolución del DNS, no a la ruta de red ni al servicio en sí.
Resolución
Si su nombre de host solo se resuelve dentro de su VPC, defina el modo de resolución de DNS en En VPC (
IN_VPC) al crear la conexión. En este modo, la dirección de host se resuelve desde el contexto de la VPC, por lo que los nombres de host exclusivamente privados se resuelven correctamente. Consulta Crear una conexión privada.El modo de resolución de DNS se elige en el momento de la creación y se aplica a la dirección de host que proporciones. No puede cambiar la forma en que la puerta de enlace de recursos administrada por el servicio resuelve el DNS después de su creación, así que elija el modo correcto desde el principio. Si seleccionó el modo incorrecto, elimine la conexión y vuelva a crearla con el modo correcto.
Si especifica una dirección IP (en lugar de un nombre DNS) para la dirección del host, el modo de resolución de DNS no tiene efecto y el tráfico va directamente a esa IP.
Si no puedes usarla
IN_VPCpara la configuración, puedes apuntar la dirección del host a la dirección IP privada del objetivo o al nombre DNS de un balanceador de cargas que se pueda resolver públicamente pero que se reenvíe a una IP privada.
La conexión está bloqueada en No se pudo crear
Síntoma
Tras crear una conexión privada, la consola muestra el estado como Fallo de conexión (y describe-private-connection devuelve el estado deCREATE_FAILED).
Causa
La mayoría de las veces, la creación fallida se debe a un problema de configuración en la solicitud o en la VPC, y no a un error de servicio. Cuando se produce un error en una conexión, el AWS DevOps agente describe el motivo en el failureMessage campo, por lo que debes leer ese campo antes de completar la lista de verificación.
Resolución
Compruebe lo siguiente, en orden:
Lea
failureMessagelos detalles de la conexión. Este campo describe por qué una conexión tiene un estado fallido y está presente cuando el estado esCREATE_FAILEDoDELETE_FAILED:
aws devops-agent describe-private-connection \ --name my-mcp-tool-connection
failureMessagetambién aparece en la salida delist-private-connections. Si el campo indica la causa, actúe en consecuencia. Si el campo está ausente, significa que no se ha devuelto ningún motivo, así que continúa con las comprobaciones restantes.
Los rangos de puertos utilizan un formato válido. Especifique cada rango de puertos como un solo puerto (por ejemplo
443) o un rango genuino con diferentes puertos de inicio y final (por ejemplo,8080-8090). Se rechaza un «rango» cuyo inicio y final sean los mismos (por ejemplo,443-443). Puede especificar hasta 11 rangos de puertos.Sus subredes tienen direcciones IP disponibles. La puerta de enlace de recursos aprovisiona interfaces de red elásticas (ENI) en las subredes que especifique. Si esas subredes están agotadas, se produce un error en la creación. Elija subredes con espacio de direcciones libre.
Sus subredes se encuentran en las zonas de disponibilidad compatibles. Amazon VPC Lattice no admite todas las zonas de disponibilidad. Ejecute lo siguiente y compárelo con las zonas no compatibles que figuran en Crear una conexión privada:
aws ec2 describe-subnets \ --subnet-ids <your-subnet-ids> \ --query 'Subnets[*].[SubnetId,AvailabilityZoneId]'
No ha alcanzado las cuotas de servicio de Amazon VPC Lattice. Comprueba si tu cuenta cumple con las cuotas de Amazon VPC Lattice, especialmente con los límites de las pasarelas de recursos.
Ninguna política de IAM o SCP bloquea el rol vinculado al servicio. La puerta de enlace de recursos administrada por el servicio se crea a través de una función vinculada al servicio. Si su organización cuenta con políticas de control de servicios (SCP) que restringen las acciones de las API de Amazon EC2 o Amazon VPC Lattice, asegúrese de que permiten al rol vinculado al servicio crear estos recursos.
Si la conexión sigue fallando después de verificar todos estos elementos, ponte en contacto con el equipo de soporte. AWS
La conexión está activa, pero el registro de la capacidad falla y se produce un error de accesibilidad
Síntoma
La conexión privada pasa al estado Activa, pero cuando se registra un proveedor de capacidades (por ejemplo, un servidor MCP) que la usa, se produce un error en el registro. En el caso de un servidor MCP, el mensaje de error describe cómo falló la comprobación de accesibilidad. Es posible que aparezca una de las siguientes opciones:
The MCP server at '<endpoint>' timed out while initializing the session.(una variante similar se refiere a la publicación de recursos)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.(también puede aparecer comoAPI error: 504)
Causa
Una conexión privada que llegue a Active confirma que la ruta de red a su VPC está establecida. No confirma que el servicio de destino esté respondiendo en la dirección y el puerto esperados. Cuando registras un proveedor de capacidades, el AWS DevOps agente comprueba que el punto final es accesible y responde, y aquí es donde aparece un objetivo mal configurado. El mensaje indica qué capa ha fallado:
Un mensaje que indica que se ha agotado el tiempo de espera significa que la conexión nunca llegó a un servicio de escucha. La mayoría de las veces, los intervalos de puertos de la conexión no incluyen el puerto del punto final, la dirección del host o la resolución de DNS son incorrectas o un grupo de seguridad bloquea el tráfico.
Un mensaje de interrupción de la conexión significa que la conexión se restableció o se interrumpió, normalmente debido a un error del protocolo de enlace TLS o al cierre de la conexión por parte del servicio.
Un mensaje de no se puede acceder a las herramientas significa que el terminal respondió pero rechazó la solicitud. Por lo general, se trata de un error de autorización o del proveedor, más que de un problema de red.
Un mensaje de «No se pudo completar la solicitud al proveedor» es un error general al enviar la solicitud al terminal a través de la conexión privada. Revisa los pasos de resolución que se indican a continuación.
Una solicitud satisfactoria de una instancia o AWS CloudShell sesión de Amazon EC2 en su VPC confirma que se puede acceder al servicio desde ese entorno de prueba. No confirma que la puerta de enlace de recursos utilice la misma URL de punto final, puerto, destino de DNS o configuración de TLS.
Cómo confirmar
Repita la prueba con la URL exacta del punto final que registró, incluida su ruta y cualquier puerto que no sea el predeterminado.
Confirme que el puerto de la URL del punto final esté incluido en los rangos de puertos de la conexión privada.
Confirme que la dirección de host de la conexión privada se dirija al balanceador de cargas o al servicio que finaliza el TLS en ese puerto, en lugar de a la IP de una tarea o instancia en un puerto de aplicación diferente.
Confirme que el destino utilice HTTPS con TLS 1.2 o una versión posterior y que presente la cadena de certificados esperada.
Confirme que el grupo de seguridad de la puerta de enlace de recursos permita el tráfico saliente en el puerto de destino y que el grupo de seguridad de destino permita el tráfico entrante correspondiente.
Resolución
Confirme que los rangos de puertos de la conexión incluyan el puerto del punto final. Una conexión privada solo reenvía el tráfico en los rangos de puertos que configuró al crearla. Si no especificó los intervalos de puertos, la conexión solo permite el puerto
443. La conexión envía el tráfico a cualquier otro puerto sin que se produzca un error descriptivo. El tráfico interrumpido aparece como un tiempo de espera, unUnable to access toolserror o unCould not complete request to provider.error. Esto suele afectar a los terminales de los puertos no estándar (por ejemplo,).https://tools.example.com:8089/mcpSi se realiza correctamentecurldesde una instancia EC2 en la misma VPC, no se descarta que esta prueba omita por completo la conexión privada. No puede cambiar los intervalos de puertos después de la creación. Elimine la conexión privada, vuelva a crearla con rangos de puertos que incluyan todos los puertos de la URL de su punto final y vuelva a registrar el proveedor de capacidades.Confirme que la puerta de enlace de recursos puede alcanzar su objetivo. Esto es lo primero que hay que descartar cuando el objetivo se ejecuta en una AWS cuenta diferente o en las instalaciones. En el modo administrado por servicios, la puerta de enlace de recursos se crea en la VPC y las subredes que especificaste, en la misma cuenta que la conexión privada, por lo que la VPC necesita una ruta hacia tu destino. Una conexión activa solo significa que las interfaces de red de la puerta de enlace se crearon y están en buen estado; no significa que puedan acceder a tu servicio. Compruebe el modo de la conexión y la VPC de la puerta de enlace y, a continuación, confirme la ruta:
aws devops-agent list-private-connections aws vpc-lattice list-resource-gateways
Si la VPC de la puerta de enlace no tiene ninguna ruta hacia el destino, añada una mediante la interconexión de VPC, AWS Transit Gateway o una conexión de red privada virtual (VPN), o mueva la puerta de enlace a la cuenta del destino mediante el modo autogestionado. Consulte Crear una conexión privada.
Apunte el DNS al balanceador de cargas, no a la IP de una tarea o instancia. Una causa frecuente es que un registro DNS o una dirección de host se resuelva en una IP de instancia o tarea de contenedor en un puerto de aplicación (por ejemplo
8100) en lugar del balanceador de cargas que termina TLS en el puerto que configuraste (por ejemplo,).443Confirma que la dirección del host se resuelve en el punto final que realmente ofrece HTTPS en el puerto de destino.Confirme que el servicio ofrece HTTPS en el puerto configurado. El destino debe ofrecer HTTPS con una versión mínima de TLS 1.2 en un puerto incluido en los intervalos de puertos de la conexión.
Compruebe las reglas del grupo de seguridad en ambas direcciones. Verifique que el grupo de seguridad conectado a la pasarela de recursos eNIS permita el tráfico saliente en el puerto de destino y que el grupo de seguridad de su servicio permita el tráfico entrante en ese puerto. El tráfico llega desde las IP del plano de datos de Amazon VPC Lattice que estén dentro del rango de CIDR de su VPC. Puede utilizar la referencia a grupos de seguridad (permitir el grupo de seguridad ENI como fuente) o permitir la entrada desde el CIDR de la VPC. Consulte Configurar las reglas de firewall para conexiones privadas.
Verifique la cadena completa de certificados de una CA privada. Si una autoridad certificadora privada emitió el certificado TLS de tu servicio, proporciona la cadena de PEM-encoded certificados completa al crear la conexión. Coloca primero el certificado hoja, luego los intermedios y, a continuación, el certificado raíz. Si la cadena está incompleta, el protocolo de enlace TLS falla aunque la ruta de red esté activa. Para ver los mensajes de error que esto produce, consulta El certificado TLS del proveedor no es de confianza.
Confirma que el objetivo se está ejecutando. Asegúrese de que su servicio esté activo y de que acepte conexiones en el puerto previsto antes de completar el registro.
El certificado TLS del proveedor no es de confianza
Síntoma
El registro o el uso de un proveedor de capacidades fallan y se produce un error en el certificado. La redacción depende del tipo de capacidad, pero todas describen el mismo tipo de problema:
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.
Causa
AWS DevOps El agente no pudo validar la cadena de certificados que presentaba su servicio. Las causas más comunes son un certificado emitido por una autoridad de certificación (CA) privada o interna, una cadena a la que le faltan los certificados intermedios, un certificado caducado en la cadena o un certificado que no incluye el nombre de host en la URL del punto final.
nota
Estos mensajes solicitan un certificado de una CA de confianza pública, pero se admite una CA privada. Introduzca la cadena en la conexión privada, tal y como se describe en los pasos de resolución.
Cómo confirmar
Desde una instancia o AWS CloudShell sesión de Amazon EC2 que pueda alcanzar su objetivo, inspeccione la cadena que presenta su servicio en el puerto que configuró y compruebe qué CA firmó la parte superior de la misma:
openssl s_client -connect <your-host-address>:<port> -showcerts
Si una CA interna firmó el certificado, introduzca la cadena en la conexión. Si lo firmó una CA pública, es probable que la cadena que envía su servicio esté incompleta.
Resolución
En el caso de un certificado de una CA privada, introduzca la cadena completa en la conexión privada. Establezca la clave pública del certificado en la consola, o en el
certificatecampo decreate-private-connection, en la PEM-encoded cadena completa: primero el certificado hoja, luego todos los certificados de CA intermedios y, a continuación, el certificado raíz. Consulte Crear una conexión privada.Para obtener un certificado de una CA pública, envíe la cadena completa. Configure su servicio para enviar el certificado Leaf más todos los certificados intermedios, no solo el Leaf.
Sustituya cualquier certificado caducado de la cadena.
Confirme que el certificado incluye el nombre de host de la URL de su punto final.
No se puede acceder al intercambio de tokens de OAuth
Síntoma
Has registrado un servidor OAuth-based MCP (credenciales de cliente o 3LO) o un agente remoto que usa las credenciales de cliente de OAuth a través de una conexión privada, pero el intercambio de tokens falla aunque se pueda acceder al extremo del servidor MCP o del agente remoto.
Causa
En el OAuth-based caso de los proveedores de capacidades, el AWS DevOps agente llama a dos puntos finales: la URL de destino (el punto final del servidor MCP o del agente remoto) y la URL de intercambio (el punto final del intercambio de tokens de OAuth). Cuando seleccionas una única conexión privada, se aplica a ambos extremos. Si solo se puede acceder a los dos extremos a través de rutas de red diferentes, una sola conexión privada no puede enrutarse a ambos.
Resolución
Si se puede acceder a ambos extremos a través de la misma ruta, asegúrese de que la dirección host de la conexión privada pueda dirigirse tanto al punto final del servidor MCP o del agente remoto como al punto final del intercambio de tokens.
Si los puntos finales requieren rutas de red diferentes, utilice los campos por punto final en lugar de uno solo.
privateConnectionNameConfiguretargetUrlPrivateConnectionNamepara el punto final del servidor MCP o del agente remoto yexchangeUrlPrivateConnectionNamepara el punto final del intercambio de tokens. Si configuras solo uno, se accede al otro punto final a través de Internet público y no se recurre a la otra conexión privada. No puedes combinar los nombres de cada punto finalprivateConnectionNameen la misma solicitud. Consulta Cómo enrutar el punto final y el intercambio de tokens de OAuth a través de diferentes conexiones privadas.
No se puede eliminar una conexión privada mientras está en uso
Síntoma
Se produce un error al eliminar una conexión privada con Private connection '<name>' is in use by one or more services. Deregister the services first.
Causa
No se puede eliminar una conexión privada mientras un proveedor de capacidades registrado siga haciendo referencia a ella. AWS DevOps El agente rechaza la eliminación antes de eliminar cualquier recurso, por lo que la conexión permanece en su estado actual.
Resolución
Identifique los proveedores de capacidades que utilizan la conexión y anule su registro o actualícelos para que dejen de utilizarla.
Elimine la conexión privada.
Eliminar un proveedor de capacidades de un espacio de agente no es lo mismo que anular su registro. Existe un registro a nivel de cuenta, así que elimínelo de todos los espacios de agente y, a continuación, elimine el registro antes de eliminar la conexión.
La pasarela de recursos o los ENI permanecen después de eliminar una conexión
Síntoma
Esperabas eliminar la pasarela de recursos gestionada y sus ENI, pero siguen apareciendo en tu VPC. Esto puede generar cargos por ENI y bloquear las operaciones que dependen de una VPC limpia, por ejemplo. terraform destroy
Causa
La puerta de enlace de recursos gestionada y las ENI solo se eliminan cuando se elimina la conexión privada a través del agente. AWS DevOps Los motivos más comunes por los que permanecen son porque nunca DeletePrivateConnection se llamó realmente o porque la AWSAIDevOpsManaged etiqueta se eliminó de los recursos administrados, por lo que la eliminación no puede continuar.
importante
AWS DevOps El agente etiqueta los recursos que administra (la puerta de enlace de recursos y sus ENI). AWSAIDevOpsManaged El rol vinculado a un servicio solo puede actuar en los recursos que contienen esta etiqueta, por lo que no debe eliminarla ni modificarla. AWSAIDevOpsManaged Si falta la etiqueta, no se DeletePrivateConnection pueden limpiar los recursos y se produce un error en la eliminación.
Resolución
Elimine la conexión a través del AWS DevOps agente. Utilice la consola (Proveedores de capacidad > Conexiones privadas > Acciones > Eliminar) o la CLI:
aws devops-agent delete-private-connection \ --name my-mcp-tool-connection
El estado cambia a DELETE_IN_PROGRESS mientras el AWS DevOps agente elimina la puerta de enlace de recursos administrada y los ENI de su VPC.
Si la eliminación falla, confirme que la
AWSAIDevOpsManagedetiqueta sigue presente. Si la etiqueta se quitó de la puerta de enlace de recursos o de sus ENI, vuelva a aplicarla a esos recursos y, a continuación, vuelva a ejecutar la eliminación.No intentes eliminar la puerta de enlace de recursos administrada directamente. La pasarela de recursos es de solo lectura en su cuenta y el AWS DevOps agente la administra en su totalidad, por lo que no puede eliminarla usted mismo a través de Amazon VPC Lattice. La eliminación de la conexión privada es lo que desencadena su eliminación.
Si eliminaste la conexión privada, la etiqueta está presente y la puerta de enlace de recursos o los ENI permanecen una vez finalizada la eliminación, ponte en contacto con el equipo de AWS soporte para conciliar los recursos.
¿Solicita ayuda
Si sigues leyendo la sección correspondiente a tu problema y el problema persiste, ponte en contacto con el equipo de AWS soporte. Incluye el nombre de tu conexión privada, su estado actual, la AWS región y la dirección del host y el puerto de destino para que el servicio de asistencia pueda investigar la ruta de la red.
Temas relacionados
