Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memecahkan masalah koneksi pribadi
Halaman ini menjelaskan masalah umum yang mungkin Anda temui saat membuat atau menggunakan [Menghubungkan ke alat yang dihosting secara pribadi](configuring-integrations-and-knowledge-connecting-to-privately-hosted-tools.md) untuk AWS DevOps Agen, dan cara mengatasinya. Setiap bagian menjelaskan gejala, penyebab yang paling mungkin, dan langkah-langkah untuk memperbaikinya.
Untuk ikhtisar tentang cara kerja koneksi pribadi, lihat[Menghubungkan ke alat yang dihosting secara pribadi](configuring-integrations-and-knowledge-connecting-to-privately-hosted-tools.md).
## Alamat host DNS tidak terselesaikan, atau lalu lintas mencapai tempat yang salah
**Gejala **
Anda membuat koneksi pribadi menggunakan nama DNS untuk alamat host, tetapi koneksi tidak dapat mencapai layanan Anda. Hal ini paling umum terjadi ketika layanan target Anda adalah GitLab instance yang di-host sendiri, Internal Application Load Balancer (ALB), atau server MCP yang nama hostnya hanya ada di dalam VPC Anda.
Kegagalan resolusi DNS tidak menghasilkan pesan yang menyebutkan DNS. Sebaliknya, ini muncul sebagai jangkauan umum atau kesalahan penyedia saat Anda mendaftar atau menggunakan penyedia kemampuan. Misalnya, Anda mungkin melihat`Could not complete request to provider.`,`Unable to connect to the MCP server at . The connection was interrupted.`, atau bahkan kesalahan otentikasi seperti `Authentication with provider failed.` Karena pesan tidak menunjuk ke DNS, gunakan pemeriksaan berikut untuk mengonfirmasi penyebabnya.
**Menyebabkan **
Secara default, koneksi pribadi menyelesaikan alamat host menggunakan DNS ** publik ** (`dnsResolution: PUBLIC`). Jika nama host Anda hanya memiliki catatan di zona yang [ dihosting pribadi](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html), aturan Amazon Route 53 Resolver, atau server DNS lokal, resolusi publik gagal dan koneksi tidak pernah mencapai layanan Anda.
**Cara mengonfirmasi DNS adalah penyebabnya **
+ Periksa apakah alamat host Anda diselesaikan hanya di dalam VPC Anda. Dari instans atau AWS CloudShell sesi Amazon EC2 di VPC yang sama, jalankan. `nslookup ` Jika diselesaikan di sana tetapi tidak dari DNS publik, dan koneksi pribadi Anda menggunakan`dnsResolution: PUBLIC`, resolusi DNS adalah penyebabnya.
+ Uji dengan alamat IP alih-alih nama. Buat sementara koneksi pribadi yang menggunakan alamat IP pribadi target (atau IP penyeimbang beban) untuk alamat host, bukan nama DNS. Jika koneksi kemudian mencapai layanan Anda, kegagalan sebelumnya adalah resolusi DNS, bukan jalur jaringan atau layanan itu sendiri.
**Resolusi**
+ Jika nama host Anda diselesaikan hanya di dalam VPC Anda, setel mode resolusi DNS ke ** Dalam VPC ** (`IN_VPC`) saat Anda membuat koneksi. Dalam mode ini, alamat host diselesaikan dari dalam konteks VPC Anda, sehingga nama host khusus pribadi diselesaikan dengan benar. Lihat [ Membuat koneksi pribadi](configuring-integrations-and-knowledge-connecting-to-privately-hosted-tools.md).
+ Mode resolusi DNS dipilih pada waktu pembuatan dan berlaku untuk alamat host yang Anda berikan. Anda tidak dapat mengubah cara gateway sumber daya yang dikelola layanan menyelesaikan DNS setelah pembuatan, jadi pilih mode yang benar di muka. Jika Anda memilih mode yang salah, hapus koneksi dan buat ulang dengan mode yang benar.
+ Jika Anda menentukan alamat ** IP ** (bukan nama DNS) untuk alamat host, mode resolusi DNS tidak berpengaruh, dan lalu lintas langsung menuju IP tersebut.
+ Jika Anda tidak dapat menggunakan `IN_VPC` untuk penyiapan Anda, Anda dapat mengarahkan alamat host ke alamat IP pribadi target, atau pada nama DNS penyeimbang beban yang dapat diselesaikan secara publik tetapi diteruskan ke IP pribadi.
## Koneksi macet di Create failed
**Gejala **
Setelah Anda membuat koneksi pribadi, konsol menampilkan status sebagai Kon ** eksi Gag ** al (dan `describe-private-connection` mengembalikan status`CREATE_FAILED`). Tanggapan sering tidak menyertakan alasan terperinci untuk kegagalan, jadi Anda dibiarkan tanpa pesan kesalahan untuk ditindaklanjuti.
**Menyebabkan **
Pembuatan gagal paling sering dihasilkan dari masalah konfigurasi dalam permintaan atau di VPC Anda, bukan kesalahan layanan. Karena alasan kegagalan terperinci tidak selalu muncul, kerjakan daftar periksa berikut bahkan ketika tidak ada pesan kesalahan yang ditampilkan.
**Resolusi**
Verifikasi yang berikut ini, secara berurutan:
1. **Rentang port menggunakan format yang valid. ** Tentukan setiap rentang port sebagai port tunggal (misalnya,`443`) atau rentang asli dengan port awal dan akhir yang berbeda (misalnya,`8080-8090`). Sebuah “rentang” yang awal dan akhirnya sama (misalnya,`443-443`) ditolak. Anda dapat menentukan hingga 11 rentang port.
1. **Subnet Anda memiliki alamat IP yang tersedia. ** Gateway sumber daya menyediakan antarmuka jaringan elastis (ENI) di subnet yang Anda tentukan. Jika subnet tersebut habis, pembuatan gagal. Pilih subnet dengan ruang alamat kosong.
1. **Subnet Anda berada di Zona Ketersediaan yang didukung. ** Amazon VPC Lattice tidak mendukung setiap Zona Ketersediaan. Jalankan yang berikut ini dan bandingkan dengan zona yang tidak didukung yang tercantum di [ Buat koneksi pribadi: ](configuring-integrations-and-knowledge-connecting-to-privately-hosted-tools.md)
``` aws ec2 describe-subnets \ --subnet-ids \ --query 'Subnets[*].[SubnetId,AvailabilityZoneId]' ```
1. **Anda belum mencapai kuota layanan Amazon VPC Lattice. ** Periksa akun Anda terhadap kuota [ Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/quotas.html), terutama batas gateway sumber daya.
1. **Tidak ada kebijakan IAM atau SCP yang memblokir peran terkait layanan. ** Gateway sumber daya yang dikelola layanan dibuat melalui peran terkait layanan[. ](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) Jika organisasi Anda memiliki kebijakan kontrol [ layanan (SCP) ](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) yang membatasi tindakan Amazon VPC Lattice atau Amazon EC2 API, pastikan mereka mengizinkan peran terkait layanan untuk membuat sumber daya ini.
Jika koneksi terus gagal setelah Anda memverifikasi semua item ini, hubungi AWS Dukungan.
## Koneksi Aktif, tetapi pendaftaran kemampuan gagal dengan kesalahan pencapaian
**Gejala **
Koneksi pribadi mencapai ** status ** Aktif, tetapi ketika Anda mendaftarkan penyedia kemampuan (misalnya, server MCP) yang menggunakannya, pendaftaran gagal. Untuk server MCP, pesan kesalahan menjelaskan bagaimana pemeriksaan jangkauan gagal. Anda mungkin melihat salah satu dari berikut ini:
+ `The MCP server at '' timed out while initializing the session.`(varian serupa mengacu pada sumber daya daftar)
+ `Unable to connect to the MCP server at . The connection was interrupted. Verify the server is running and accessible, then try again.`
+ `Unable to access tools from the MCP server at '' ...`
+ `Could not complete request to provider.`(mungkin juga muncul sebagai`API error: 504`)
**Menyebabkan **
Koneksi pribadi yang mencapai ** Aktif ** mengonfirmasi bahwa jalur jaringan ke VPC Anda telah dibuat. Itu tidak mengonfirmasi bahwa layanan target Anda menjawab pada alamat dan port yang diharapkan. Saat Anda mendaftarkan penyedia kemampuan, AWS DevOps Agen memvalidasi bahwa titik akhir dapat dijangkau dan merespons, dan di sinilah target yang salah konfigurasi muncul. Pesan memberi tahu Anda lapisan mana yang gagal:
+ Pesan ** batas waktu ** berarti koneksi tidak pernah mencapai layanan mendengarkan. Paling sering alamat host, port, atau resolusi DNS salah, atau grup keamanan memblokir lalu lintas.
+ Pesan ** koneksi terputus ** berarti koneksi diatur ulang atau terputus, biasanya oleh kegagalan jabat tangan TLS atau layanan menutup koneksi.
+ **Pesan ** alat yang tidak dapat mengakses berarti titik akhir merespons tetapi menolak permintaan. Ini biasanya merupakan kesalahan otorisasi atau sisi penyedia daripada masalah jaringan.
+ Pesan ** Tidak dapat menyelesaikan permintaan ke penyedia ** adalah kegagalan umum untuk menyelesaikan permintaan ke titik akhir Anda melalui koneksi pribadi. Tinjau langkah-langkah resolusi berikut.
**Resolusi**
+ **Arahkan DNS pada penyeimbang beban, bukan IP tugas atau instance. ** Penyebab yang sering terjadi adalah catatan DNS atau alamat host yang diselesaikan ke tugas kontainer atau IP instans pada port aplikasi (misalnya,`8100`) alih-alih penyeimbang beban yang mengakhiri TLS pada port yang Anda konfigurasikan (misalnya,). `443` Konfirmasikan alamat host diselesaikan ke titik akhir yang benar-benar melayani HTTPS pada port target.
+ **Konfirmasikan layanan melayani HTTPS pada port yang dikonfigurasi. ** Target harus melayani HTTPS dengan versi TLS minimum 1.2 pada port yang termasuk dalam rentang port koneksi.
+ **Periksa aturan grup keamanan di kedua arah. ** Verifikasi bahwa grup keamanan yang dilampirkan ke gateway sumber daya ENIS mengizinkan lalu lintas keluar pada port target, dan bahwa grup keamanan layanan Anda mengizinkan lalu lintas masuk pada port tersebut. Lalu lintas datang dari IP bidang data Amazon VPC Lattice dalam jangkauan VPC CIDR Anda. Anda dapat menggunakan referensi grup keamanan (izinkan grup keamanan ENI sebagai sumber) atau mengizinkan masuk dari VPC CIDR. Lihat Meng [ onfigurasi aturan firewall untuk koneksi pribadi](configuring-integrations-and-knowledge-connecting-to-privately-hosted-tools.md).
+ **Verifikasi rantai sertifikat lengkap untuk CA pribadi. ** Jika otoritas sertifikat pribadi menerbitkan sertifikat TLS layanan Anda, berikan rantai PEM-encoded sertifikat lengkap saat Anda membuat koneksi. Tempatkan sertifikat daun terlebih dahulu, lalu perantara, lalu akarnya. Jika rantai tidak lengkap, jabat tangan TLS gagal meskipun jalur jaringan aktif.
+ **Konfirmasikan target sedang berjalan. ** Pastikan layanan Anda aktif dan menerima koneksi pada port yang diharapkan sebelum Anda menyelesaikan pendaftaran.
## Pertukaran token OAuth tidak dapat dicapai
**Gejala **
Anda mendaftarkan penyedia kemampuan server OAuth-based MCP (Kredensi Klien atau 3LO) melalui koneksi pribadi, tetapi pertukaran token gagal meskipun titik akhir server MCP dapat dijangkau.
**Menyebabkan **
Untuk penyedia OAuth-based kemampuan, AWS DevOps Agen memanggil dua titik akhir: URL ** target ** (titik akhir server MCP) dan URL ** pertukaran ** (titik akhir pertukaran token OAuth). Ketika Anda memilih koneksi pribadi tunggal, itu berlaku untuk * kedua * titik akhir. Jika dua titik akhir hanya dapat dijangkau melalui jalur jaringan yang berbeda, koneksi pribadi tunggal tidak dapat merutekan ke keduanya.
**Resolusi**
+ Jika kedua titik akhir dapat dijangkau melalui jalur yang sama, pastikan alamat host koneksi pribadi dapat merutekan ke titik akhir server MCP dan titik akhir pertukaran token.
+ Jika titik akhir memerlukan jalur jaringan yang berbeda, gunakan bidang per titik akhir, bukan kolom tunggal. `privateConnectionName` Tetapkan `targetUrlPrivateConnectionName` untuk titik akhir server MCP dan `exchangeUrlPrivateConnectionName` untuk titik akhir pertukaran token. Jika Anda menetapkan hanya satu, titik akhir lainnya dicapai melalui internet publik, dan itu tidak jatuh kembali ke koneksi pribadi lainnya. Anda tidak dapat menggabungkan nama per titik akhir dengan `privateConnectionName` permintaan yang sama. Lihat [ Merutekan titik akhir dan pertukaran token OAuth melalui koneksi pribadi yang berbeda. ](configuring-integrations-and-knowledge-connecting-to-privately-hosted-tools.md)
## Gerbang sumber daya atau ENI tetap ada setelah Anda menghapus koneksi
**Gejala **
Anda mengharapkan gateway sumber daya terkelola dan ENI-nya dihapus, tetapi mereka masih muncul di VPC Anda. Ini dapat menimbulkan biaya ENI dan dapat memblokir operasi yang bergantung pada VPC bersih, seperti. `terraform destroy`
**Penyebab **
Gateway sumber daya terkelola dan ENI dihapus hanya saat Anda menghapus koneksi pribadi melalui AWS DevOps Agen. Alasan paling umum mereka tetap ada adalah bahwa tag tidak pernah benar-benar `DeletePrivateConnection` dipanggil, atau bahwa `AWSAIDevOpsManaged` tag telah dihapus dari sumber daya yang dikelola sehingga penghapusan tidak dapat dilanjutkan.
**penting**
** AWS DevOps Agen menandai sumber daya yang dikelolanya (gateway sumber daya dan ENI-nya). `AWSAIDevOpsManaged` Peran terkait layanan hanya dapat bertindak pada sumber daya yang membawa tag ini, jadi ** jangan menghapus atau memodifikasi tag. `AWSAIDevOpsManaged` ** Jika tag hilang, tidak `DeletePrivateConnection` dapat membersihkan sumber daya dan penghapusan gagal.
**Resolusi**
+ **Hapus koneksi melalui AWS DevOps Agen. ** Gunakan konsol (Penyedia ** kemampuan ** > Koneksi ** pribadi ** > T ** indakan ** > ** Hapus**) atau CLI:
``` aws devops-agent delete-private-connection \ --name my-mcp-tool-connection ```
Status berubah menjadi `DELETE_IN_PROGRESS` sementara AWS DevOps Agen menghapus gateway sumber daya terkelola dan ENI dari VPC Anda.
+ **Jika penghapusan gagal, konfir `AWSAIDevOpsManaged` masikan tag masih ada. ** Jika tag dihapus dari gateway sumber daya atau ENI-nya, terapkan kembali ke sumber daya tersebut, lalu jalankan penghapusan lagi.
+ **Jangan mencoba menghapus gateway sumber daya terkelola secara langsung. ** Gerbang sumber daya hanya dapat dibaca di akun Anda dan dikelola sepenuhnya oleh AWS DevOps Agen, dan Anda tidak dapat menghapusnya sendiri melalui Amazon VPC Lattice. Menghapus koneksi pribadi adalah apa yang memicu penghapusannya.
+ Jika Anda menghapus koneksi pribadi, tag ada, dan gateway sumber daya atau ENI masih tetap ada setelah penghapusan selesai, hubungi AWS Dukungan untuk merekonsiliasi sumber daya.
## Meminta bantuan
Jika Anda menyelesaikan bagian yang relevan untuk masalah Anda dan masalah tetap ada, hubungi AWS Dukungan. Sertakan nama koneksi pribadi Anda, status saat ini, AWS Wilayah, dan alamat host target dan port sehingga dukungan dapat menyelidiki jalur jaringan.
## Topik terkait
+ [Menghubungkan ke alat yang dihosting secara pribadi](configuring-integrations-and-knowledge-connecting-to-privately-hosted-tools.md)
+ [Mengkonfigurasi aturan firewall untuk koneksi pribadi ](configuring-integrations-and-knowledge-connecting-to-privately-hosted-tools.md)
+ [VPC Endpoint (AWS PrivateLink)](aws-devops-agent-security-vpc-endpoints-aws-privatelink.md)
+ [Menghubungkan Server MCP](configuring-integrations-and-knowledge-connecting-mcp-servers.md)
+ [AWS DevOps Keamanan Agen](aws-devops-agent-security.md)