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 falla y la conexión nunca llega 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). La respuesta no suele incluir un motivo detallado del error, por lo que no aparece ningún mensaje de error sobre el que actuar.
Causa
Los errores de creación suelen deberse a un problema de configuración en la solicitud o en la VPC, y no a un error de servicio. Como no siempre aparece un motivo detallado del error, sigue la siguiente lista de comprobación aunque no aparezca ningún mensaje de error.
Resolución
Compruebe lo siguiente, en orden:
Los intervalos 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 como unAPI 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. Al registrar 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, la dirección del host, el puerto o la resolución de DNS son incorrectos 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.
Resolución
Dirija 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 usar la referencia a grupos de seguridad (permita que el grupo de seguridad ENI sea el origen) 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.
Confirme 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.
No se puede acceder al intercambio de tokens de OAuth
Síntoma
Has registrado un proveedor de capacidades de servidor OAuth-based MCP (credenciales de cliente o 3LO) a través de una conexión privada, pero el intercambio de tokens falla aunque se pueda acceder al punto final del servidor MCP.
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) 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 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.
privateConnectionNametargetUrlPrivateConnectionNameEstablézcalos para el punto final del servidor MCP yexchangeUrlPrivateConnectionNamepara el punto final del intercambio de tokens. Si configuras solo uno, se llega al otro punto final a través de la Internet pública 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.
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 se produce un error en la eliminación, 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
