Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Risoluzione dei problemi relativi alle connessioni private
Questa pagina descrive i problemi più comuni che potresti riscontrare durante la creazione o l'utilizzo di un Connessione a strumenti ospitati privatamente for AWS DevOps Agent e come risolverli. Ogni sezione descrive un sintomo, le cause più probabili e i passaggi per risolverlo.
Per una panoramica del funzionamento delle connessioni private, consultaConnessione a strumenti ospitati privatamente.
Un indirizzo host DNS non si risolve o il traffico arriva nel posto sbagliato
Sintomo
Hai creato una connessione privata utilizzando un nome DNS per l'indirizzo host, ma la connessione non può raggiungere il tuo servizio. Ciò è più comune quando il servizio di destinazione è un' GitLab istanza ospitata autonomamente, un Application Load Balancer (ALB) interno o un server MCP il cui nome host esiste solo all'interno del VPC.
Un errore di risoluzione DNS non produce un messaggio che menziona il DNS. Al contrario, si presenta come un errore generico di raggiungibilità o del provider quando ci si registra o si utilizza il provider di funzionalità. Ad esempio, potresti visualizzare Could not complete request to provider. o persino un errore di autenticazione come Authentication with provider failed. Poiché il messaggio non punta al DNS, utilizza il seguente controllo per confermare la causa. Unable to connect to the MCP server at <endpoint>. The connection was interrupted.
Causa
Per impostazione predefinita, una connessione privata risolve l'indirizzo dell'host utilizzando il DNS pubblico (). dnsResolution: PUBLIC Se il tuo nome host ha solo un record in una zona ospitata privata, una regola Amazon Route 53 Resolver o un server DNS locale, la risoluzione pubblica fallisce e la connessione non raggiunge mai il tuo servizio.
Come confermare che il DNS è la causa
Verifica se il tuo indirizzo host si risolve solo all'interno del tuo VPC. Esegui da un'istanza o AWS CloudShell sessione di Amazon EC2 nello stesso VPC.
nslookup <your-host-address>Se si risolve lì ma non da un DNS pubblico e la tua connessione privata lo utilizzadnsResolution: PUBLIC, la causa è la risoluzione DNS.Effettua il test con l'indirizzo IP anziché con il nome. Crea temporaneamente una connessione privata che utilizzi l'indirizzo IP privato della destinazione (o un IP di bilanciamento del carico) per l'indirizzo host anziché il nome DNS. Se la connessione raggiunge quindi il servizio, l'errore precedente era la risoluzione DNS, non il percorso di rete o il servizio stesso.
Resolution (Risoluzione)
Se il tuo nome host si risolve solo all'interno del tuo VPC, imposta la modalità di risoluzione DNS su In VPC ()
IN_VPCquando crei la connessione. In questa modalità, l'indirizzo host viene risolto all'interno del tuo contesto VPC, quindi i nomi host solo privati vengono risolti correttamente. Vedi Creare una connessione privata.La modalità di risoluzione DNS viene scelta al momento della creazione e si applica all'indirizzo host fornito. Non puoi modificare il modo in cui il gateway di risorse gestito dal servizio risolve il DNS dopo la creazione, quindi scegli subito la modalità corretta. Se hai selezionato la modalità sbagliata, elimina la connessione e ricreala con la modalità corretta.
Se si specifica un indirizzo IP (anziché un nome DNS) per l'indirizzo host, la modalità di risoluzione DNS non ha effetto e il traffico viene indirizzato direttamente a quell'IP.
Se non puoi utilizzarlo
IN_VPCper la configurazione, puoi invece indirizzare l'indirizzo host all'indirizzo IP privato del destinatario o al nome DNS di un load balancer che è risolvibile pubblicamente ma inoltrato a un IP privato.
La connessione è bloccata in Creazione non riuscita
Sintomo
Dopo aver creato una connessione privata, la console mostra lo stato Connessione non riuscita (e describe-private-connection restituisce lo stato diCREATE_FAILED).
Causa
La creazione non riuscita deriva molto spesso da un problema di configurazione nella richiesta o nel VPC, piuttosto che da un errore di servizio. Quando una connessione ha lo stato di errore, l' AWS DevOps agente ne descrive il motivo nel failureMessage campo, quindi leggi quel campo prima di esaminare l'elenco di controllo.
Resolution (Risoluzione)
Verifica quanto segue, nell'ordine:
Leggi
failureMessagei dettagli della connessione. Questo campo descrive il motivo per cui una connessione ha uno stato fallito ed è presente quando lo stato èCREATE_FAILEDoDELETE_FAILED:
aws devops-agent describe-private-connection \ --name my-mcp-tool-connection
failureMessageappare anche nell'output dilist-private-connections. Se il campo indica la causa, agisci su di essa. Se il campo è assente, non è stato restituito alcun motivo, quindi continua con i controlli rimanenti.
Gli intervalli di porte utilizzano un formato valido. Specifica ogni intervallo di porte come porta singola (ad esempio
443) o come intervallo reale con porte di inizio e fine diverse (ad esempio,8080-8090). Un «intervallo» con inizio e fine uguali (ad esempio443-443) viene rifiutato. È possibile specificare fino a 11 intervalli di porte.Le tue sottoreti hanno indirizzi IP disponibili. Il gateway di risorse fornisce interfacce di rete elastiche (ENI) nelle sottoreti specificate. Se tali sottoreti sono esaurite, la creazione non riesce. Scegli le sottoreti con spazio di indirizzo libero.
Le tue sottoreti si trovano nelle zone di disponibilità supportate. Amazon VPC Lattice non supporta tutte le zone di disponibilità. Esegui quanto segue e confrontalo con le zone non supportate elencate in Crea una connessione privata:
aws ec2 describe-subnets \ --subnet-ids <your-subnet-ids> \ --query 'Subnets[*].[SubnetId,AvailabilityZoneId]'
Non hai raggiunto le quote di servizio Amazon VPC Lattice. Confronta il tuo account con le quote di Amazon VPC Lattice, in particolare i limiti del gateway di risorse.
Nessuna politica IAM o SCP sta bloccando il ruolo collegato al servizio. Il gateway di risorse gestite dal servizio viene creato tramite un ruolo collegato al servizio. Se la tua organizzazione dispone di politiche di controllo dei servizi (SCP) che limitano le azioni delle API Amazon VPC Lattice o Amazon EC2, assicurati che consentano al ruolo collegato al servizio di creare queste risorse.
Se la connessione continua a fallire dopo aver verificato tutti questi elementi, contatta l'assistenza. AWS
La connessione è attiva, ma la registrazione della funzionalità non riesce con un errore di raggiungibilità
Sintomo
La connessione privata raggiunge lo stato Attivo, ma quando si registra un provider di funzionalità (ad esempio, un server MCP) che la utilizza, la registrazione non riesce. Per un server MCP, il messaggio di errore descrive in che modo il controllo di raggiungibilità non è riuscito. Potresti visualizzare uno dei seguenti:
The MCP server at '<endpoint>' timed out while initializing the session.(una variante simile si riferisce all'elenco delle risorse)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.(può anche apparire come unAPI error: 504)
Causa
Una connessione privata che raggiunge Active conferma che il percorso di rete verso il tuo VPC è stato stabilito. Non conferma che il servizio di destinazione stia rispondendo all'indirizzo e alla porta previsti. Quando si registra un fornitore di funzionalità, l' AWS DevOps agente verifica che l'endpoint sia raggiungibile e risponda, ed è qui che emerge un target non configurato correttamente. Il messaggio indica quale livello non è riuscito:
Un messaggio scaduto indica che la connessione non ha mai raggiunto un servizio di ascolto. Molto spesso gli intervalli di porte della connessione non includono la porta dell'endpoint, l'indirizzo host o la risoluzione DNS sono errati o un gruppo di sicurezza sta bloccando il traffico.
Un messaggio di interruzione della connessione indica che la connessione è stata ripristinata o interrotta, in genere a causa di un errore di handshake TLS o della chiusura della connessione da parte del servizio.
Un messaggio di impossibilità di accedere agli strumenti indica che l'endpoint ha risposto ma ha rifiutato la richiesta. Di solito si tratta di un errore di autorizzazione o del provider piuttosto che di un problema di rete.
Un messaggio Impossibile completare la richiesta al provider è un errore generale nel completare la richiesta all'endpoint tramite la connessione privata. Rivedi i passaggi di risoluzione che seguono.
Una richiesta andata a buon fine da un'istanza o AWS CloudShell sessione Amazon EC2 nel tuo VPC conferma che il servizio è raggiungibile da quell'ambiente di test. Non conferma che il gateway di risorse utilizzi lo stesso URL dell'endpoint, porta, destinazione DNS o configurazione TLS.
Come confermare
Ripeti il test con l'URL esatto dell'endpoint che hai registrato, incluso il percorso e qualsiasi porta non predefinita.
Verifica che la porta dell'URL dell'endpoint sia inclusa negli intervalli di porte della connessione privata.
Verifica che l'indirizzo host della connessione privata si risolva nel load balancer o nel servizio che termina TLS su quella porta, anziché nell'IP di un'attività o di un'istanza su una porta dell'applicazione diversa.
Verifica che la destinazione utilizzi HTTPS con TLS 1.2 o versioni successive e presenti la catena di certificati prevista.
Verifica che il gruppo di sicurezza del gateway delle risorse consenta il traffico in uscita sulla porta di destinazione e che il gruppo di sicurezza di destinazione consenta il traffico in entrata corrispondente.
Resolution (Risoluzione)
Verifica che gli intervalli di porte della connessione includano la porta dell'endpoint. Una connessione privata inoltra il traffico solo sugli intervalli di porte configurati al momento della creazione. Se non hai specificato gli intervalli di porte, la connessione consente solo le porte
443. La connessione interrompe il traffico verso qualsiasi altra porta senza un errore descrittivo. Il traffico interrotto si presenta come un timeout, unUnable to access toolserrore o un errore.Could not complete request to provider.Ciò influisce in genere sugli endpoint su porte non standard (ad esempio).https://tools.example.com:8089/mcpUn esito positivocurlda un'istanza EC2 nello stesso VPC non lo esclude: tale test ignora completamente la connessione privata. Non è possibile modificare gli intervalli di porte dopo la creazione. Elimina la connessione privata, ricreala con intervalli di porte che includono tutte le porte nell'URL dell'endpoint e registra nuovamente il provider di funzionalità.Verifica che il gateway di risorse sia in grado di raggiungere il tuo obiettivo. Questa è la prima cosa da escludere quando il target viene eseguito in un AWS account diverso o in locale. In modalità gestita dai servizi, il gateway delle risorse viene creato nel VPC e nelle sottoreti specificate, nello stesso account della connessione privata, in modo che il VPC abbia bisogno di un percorso verso la destinazione. Una connessione che raggiunge Active significa solo che le interfacce di rete del gateway sono state create e sono integre; non significa che possano raggiungere il tuo servizio. Controlla la modalità di connessione e il VPC del gateway, quindi conferma il percorso:
aws devops-agent list-private-connections aws vpc-lattice list-resource-gateways
Se il VPC del gateway non ha alcun percorso verso la destinazione, aggiungine uno tramite peering VPC, AWS Transit Gateway o una connessione di rete privata virtuale (VPN), oppure sposta il gateway sull'account del target utilizzando la modalità autogestita. Vedi Creare una connessione privata.
Indirizza il DNS al load balancer, non all'IP dell'attività o dell'istanza. Una causa frequente è un record DNS o un indirizzo host che si risolve in un'attività contenitore o in un IP di istanza su una porta dell'applicazione (ad esempio
8100) anziché nel load balancer che termina il protocollo TLS sulla porta configurata (ad esempio,).443Verifica che l'indirizzo host si risolva nell'endpoint che effettivamente serve HTTPS sulla porta di destinazione.Verifica che il servizio serva HTTPS sulla porta configurata. La destinazione deve servire HTTPS con una versione TLS minima di 1.2 su una porta inclusa negli intervalli di porte della connessione.
Controlla le regole del gruppo di sicurezza in entrambe le direzioni. Verifica che il gruppo di sicurezza collegato al Resource Gateway ENIS consenta il traffico in uscita sulla porta di destinazione e che il gruppo di sicurezza del tuo servizio consenta il traffico in entrata su quella porta. Il traffico arriva dagli IP del data plane di Amazon VPC Lattice all'interno dell'intervallo CIDR del tuo VPC. Puoi utilizzare il riferimento ai gruppi di sicurezza (consenti il gruppo di sicurezza ENI come fonte) o consentire l'ingresso dal CIDR VPC. Vedere Configurazione delle regole del firewall per le connessioni private.
Verifica l'intera catena di certificati per una CA privata. Se un'autorità di certificazione privata ha emesso il certificato TLS del tuo servizio, fornisci l'intera catena di PEM-encoded certificati quando crei la connessione. Posiziona prima il certificato foglia, poi i certificati intermedi e poi il certificato radice. Se la catena è incompleta, l'handshake TLS fallisce anche se il percorso di rete è attivo. Per i messaggi di errore che ciò produce, vedi Il certificato TLS del provider non è attendibile.
Conferma che il target è in esecuzione. Assicurati che il servizio sia attivo e accetti le connessioni sulla porta prevista prima di completare la registrazione.
Il certificato TLS del provider non è attendibile
Sintomo
La registrazione o l'utilizzo di un provider di funzionalità non riesce e viene generato un errore di certificato. La formulazione dipende dal tipo di funzionalità, ma tutte descrivono la stessa classe di problemi:
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 L'agente non è riuscito a convalidare la catena di certificati presentata dal servizio. Le cause più comuni sono un certificato emesso da un'autorità di certificazione (CA) privata o interna, una catena a cui mancano i certificati intermedi, un certificato scaduto nella catena o un certificato che non copre il nome host nell'URL dell'endpoint.
Nota
Questi messaggi richiedono un certificato da una CA pubblicamente attendibile, ma è supportata una CA privata. Fornisci la catena sulla connessione privata, come descritto nelle fasi di risoluzione.
Come confermare
Da un'istanza o AWS CloudShell sessione Amazon EC2 che può raggiungere il tuo obiettivo, ispeziona la catena che il servizio presenta sulla porta che hai configurato e verifica quale CA ne ha firmato la parte superiore:
openssl s_client -connect <your-host-address>:<port> -showcerts
Se una CA interna ha firmato il certificato, fornisci la catena sulla connessione. Se una CA pubblica lo ha firmato, la catena inviata dal servizio è probabilmente incompleta.
Resolution (Risoluzione)
Per ottenere un certificato da una CA privata, fornisci l'intera catena sulla connessione privata. Imposta la chiave pubblica del certificato nella console, o il
certificatecampo increate-private-connection, sulla PEM-encoded catena completa: prima il certificato foglia, poi tutti i certificati CA intermedi, quindi la radice. Vedi Creare una connessione privata.Per un certificato rilasciato da una CA pubblica, invia la catena completa. Configura il tuo servizio per inviare il certificato leaf più tutti i certificati intermedi, non solo il leaf.
Sostituisci qualsiasi certificato scaduto presente nella catena.
Verifica che il certificato includa il nome host nell'URL dell'endpoint.
Lo scambio di token OAuth non può essere raggiunto
Sintomo
Hai registrato un server OAuth-based MCP (Client Credentials o 3LO) o un agente remoto che utilizza le credenziali client OAuth tramite una connessione privata, ma lo scambio di token non riesce anche se il server MCP o l'endpoint dell'agente remoto è raggiungibile.
Causa
Per i fornitori OAuth-based di funzionalità, AWS DevOps l'agente chiama due endpoint: l'URL di destinazione (il server MCP o l'endpoint dell'agente remoto) e l'URL di scambio (l'endpoint di scambio di token OAuth). Quando si seleziona una singola connessione privata, questa si applica a entrambi gli endpoint. Se i due endpoint sono raggiungibili solo attraverso percorsi di rete diversi, una singola connessione privata non può essere indirizzata a entrambi.
Resolution (Risoluzione)
Se entrambi gli endpoint sono raggiungibili tramite lo stesso percorso, assicurati che l'indirizzo host della connessione privata possa essere indirizzato sia al server MCP o all'endpoint dell'agente remoto sia all'endpoint di scambio di token.
Se gli endpoint richiedono percorsi di rete diversi, utilizza i campi per endpoint anziché uno solo.
privateConnectionNameImpostatotargetUrlPrivateConnectionNameper il server MCP o l'endpoint dell'agente remoto eexchangeUrlPrivateConnectionNameper l'endpoint di scambio di token. Se ne imposti solo uno, l'altro endpoint viene raggiunto tramite Internet pubblico e non ritorna all'altra connessione privata. Non è possibile combinare i nomi dei singoli endpointprivateConnectionNamenella stessa richiesta. Vedi Routing dell'endpoint e dello scambio di token OAuth tramite diverse connessioni private.
Una connessione privata non può essere eliminata mentre è in uso
Sintomo
L'eliminazione di una connessione privata non riesce con Private connection '<name>' is in use by one or more services. Deregister the services first.
Causa
Una connessione privata non può essere eliminata finché un provider di funzionalità registrato fa ancora riferimento ad essa. AWS DevOps L'agente rifiuta l'eliminazione prima di rimuovere qualsiasi risorsa, quindi la connessione rimane nello stato attuale.
Resolution (Risoluzione)
Identifica i fornitori di funzionalità che utilizzano la connessione e annullane la registrazione o li aggiorna in modo che non la utilizzino più.
Elimina la connessione privata.
Rimuovere un provider di funzionalità da un Agent Space non equivale ad annullarne la registrazione. Esiste una registrazione a livello di account, quindi rimuovila da tutti gli Agent Spaces e quindi elimina la registrazione prima di eliminare la connessione.
Il Resource Gateway o ENI rimangono invariati dopo l'eliminazione di una connessione
Sintomo
Ti aspettavi che il gateway di risorse gestite e i relativi ENI venissero rimossi, ma sono comunque visualizzati nel tuo VPC. Ciò può comportare costi ENI e bloccare le operazioni che dipendono da un VPC pulito, ad esempio. terraform destroy
Causa
Il gateway di risorse gestite e gli ENI vengono rimossi solo quando si elimina la connessione privata tramite Agent. AWS DevOps I motivi più comuni per cui rimangono sono il fatto che non sono mai DeletePrivateConnection stati effettivamente richiamati o che il AWSAIDevOpsManaged tag è stato rimosso dalle risorse gestite, quindi l'eliminazione non può procedere.
Importante
AWS DevOps L'agente contrassegna le risorse che gestisce (il gateway delle risorse e i relativi ENI) con. AWSAIDevOpsManaged Il ruolo collegato al servizio può agire solo sulle risorse che contengono questo tag, quindi non rimuovere o modificare il AWSAIDevOpsManaged tag. Se il tag è mancante, non è DeletePrivateConnection possibile ripulire le risorse e l'eliminazione non riesce.
Resolution (Risoluzione)
Elimina la connessione tramite AWS DevOps Agent. Usa la console (Capability provider > Connessioni private > Azioni > Rimuovi) o la CLI:
aws devops-agent delete-private-connection \ --name my-mcp-tool-connection
Lo stato cambia DELETE_IN_PROGRESS quando l' AWS DevOps agente rimuove il gateway di risorse gestite e gli ENI dal tuo VPC.
Se l'eliminazione non riesce, conferma che il
AWSAIDevOpsManagedtag sia ancora presente. Se il tag è stato rimosso dal gateway delle risorse o dai relativi ENI, applicalo nuovamente a tali risorse, quindi esegui nuovamente l'eliminazione.Non provare a eliminare direttamente il gateway di risorse gestite. Il gateway delle risorse è di sola lettura nel tuo account ed è completamente gestito da AWS DevOps Agent e non puoi eliminarlo tu stesso tramite Amazon VPC Lattice. L'eliminazione della connessione privata è ciò che ne attiva la rimozione.
Se hai eliminato la connessione privata, il tag è presente e il gateway delle risorse o gli ENI rimangono attivi dopo il completamento dell'eliminazione, contatta l' AWS assistenza per riconciliare le risorse.
Richiesta di aiuto
Se consulti la sezione pertinente al problema e il problema persiste, contatta AWS l'assistenza. Includi il nome della tua connessione privata, il suo stato attuale, la AWS regione e l'indirizzo e la porta dell'host di destinazione in modo che l'assistenza possa esaminare il percorso di rete.
Argomenti correlati
