Tidak dapat terhubung ke instance RDS dari luar VPC (ERROR 2003 (HY000) Tidak dapat terhubung ke MySQL Server)


12

Saya telah membuat VPC, dan di dalamnya ada instance RDS. Mesin virtual RDS dapat diakses oleh publik dan pengaturannya adalah sebagai berikut:

Pengaturan RDS

Grup keamanan yang dilampirkan ke instance RDS menerima semua lalu lintas:

Pengaturan grup keamanan

Semua ACL jaringan saya menerima semua lalu lintas. Namun, saya tidak dapat mengakses instance saya dari mesin di luar VPC saya. Saya mendapatkan kesalahan berikut:

    root@vps151014:~# mysql -h mysql1.xxxxxxxxxxxx.eu-west-1.rds.amazonaws.com -P 3306 -u skullberry -p
Enter password: 
ERROR 2003 (HY000): Can't connect to MySQL server on 'mysql1.xxxxxxxxxxxx.eu-west-1.rds.amazonaws.com' (110)

Jika saya menjalankan perintah yang sama dari EC2 di dalam VPC saya, saya dapat terhubung. Saya sudah mencoba menghubungkan dari beberapa mesin, semuanya tanpa firewall (yaitu port 3306 terbuka).

Saya jelas kehilangan sesuatu tetapi semuanya tampaknya sudah dikonfigurasi dengan benar. Apa yang bisa menjadi masalah?


1
The (110)dalam sarana pesan kesalahan "koneksi timed out," jadi pasti ini adalah masalah konektivitas IP. Mesin virtual RDS Anda menunjukkan dikaitkan dengan dua subnet. Di konsol VPC, apa rute default kedua subnet itu? Apakah itu "igw-xxxxxxxx" atau apakah itu "i-xxxxxxxx"?
Michael - sqlbot

Kedua subnet secara implisit dikaitkan dengan tabel rute utama VPC.
dazedviper

1
Mengaitkan kedua subnet secara eksplisit ke tabel rute kustom yang merutekan semua lalu lintas keluar ke gateway internet VPC tidak membuat perbedaan apa pun.
dazedviper

1
Nah, itu mengecewakan. Rute default ke "igw" tampak seperti bagian yang hilang paling mungkin ... dan harus dalam keadaan apa pun diperlukan agar ini berfungsi. Dengan asumsi Anda memberi VPC cukup waktu untuk mengkonfigurasi ulang dirinya di latar belakang setelah mengubah konfigurasi subnet, saya kehabisan ide.
Michael - sqlbot

2
Ah, blok yang Anda butuhkan untuk semua alamat IP adalah 0.0.0.0/0. Saya akan memposting jawabannya.
Michael - sqlbot

Jawaban:


20

Untuk instance RDS di VPC yang dapat diakses "secara publik" (Internet), semua subnet yang dilampirkan haruslah "publik" - sebagai lawan dari "pribadi" - subnet VPC.

Subnet publik pada dasarnya didefinisikan sebagai subnet yang memiliki objek Internet Gateway (igw-xxxxxxxx) sebagai rutenya ke "Internet," atau setidaknya ke semua tujuan Internet yang perlu Anda akses. Biasanya, ini adalah alamat tujuan 0.0.0.0/0. Subnet publik harus digunakan untuk instance (termasuk RDS) yang akan memiliki alamat IP publik yang terkait, dan tidak boleh digunakan untuk instance yang tidak akan memiliki alamat IP publik, karena alamat pribadi tidak berfungsi di Internet tanpa terjemahan.

Subnet pribadi, sebaliknya, memiliki tabel perutean yang dikonfigurasi untuk mencapai tujuan Internet melalui instance EC2 lainnya, biasanya instance NAT. Ini ditampilkan dalam tabel rute VPC yang terkait dengan subnet itu sebagai i-xxxxxxxx, bukan "igw." Mesin itu (yang, sendiri, sebenarnya akan berada di subnet yang berbeda dari yang digunakan sebagai tujuan rute) berfungsi sebagai penerjemah, memungkinkan instance privat-IP-only untuk secara transparan membuat permintaan Internet keluar menggunakan publik mesin NAT menggunakan publik IP untuk kebutuhan Internet mereka. Mesin virtual dengan alamat IP publik tidak dapat berinteraksi dengan Internet dengan benar jika dilampirkan ke subnet pribadi.

Dalam kasus tertentu, di sini, subnet yang terkait dengan instance RDS tidak benar-benar dikonfigurasikan sebagai sesuatu yang dapat dengan mudah diklasifikasikan sebagai subnet pribadi atau publik, karena subnet tidak memiliki rute default sama sekali. Menambahkan rute default melalui objek "igw", atau, seperti yang dilakukan OP, menambahkan rute statis ke alamat IP Internet di mana konektivitas diperlukan, ke dalam tabel rute VPC untuk subnet memperbaiki masalah konektivitas.

Namun ... Jika Anda mengalami masalah yang serupa, Anda tidak bisa begitu saja mengubah tabel rute atau membuat tabel rute baru dan mengaitkan subnet dengan mereka, kecuali jika Anda tidak memiliki hal lain yang sudah bekerja dengan benar pada subnet, karena perubahan itu bisa masuk akal diharapkan dapat memutus konektivitas yang ada. Kursus yang benar, dalam hal ini, akan menyediakan contoh pada subnet yang berbeda dengan entri tabel rute yang benar di tempat.

Saat mengatur VPC, sangat ideal untuk secara jelas mendefinisikan peran subnet dan penyediaan penuh kemudian dengan rute yang diperlukan ketika VPC pertama kali ditugaskan. Penting juga untuk diingat bahwa seluruh VPC "LAN" adalah jaringan yang ditentukan oleh perangkat lunak. Tidak seperti di jaringan fisik, di mana router dapat menjadi hambatan dan sering masuk akal untuk menempatkan mesin dengan lalu lintas yang padat di antara mereka di subnet yang sama ... lalu lintas subnet tidak memiliki kelemahan kinerja pada VPC. Mesin harus ditempatkan pada subnet yang sesuai untuk kebutuhan pengalamatan IP mesin - alamat publik, subnet publik; tidak ada alamat publik, subnet pribadi.

Diskusi lebih lanjut tentang logistik subnet pribadi / publik di VPC dapat ditemukan di Mengapa Kita Membutuhkan Subnet Pribadi di VPC (di Stack Overflow)


2

Ini sudah memiliki jawaban yang bagus, tetapi AWS membuat subnet publik untuk Anda ketika Anda memilih opsi "dapat diakses publik". Sebaliknya, bagi saya masalahnya adalah grup keamanan VPC default. Saya melihat aturan Jaringan ACL - bukan Grup Keamanan . (Memilih opsi "dapat diakses publik" di RDS menambahkan grup keamanan tetapi tidak secara otomatis menambahkan aturan masuk.)

Klik RDS dan identifikasi dan klik pada grup keamanan. Kemudian di bawah "aturan masuk" tambahkan port 3306 dan tambahkan alamat IPV4 Anda yang terhubung, xxxx / 32 (atau 0.0.0.0/32 - jika Anda ingin seluruh Internet terhubung - tetapi hati-hati dengan itu).


0

Juga periksa untuk memastikan jaringan yang Anda hubungkan tidak memblokir koneksi ke server lain pada port 3306. Ini adalah kasus bagi saya ketika terhubung ke jaringan perusahaan saya.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.