Proses debug konektivitas

MySQL | PostgreSQL | PostgreSQL ke AlloyDB

Men-debug konektivitas

Anda telah menyiapkan konektivitas antara database sumber dan tujuan, tetapi bagaimana Anda tahu bahwa keduanya terhubung? Jika komunikasi antara keduanya gagal, bagaimana Anda dapat mengetahui apa yang salah dan di mana?

Alat yang paling dasar adalah ping dan traceroute.

Ping

Ping melakukan pengujian dasar untuk menentukan apakah tujuan ("host jarak jauh") tersedia dari sumber. Ping mengirimkan paket ICMP Echo Request ke host jarak jauh, dan mengharapkan ICMP Echo Reply sebagai balasannya. Jika ping tidak berhasil, berarti tidak ada rute dari sumber ke tujuan. Namun, keberhasilan tidak berarti paket Anda dapat terkirim, hanya saja secara umum, host jarak jauh dapat dijangkau.

Meskipun ping dapat mengetahui apakah host aktif dan merespons, tetapi tidak dijamin dapat diandalkan. Beberapa penyedia jaringan memblokir ICMP sebagai tindakan pencegahan keamanan, yang dapat membuat proses debug konektivitas menjadi lebih sulit.

Traceroute

Traceroute menguji paket jaringan rute lengkap yang diambil dari satu host ke host lainnya. Alat ini menampilkan semua langkah ("hop") yang diambil paket di sepanjang rute, dan berapa lama waktu yang dibutuhkan untuk setiap langkah. Jika paket tidak terkirim hingga ke tujuan, traceroute tidak akan selesai, tetapi akan berakhir dengan serangkaian tanda bintang. Dalam hal ini, cari alamat IP terakhir yang berhasil dijangkau di sepanjang rute. Di sinilah konektivitas terputus.

Traceroute dapat mengalami waktu tunggu. Alat ini juga dapat gagal diselesaikan jika gateway di sepanjang rute tidak dikonfigurasi dengan benar untuk meneruskan paket ke hop berikutnya.

Jika traceroute gagal diselesaikan, Anda mungkin dapat mengetahui tempatnya berhenti. Temukan alamat IP terakhir yang tercantum dalam output traceroute, lalu lakukan penelusuran browser untuk who owns [IP_ADDRESS]. Hasilnya mungkin atau mungkin tidak menampilkan pemilik alamat, tetapi patut dicoba.

mtr

Alat mtr adalah bentuk traceroute yang tetap aktif dan terus diperbarui, mirip dengan cara perintah top berfungsi untuk proses lokal.

Menemukan alamat IP lokal Anda

Jika Anda tidak mengetahui alamat lokal host, jalankan perintah ip -br address show. Di Linux, hal ini menunjukkan antarmuka jaringan, status antarmuka, IP lokal, dan alamat MAC. Contoh: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64.

Atau, Anda dapat menjalankan ipconfig atau ifconfig untuk melihat status antarmuka jaringan.

Menemukan alamat IP keluar

Jika Anda tidak mengetahui alamat IP yang digunakan database sumber dan tujuan untuk berkomunikasi satu sama lain (alamat IP keluar), selesaikan langkah-langkah berikut:

Buka halaman Instance SQL di Google Cloud console.

Buka halaman Instance Cloud SQL
Klik nama instance yang terkait dengan tugas migrasi yang Anda debug.
Scroll ke bawah hingga panel Connect to this instance muncul. Di panel ini, alamat IP keluar akan muncul.

Buka port lokal

Untuk memverifikasi bahwa host memproses port yang menurut Anda benar, jalankan perintah ss -tunlp4. Perintah ini memberitahu Anda tentang port yang terbuka dan sedang memproses. Misalnya, jika Anda memiliki database MySQL yang berjalan, port 3306 seharusnya aktif dan memproses. Untuk SSH, Anda akan melihat port 22.

Semua aktivitas port lokal

Gunakan perintah netstat untuk melihat semua aktivitas port lokal. Misalnya, netstat -lt menampilkan semua port yang saat ini aktif.

Menghubungkan ke host jarak jauh menggunakan telnet

Untuk memverifikasi bahwa Anda dapat terhubung ke host jarak jauh menggunakan TCP, jalankan perintah telnet. Telnet mencoba terhubung ke alamat IP dan port yang Anda berikan.

Misalnya, jika host jarak jauh Anda menjalankan database MySQL, Anda seharusnya dapat melakukan telnet ke database tersebut di port 3306: telnet 35.193.198.159 3306.

Jika berhasil, Anda akan melihat hal berikut:

Trying 35.193.198.159...

Connected to 35.193.198.159..

Jika gagal, Anda akan melihat telnet berhenti merespons hingga Anda menutup paksa upaya tersebut:

Trying 35.193.198.159...

^C..

Cloud Logging

Database Migration Service dan Cloud SQL menggunakan Cloud Logging. Lihat dokumentasi Cloud Logging untuk mengetahui informasi selengkapnya dan tinjau contoh kueri Cloud SQL.

Melihat log

Anda dapat melihat log untuk instance Cloud SQL dan project lainnya, seperti instance Cloud VPN atau Compute Engine. Google CloudUntuk melihat log yang berisi entri log instance Cloud SQL Anda:

Konsol

Buka Logs Explorer
Pilih project Cloud SQL yang sudah ada di bagian atas halaman.
Di Builder kueri, tambahkan hal berikut:

