Informasi tambahan untuk orang yang mungkin mengalami masalah serupa saat mencoba menyambung ke RDS atau RedShift:
1) Periksa grup keamanan
Verifikasi grup keamanan untuk instans RDS mengizinkan akses dari grup keamanan milik server sumber Anda (atau IP-nya ditambahkan langsung jika eksternal ke AWS). Grup keamanan yang harus Anda lihat adalah grup yang ditentukan dalam atribut instans RDS dari UI konsol RDS (bernama "grup keamanan").
CATATAN :Grup keamanan database mungkin berbeda dari grup keamanan AWS EC2. Jika instans RDS Anda berada di EC2 klasik/publik, Anda harus memeriksa bagian "grup keamanan basis data" pada UI RDS. Untuk pengguna VPC, grup keamanan akan menjadi grup keamanan VPC normal (nama sg-xxx akan dicantumkan dalam atribut instans RDS).
2) Konfirmasikan bahwa DNS tidak menjadi masalah.
Amazon menggunakan DNS terpisah, sehingga pencarian DNS eksternal ke AWS akan mengembalikan IP publik sementara pencarian internal ke AWS akan mengembalikan IP pribadi. Jika Anda menduga ini adalah masalah DNS, sudahkah Anda mengonfirmasi bahwa IP yang berbeda dikembalikan dari zona ketersediaan yang berbeda? Jika AZ yang berbeda mendapatkan IP yang berbeda, Anda harus menghubungi dukungan AWS.
3) Konfirmasi konektivitas jaringan dengan membuat sambungan soket.
Alat seperti tracepath dan traceroute kemungkinan tidak akan membantu karena RDS saat ini menurunkan lalu lintas ICMP.
Uji konektivitas port dengan mencoba membuat koneksi soket ke instance RDS pada port 3306 (mysql, atau 5432 untuk postgres). Mulailah dengan menemukan IP instans RDS dan menggunakan telnet atau nc (pastikan untuk menggunakan IP internal/pribadi jika menghubungkan dari dalam AWS):
telnet x.x.x.x 3306
nc -vz x.x.x.x 3306
a) Jika upaya koneksi Anda tidak berhasil dan segera gagal, port tersebut kemungkinan diblokir atau host jarak jauh tidak menjalankan layanan pada port tersebut. Anda mungkin perlu melibatkan dukungan AWS untuk memecahkan masalah lebih lanjut. Jika menghubungkan dari luar AWS, coba sambungkan dari instans lain di dalam AWS terlebih dahulu (karena firewall Anda mungkin memblokir koneksi tersebut).
b) Jika koneksi Anda tidak berhasil dan Anda mendapatkan batas waktu, paket mungkin dijatuhkan/diabaikan oleh firewall atau paket kembali pada jalur jaringan yang berbeda. Anda dapat mengonfirmasi ini dengan menjalankan netstat -an | grep SYN (dari sesi ssh yang berbeda sambil menunggu perintah telnet/nc timeout).
Koneksi dalam status SYN berarti Anda telah mengirim permintaan koneksi, tetapi belum menerima apa pun kembali (SYN_ACK atau tolak/blokir). Biasanya ini berarti firewall atau grup keamanan mengabaikan atau menjatuhkan paket.
Ini juga bisa menjadi masalah dengan perutean NAT atau banyak jalur dari banyak antarmuka. Periksa untuk memastikan Anda tidak menggunakan iptables atau gateway NAT antara host Anda dan instans RDS. Jika Anda berada di VPC, pastikan juga Anda mengizinkan lalu lintas keluar/keluar dari host sumber.
c) Jika tes koneksi soket Anda berhasil, tetapi Anda tidak dapat terhubung dengan klien mysql (CLI, meja kerja, aplikasi, dll.), lihat output netstat untuk melihat status koneksi (ganti x.x.x.x dengan alamat IP sebenarnya dari instance RDS):
netstat -an | grep x.x.x.x
Jika Anda mendapatkan koneksi yang dibuat saat menggunakan telnet atau NC, tetapi Anda melihat status 'SYN' saat menggunakan klien mysql, Anda mungkin mengalami masalah MTU.
RDS, pada saat ini ditulis, mungkin tidak mendukung paket ICMP yang digunakan untuk PMTUD (https:// /en.wikipedia.org/wiki/Path_MTU_Discovery#Problems_with_PMTUD ). Ini bisa menjadi masalah jika Anda mencoba mengakses RDS atau RedShift yang ada di VPC dari instans EC2 klasik melalui ClassicLink. Coba turunkan MTU dengan yang berikut, lalu uji lagi:
sudo ip link show
# take note of the current MTU (likely 1500 or 9001)
sudo ip link set dev eth0 mtu 1400
Jika MTU yang lebih rendah berfungsi, pastikan untuk menindaklanjuti dengan dukungan pelanggan AWS untuk mendapatkan bantuan dan menyebutkan bahwa Anda melihat masalah MTU saat mencoba menghubungkan ke instans RDS Anda. Ini dapat terjadi jika paket TCP dibungkus dengan enkapsulasi untuk tunneling, menghasilkan MTU yang dapat digunakan lebih rendah untuk data paket/payload. Menurunkan MTU di server sumber memungkinkan paket yang dibungkus tetap muat di bawah batas MTU saat melewati gateway tunneling.
Jika tidak berhasil, atur kembali MTU Anda ke default dan libatkan dukungan AWS untuk pemecahan masalah lebih lanjut.
