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). La risposta spesso non include un motivo dettagliato dell'errore, quindi non viene visualizzato un messaggio di errore su cui intervenire.
Causa
L'errore di creazione è spesso dovuto a un problema di configurazione nella richiesta o nel VPC, piuttosto che a un errore di servizio. Poiché non sempre viene indicato il motivo dettagliato dell'errore, segui la seguente lista di controllo anche quando non viene visualizzato alcun messaggio di errore.
Resolution (Risoluzione)
Verifica quanto segue, nell'ordine:
Gli intervalli di porte utilizzano un formato valido. Specifica ogni intervallo di porte come una porta singola (ad esempio
443) o un intervallo autentico 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 l'indirizzo host, la porta o la risoluzione DNS sono errati o un gruppo di sicurezza sta bloccando il traffico.
Un messaggio di connessione interrotta 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.
Resolution (Risoluzione)
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.
Conferma che il target è in esecuzione. Assicurati che il servizio sia attivo e accetti le connessioni sulla porta prevista prima di completare la registrazione.
Impossibile raggiungere lo scambio di token OAuth
Sintomo
Hai registrato un provider di funzionalità del server OAuth-based MCP (Client Credentials o 3LO) tramite una connessione privata, ma lo scambio di token non riesce anche se l'endpoint del server MCP è raggiungibile.
Causa
Per i fornitori OAuth-based di funzionalità, AWS DevOps l'agente chiama due endpoint: l'URL di destinazione (l'endpoint del server MCP) 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 all'endpoint del server MCP che all'endpoint di scambio di token.
Se gli endpoint richiedono percorsi di rete diversi, utilizza i campi per endpoint anziché uno solo.
privateConnectionNameImpostatotargetUrlPrivateConnectionNameper l'endpoint del server MCP 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.
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 che non sono mai DeletePrivateConnection stati effettivamente richiamati o perché 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 in 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