Resource: Pilih Database Cloud SQL. Pada dialog, pilih instance Cloud SQL.
Nama log: Scroll ke bagian Cloud SQL dan pilih file log yang sesuai untuk instance Anda. Contoh:
- cloudsql.googlapis.com/mysql-general.log
- cloudsql.googleapis.com/mysql.err
Tingkat keparahan: Pilih level log.
Rentang waktu: Pilih preset atau buat rentang kustom.

gcloud

Gunakan perintah gcloud logging untuk melihat entri log. Pada contoh di bawah, ganti PROJECT_ID. Flag limit adalah parameter opsional yang menunjukkan jumlah entri maksimum yang akan ditampilkan.

gcloud logging read "projects/[PROJECT_ID]/logs/cloudsql.googleapis.com/mysql-general.log" --limit=10

Alamat IP pribadi

Koneksi ke instance Cloud SQL yang menggunakan alamat IP pribadi akan otomatis diizinkan untuk rentang alamat IP RFC 1918. Rentang alamat IP Non-RFC 1918 harus dikonfigurasi di Cloud SQL sebagai jaringan yang diizinkan. Anda juga harus memperbarui peering jaringan ke Cloud SQL untuk mengekspor rute Non-RFC 1918. Contoh: gcloud compute networks peerings update cloudsql-mysql-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT

Rentang IP 172.17.0.0/16 dicadangkan untuk jaringan bridge Docker. Instance Cloud SQL yang dibuat dengan alamat IP dalam rentang tersebut tidak akan dapat dijangkau. Koneksi dari alamat IP mana pun dalam rentang tersebut ke instance Cloud SQL yang menggunakan alamat IP pribadi akan gagal.

Pemecahan masalah VPN

Lihat halaman Google Cloud Pemecahan masalah Cloud VPN.

Memecahkan masalah tunnel SSH terbalik

Tunneling SSH adalah metode untuk meneruskan beberapa komunikasi di atas koneksi SSH. Tunneling SSH terbalik memungkinkan penyiapan tunnel SSH, tetapi mempertahankan bahwa jaringan tujuan adalah jaringan yang memulai koneksi tunnel. Hal ini berguna jika Anda tidak ingin membuka port di jaringan Anda sendiri untuk tujuan keamanan.

Yang ingin Anda capai adalah menyiapkan hal berikut: Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

Diasumsikan bahwa:

Compute Engine VM bastion dapat mengakses Cloud SQL DB.
source network bastion dapat mengakses source DB (hal ini dicapai dengan melakukan peering jaringan Cloud SQL ke jaringan VM Compute Engine).

Kemudian, Anda menyiapkan tunnel SSH dari source network bastion ke Compute Engine VM bastion, yang merutekan koneksi masuk ke beberapa port di Compute Engine VM bastion melalui tunnel ke source DB.

Setiap link dalam skenario di atas dapat disiapkan dengan tidak benar dan mencegah seluruh alur berfungsi. Pecahkan masalah setiap link, satu per satu:

`source network bastion` ---> `source DB`

Hubungkan ke source network bastion menggunakan SSH, atau dari terminal jika merupakan mesin lokal.
Uji konektivitas ke DB sumber menggunakan salah satu metode berikut:
- telnet [source_db_host_or_ip] [source_db_port] - diharapkan melihat perintah sandi mysql (seperti 5.7.12-logPuN0%`D5G??f9nVS'Pmysql_native_passwordConnection)
- [db_client] -h[source_db_host_or_ip] -P[source_db_port] - diharapkan melihat akses ditolak (seperti ERROR 1045 (28000): Access denied for user...)

Jika gagal, Anda harus memverifikasi bahwa Anda mengaktifkan akses dari bastion ini ke DB sumber.

`Compute Engine VM bastion` ---> `source DB`

SSH ke Compute Engine VM bastion (menggunakan gcloud compute ssh VM_INSTANCE_NAME)
Uji konektivitas ke DB sumber menggunakan salah satu metode berikut:
- telnet 127.0.0.1 [tunnel_port] - diharapkan melihat perintah sandi mysql password prompt (seperti 5.7.12-logPuN0%`D5G??f9nVS'Pmysql_native_passwordConnection)
- [db_client] -h127.0.0.1 -P[tunnel_port] - diharapkan melihat akses ditolak (seperti ERROR 1045 (28000): Access denied for user...)

Jika gagal, Anda harus memverifikasi bahwa tunnel aktif dan berjalan dengan benar. Menjalankan sudo netstat -tupln akan menampilkan semua proses yang memproses di VM ini, dan Anda akan melihat sshd listening on the tunnel_port.

`Cloud SQL DB` ---> `source DB`

Hal ini paling baik diuji dengan testing the migration job dari Database Migration Service. Jika gagal, berarti ada masalah dengan peering atau perutean VPC antara jaringan Cloud SQL dan Compute Engine VM bastion jaringan.

Firewall server database sumber harus dikonfigurasi untuk mengizinkan seluruh rentang IP internal yang dialokasikan untuk koneksi layanan pribadi jaringan VPC yang akan digunakan oleh instance tujuan Cloud SQL sebagai privateNetwork kolom dari setelan ipConfiguration-nya.

Untuk menemukan rentang IP internal di konsol:

Buka halaman VPC networks di Google Cloud konsol.
Pilih jaringan VPC yang ingin Anda gunakan.

Pilih Private services access > Allocated IP ranges for services.
Temukan Internal IP range yang terkait dengan koneksi yang dibuat oleh servicenetworking-googleapis-com.

Anda juga dapat melihat traffic antara instance Cloud SQL dan instance VM Compute Engine di konsol Cloud Logging dalam Cloud VPN gateway project. Di log VM Compute Engine, cari traffic yang berasal dari instance Cloud SQL. Di log instance Cloud SQL, cari traffic dari VM Compute Engine.