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 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, lihatMenghubungkan ke alat yang dihosting secara pribadi.
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 melihatCould not complete request to provider.,Unable to connect to the MCP server at <endpoint>. 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, 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 <your-host-address>Jika diselesaikan di sana tetapi tidak dari DNS publik, dan koneksi pribadi Anda menggunakandnsResolution: 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.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_VPCuntuk 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 statusCREATE_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:
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.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.
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:
aws ec2 describe-subnets \ --subnet-ids <your-subnet-ids> \ --query 'Subnets[*].[SubnetId,AvailabilityZoneId]'
Anda belum mencapai kuota layanan Amazon VPC Lattice. Periksa akun Anda terhadap kuota Amazon VPC Lattice, terutama batas gateway sumber daya.
Tidak ada kebijakan IAM atau SCP yang memblokir peran terkait layanan. Gateway sumber daya yang dikelola layanan dibuat melalui peran terkait layanan. Jika organisasi Anda memiliki kebijakan kontrol layanan (SCP) 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 '<endpoint>' timed out while initializing the session.(varian serupa mengacu pada sumber daya daftar)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.(mungkin juga muncul sebagaiAPI 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,).443Konfirmasikan 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.
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.
privateConnectionNameTetapkantargetUrlPrivateConnectionNameuntuk titik akhir server MCP danexchangeUrlPrivateConnectionNameuntuk 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 denganprivateConnectionNamepermintaan yang sama. Lihat Merutekan titik akhir dan pertukaran token OAuth melalui koneksi pribadi yang berbeda.
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
AWSAIDevOpsManagedmasikan 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
