Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Problembehandlung bei privaten Verbindungen
Auf dieser Seite werden häufig auftretende Probleme beschrieben, die beim Erstellen oder Verwenden eines Verbindung zu privat gehosteten Tools herstellen for AWS DevOps Agents auftreten können, und wie diese behoben werden können. In jedem Abschnitt werden ein Symptom, die wahrscheinlichsten Ursachen und die Schritte zu seiner Behebung beschrieben.
Einen Überblick über die Funktionsweise privater Verbindungen finden Sie unterVerbindung zu privat gehosteten Tools herstellen.
Eine DNS-Hostadresse wird nicht aufgelöst, oder der Datenverkehr erreicht den falschen Ort
Symptom
Sie haben eine private Verbindung mit einem DNS-Namen für die Hostadresse erstellt, aber die Verbindung kann Ihren Dienst nicht erreichen. Dies ist am häufigsten der Fall, wenn es sich bei Ihrem Zieldienst um eine selbst gehostete GitLab Instance, einen internen Application Load Balancer (ALB) oder einen MCP-Server handelt, dessen Hostname nur in Ihrer VPC existiert.
Ein Fehler bei der DNS-Auflösung führt nicht zu einer Meldung, in der DNS erwähnt wird. Stattdessen wird es als generischer Erreichbarkeits- oder Anbieterfehler angezeigt, wenn Sie den Capability Provider registrieren oder verwenden. Beispielsweise wird möglicherweise ein Authentifizierungsfehler angezeigt Could not complete request to provider.Unable to connect to the MCP server at <endpoint>. The connection was interrupted., oder sogar ein Authentifizierungsfehler wie z. B. Authentication with provider failed. Da die Meldung nicht auf DNS verweist, überprüfen Sie die Ursache mithilfe der folgenden Überprüfung.
Ursache
Standardmäßig löst eine private Verbindung die Hostadresse mithilfe von öffentlichem DNS (dnsResolution: PUBLIC) auf. Wenn Ihr Hostname nur einen Eintrag in einer privat gehosteten Zone, eine Amazon Route 53 Resolver-Regel oder einen lokalen DNS-Server hat, schlägt die öffentliche Auflösung fehl und die Verbindung erreicht Ihren Service nie.
Wie kann man bestätigen, dass DNS die Ursache ist
Prüfen Sie, ob Ihre Hostadresse nur in Ihrer VPC aufgelöst wird. Führen Sie von einer Amazon EC2-Instance oder AWS CloudShell -Sitzung in derselben VPC aus.
nslookup <your-host-address>Wenn es dort aufgelöst wird, aber nicht aus öffentlichem DNS, und Ihre private Verbindung verwendetdnsResolution: PUBLIC, ist die DNS-Auflösung die Ursache.Testen Sie mit der IP-Adresse statt mit dem Namen. Erstellen Sie vorübergehend eine private Verbindung, die die private IP-Adresse des Ziels (oder eine Load Balancer-IP) für die Hostadresse anstelle des DNS-Namens verwendet. Wenn die Verbindung dann Ihren Dienst erreicht, war der frühere Fehler die DNS-Auflösung, nicht der Netzwerkpfad oder der Dienst selbst.
Resolution (Auflösung)
Wenn Ihr Hostname nur innerhalb Ihrer VPC aufgelöst wird, setzen Sie den DNS-Auflösungsmodus auf In VPC (
IN_VPC), wenn Sie die Verbindung herstellen. In diesem Modus wird die Hostadresse in Ihrem VPC-Kontext aufgelöst, sodass reine private Hostnamen korrekt aufgelöst werden. Siehe Eine private Verbindung erstellen.Der DNS-Auflösungsmodus wird bei der Erstellung ausgewählt und gilt für die von Ihnen angegebene Hostadresse. Sie können nicht ändern, wie das vom Service verwaltete Resource Gateway DNS nach der Erstellung auflöst. Wählen Sie daher im Voraus den richtigen Modus aus. Wenn Sie den falschen Modus ausgewählt haben, löschen Sie die Verbindung und stellen Sie sie im richtigen Modus neu her.
Wenn Sie eine IP-Adresse (statt eines DNS-Namens) für die Hostadresse angeben, hat der DNS-Auflösungsmodus keine Auswirkung, und der Datenverkehr wird direkt an diese IP weitergeleitet.
Wenn Sie diese
IN_VPCfür Ihr Setup nicht verwenden können, können Sie die Hostadresse stattdessen auf die private IP-Adresse des Ziels oder auf den DNS-Namen eines Load Balancers verweisen, der öffentlich auflösbar ist, aber an eine private IP weiterleitet.
Die Verbindung steckt in Create failed
Symptom
Nachdem Sie eine private Verbindung erstellt haben, zeigt die Konsole den Status Verbindung fehlgeschlagen an (und describe-private-connection gibt den Status zurückCREATE_FAILED). Die Antwort enthält oft keinen detaillierten Grund für den Fehler, sodass Sie keine Fehlermeldung erhalten, auf die Sie reagieren könnten.
Ursache
Ein Fehler bei der Erstellung ist meistens auf ein Konfigurationsproblem in der Anfrage oder in Ihrer VPC zurückzuführen und nicht auf einen Servicefehler. Da nicht immer eine detaillierte Fehlerursache angezeigt wird, sollten Sie die folgende Checkliste auch dann durcharbeiten, wenn keine Fehlermeldung angezeigt wird.
Resolution (Auflösung)
Überprüfen Sie Folgendes in der angegebenen Reihenfolge:
Portbereiche verwenden ein gültiges Format. Geben Sie jeden Portbereich entweder als einzelnen Port (z. B.
443) oder als echten Bereich mit unterschiedlichen Start- und Endports (z. B.8080-8090) an. Ein „Bereich“, dessen Anfang und Ende identisch sind (z. B.443-443), wird abgelehnt. Sie können bis zu 11 Portbereiche angeben.Ihre Subnetze haben verfügbare IP-Adressen. Das Resource Gateway stellt Elastic Network Interfaces (ENIs) in den von Ihnen angegebenen Subnetzen bereit. Wenn diese Subnetze erschöpft sind, schlägt die Erstellung fehl. Wählen Sie Subnetze mit freiem Adressraum.
Ihre Subnetze befinden sich in unterstützten Availability Zones. Amazon VPC Lattice unterstützt nicht jede Availability Zone. Führen Sie Folgendes aus und vergleichen Sie es mit den nicht unterstützten Zonen, die unter Private Verbindung erstellen aufgeführt sind:
aws ec2 describe-subnets \ --subnet-ids <your-subnet-ids> \ --query 'Subnets[*].[SubnetId,AvailabilityZoneId]'
Sie haben die Amazon VPC Lattice-Servicekontingente nicht erreicht. Prüfen Sie Ihr Konto anhand der Amazon VPC Lattice-Kontingente, insbesondere der Resource Gateway-Limits.
Keine IAM-Richtlinie oder SCP blockiert die serviceverknüpfte Rolle. Das dienstverwaltete Ressourcen-Gateway wird über eine dienstverknüpfte Rolle erstellt. Wenn Ihre Organisation über Service Control Policies (SCPs) verfügt, die Amazon VPC Lattice- oder Amazon EC2-API-Aktionen einschränken, stellen Sie sicher, dass die serviceverknüpfte Rolle diese Ressourcen erstellen kann.
Wenn die Verbindung nach der Überprüfung all dieser Elemente weiterhin fehlschlägt, wenden Sie sich an den Support. AWS
Die Verbindung ist aktiv, aber die Funktionsregistrierung schlägt fehl und es wird ein Erreichbarkeitsfehler gemeldet
Symptom
Die private Verbindung erreicht den Status Aktiv, aber wenn Sie einen Capability Provider (z. B. einen MCP-Server) registrieren, der sie verwendet, schlägt die Registrierung fehl. Bei einem MCP-Server beschreibt die Fehlermeldung, dass die Erreichbarkeitsprüfung fehlgeschlagen ist. Möglicherweise wird eine der folgenden Optionen angezeigt:
The MCP server at '<endpoint>' timed out while initializing the session.(Eine ähnliche Variante bezieht sich auf das Auflisten von Ressourcen)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.(kann auch als erscheinenAPI error: 504)
Ursache
Eine private Verbindung, die Active erreicht, bestätigt, dass der Netzwerkpfad zu Ihrer VPC eingerichtet ist. Es bestätigt nicht, dass Ihr Zieldienst an der erwarteten Adresse und dem erwarteten Port antwortet. Wenn Sie einen Capability Provider registrieren, überprüft der AWS DevOps Agent, ob der Endpunkt erreichbar ist und reagiert. An dieser Stelle taucht ein falsch konfiguriertes Ziel auf. In der Meldung erfahren Sie, welcher Layer ausgefallen ist:
Eine Timeout-Meldung bedeutet, dass die Verbindung nie einen Abhördienst erreicht hat. In den meisten Fällen ist die Hostadresse, der Port oder die DNS-Auflösung falsch, oder eine Sicherheitsgruppe blockiert den Datenverkehr.
Die Meldung „Verbindung wurde unterbrochen“ bedeutet, dass die Verbindung zurückgesetzt oder unterbrochen wurde, in der Regel aufgrund eines TLS-Handshake-Fehlers oder beim Schließen der Verbindung durch den Dienst.
Eine Meldung, dass auf die Tools nicht zugegriffen werden kann, bedeutet, dass der Endpunkt geantwortet, die Anfrage jedoch abgelehnt hat. Dies ist in der Regel eher ein Autorisierungs- oder Anbieterfehler als ein Netzwerkproblem.
Die Meldung „Anfrage an den Anbieter konnte nicht abgeschlossen werden“ ist ein allgemeiner Fehler beim Abschließen der Anfrage an Ihren Endpunkt über die private Verbindung. Lesen Sie die folgenden Schritte zur Problembehebung.
Resolution (Auflösung)
Richten Sie DNS auf den Load Balancer, nicht auf eine Task- oder Instanz-IP. Eine häufige Ursache ist ein DNS-Datensatz oder eine Hostadresse, die in eine Container-Aufgabe oder Instance-IP an einem Anwendungsport aufgelöst wird (z. B.
8100), anstatt in den Load Balancer, der TLS auf dem von Ihnen konfigurierten Port beendet (z. B.).443Vergewissern Sie sich, dass die Hostadresse in den Endpunkt aufgelöst wird, der tatsächlich HTTPS auf dem Zielport bereitstellt.Vergewissern Sie sich, dass der Dienst HTTPS auf dem konfigurierten Port bereitstellt. Das Ziel muss HTTPS mit einer TLS-Version von mindestens 1.2 auf einem Port bereitstellen, der in den Portbereichen der Verbindung enthalten ist.
Überprüfen Sie die Sicherheitsgruppenregeln in beide Richtungen. Stellen Sie sicher, dass die an die Ressourcen-Gateway-ENIs angehängte Sicherheitsgruppe ausgehenden Verkehr auf dem Zielport zulässt und dass die Sicherheitsgruppe Ihres Dienstes eingehenden Verkehr auf diesem Port zulässt. Der Datenverkehr kommt von den IP-Adressen der Amazon VPC Lattice-Datenebene innerhalb Ihres VPC-CIDR-Bereichs an. Sie können Sicherheitsgruppen-Referenzierung verwenden (die ENI-Sicherheitsgruppe als Quelle zulassen) oder eingehenden Datenverkehr vom VPC-CIDR zulassen. Siehe Firewallregeln für private Verbindungen konfigurieren.
Überprüfen Sie die vollständige Zertifikatskette für eine private CA. Wenn eine private Zertifizierungsstelle das TLS-Zertifikat Ihres Dienstes ausgestellt hat, geben Sie die vollständige PEM-encoded Zertifikatskette an, wenn Sie die Verbindung herstellen. Platzieren Sie zuerst das Leaf-Zertifikat, dann die Zwischenprodukte und dann das Stammzertifikat. Wenn die Kette unvollständig ist, schlägt der TLS-Handshake fehl, obwohl der Netzwerkpfad aktiv ist.
Vergewissern Sie sich, dass das Ziel läuft. Vergewissern Sie sich, dass Ihr Dienst aktiv ist und Verbindungen auf dem erwarteten Port akzeptiert, bevor Sie die Registrierung abschließen.
Der OAuth-Token-Austausch kann nicht erreicht werden
Symptom
Sie haben einen OAuth-based MCP-Serverfunktionsanbieter (Client Credentials oder 3LO) über eine private Verbindung registriert, aber der Token-Austausch schlägt fehl, obwohl der MCP-Serverendpunkt erreichbar ist.
Ursache
Bei OAuth-based Capability Providern ruft der AWS DevOps Agent zwei Endpunkte auf: die Ziel-URL (der MCP-Serverendpunkt) und die Exchange-URL (der OAuth-Token-Exchange-Endpunkt). Wenn Sie eine einzelne private Verbindung auswählen, gilt sie für beide Endpunkte. Wenn die beiden Endpunkte nur über unterschiedliche Netzwerkpfade erreichbar sind, kann eine einzelne private Verbindung nicht zu beiden weitergeleitet werden.
Resolution (Auflösung)
Wenn beide Endpunkte über denselben Pfad erreichbar sind, stellen Sie sicher, dass die Hostadresse der privaten Verbindung sowohl zum MCP-Serverendpunkt als auch zum Token-Exchange-Endpunkt weitergeleitet werden kann.
Wenn die Endpunkte unterschiedliche Netzwerkpfade benötigen, verwenden Sie die Felder pro Endpunkt anstelle eines einzelnen.
privateConnectionNameWirdtargetUrlPrivateConnectionNamefür den MCP-Serverendpunkt undexchangeUrlPrivateConnectionNamefür den Token-Exchange-Endpunkt festgelegt. Wenn Sie nur einen festlegen, wird der andere Endpunkt über das öffentliche Internet erreicht und es wird nicht auf die andere private Verbindung zurückgegriffen. Sie können die Namen pro Endpunkt nichtprivateConnectionNamein derselben Anfrage kombinieren. Weitere Informationen finden Sie unter Routing des Endpunkts und des OAuth-Tokenaustauschs über verschiedene private Verbindungen.
Resource Gateway oder ENIs bleiben erhalten, nachdem Sie eine Verbindung gelöscht haben
Symptom
Sie haben erwartet, dass das verwaltete Resource Gateway und seine ENIs entfernt werden, aber sie werden immer noch in Ihrer VPC angezeigt. Dadurch können ENI-Gebühren anfallen und Operationen blockiert werden, die von einer sauberen VPC abhängen, wie z. terraform destroy
Ursache
Das verwaltete Resource Gateway und die ENIs werden nur entfernt, wenn Sie die private Verbindung über den Agenten löschen. AWS DevOps Die häufigsten Gründe dafür sind, dass sie nie aufgerufen DeletePrivateConnection wurden oder dass das AWSAIDevOpsManaged Tag aus den verwalteten Ressourcen entfernt wurde, sodass das Löschen nicht fortgesetzt werden kann.
Wichtig
AWS DevOps Der Agent kennzeichnet die von ihm verwalteten Ressourcen (das Ressourcen-Gateway und seine ENIs). AWSAIDevOpsManaged Die serviceverknüpfte Rolle kann nur auf Ressourcen angewendet werden, die dieses Tag tragen. Entfernen oder ändern Sie das AWSAIDevOpsManaged Tag daher nicht. Wenn das Tag fehlt, DeletePrivateConnection können die Ressourcen nicht bereinigt werden und das Löschen schlägt fehl.
Resolution (Auflösung)
Löschen Sie die Verbindung über den AWS DevOps Agenten. Verwenden Sie die Konsole (Capability Providers > Private Verbindungen > Aktionen > Entfernen) oder die CLI:
aws devops-agent delete-private-connection \ --name my-mcp-tool-connection
Der Status ändert sich in, DELETE_IN_PROGRESS während der AWS DevOps Agent das verwaltete Ressourcen-Gateway und die ENIs aus Ihrer VPC entfernt.
Wenn das Löschen fehlschlägt, vergewissern Sie sich, dass das
AWSAIDevOpsManagedTag noch vorhanden ist. Wenn das Tag vom Ressourcen-Gateway oder seinen ENIs entfernt wurde, wenden Sie es erneut auf diese Ressourcen an und führen Sie den Löschvorgang erneut durch.Versuchen Sie nicht, das verwaltete Resource Gateway direkt zu löschen. Das Resource Gateway ist in Ihrem Konto schreibgeschützt und wird vollständig vom AWS DevOps Agenten verwaltet. Sie können es nicht selbst über Amazon VPC Lattice löschen. Das Löschen der privaten Verbindung löst ihre Entfernung aus.
Wenn Sie die private Verbindung gelöscht haben, das Tag vorhanden ist und das Ressourcen-Gateway oder die ENIs auch nach Abschluss des Löschvorgangs noch vorhanden sind. Wenden Sie sich an den AWS Support, um die Ressourcen abzugleichen.
Hilfe anfordern
Wenn Sie den entsprechenden Abschnitt für Ihr Problem durchgearbeitet haben und das Problem weiterhin besteht, wenden Sie sich an den AWS Support. Geben Sie den Namen Ihrer privaten Verbindung, den aktuellen Status, die AWS Region sowie die Zielhostadresse und den Port an, damit der Support den Netzwerkpfad untersuchen kann.
Verwandte Themen
