Kueri basis data macet di atas IPsec: penataan ulang UDP atau TCP?
Kueri yang macet setelah handshake bersih menunjuk ke bagian dalam jalur tunnel. Tiga kondisi menentukan apakah jalur diperbaiki atau beralih ke TCP pada 443.
Kueri yang macet setelah handshake TCP bukan masalah perutean. Kesalahan rute membuat handshake gagal, jadi sesi yang terbentuk lalu diam menunjuk ke bagian dalam jalur: inspeksi, MTU, atau cara paket UDP tunnel tiba. Keputusan di depan Anda adalah memperbaiki jalur itu atau memindahkan tunnel ke TCP. Tiga kondisi menentukan hal itu, dan tidak satu pun tentang basis data.
Klasifikasikan kemacetan sebelum menyalahkan tunnel
Empat hasil terlihat sama bagi pengguna dan berarti hal yang sangat berbeda bagi seorang insinyur.
| What the client sees | What it rules out |
|---|---|
| Connection refused | Nothing is listening on the address and port the client reached |
| Timeout before the handshake | A filter, a missing route, or the wrong address |
| Handshake completes, query hangs | The session exists, so look at inspection, MTU and packet order |
| Stalls that recover on retry | Often reordering, or a state table entry expiring |
Hanya dua baris terakhir yang membenarkan waktu pada tunnel. Koneksi yang ditolak melalui VPN biasanya basis data yang hanya mendengarkan di loopback, yang merupakan masalah pendengar, dan timeout sebelum handshake adalah filter atau rute. Keduanya tidak membaik dengan mengubah enkapsulasi.
Tulis klasifikasi itu ke tiket terlebih dahulu. Itu langkah termurah dan menghapus sebagian besar ruang pencarian.
Tiga kondisi yang menentukan UDP atau TCP
Lalu lintas IPsec yang dienkapsulasi berjalan di atas UDP, dan UDP memberi jalur kebebasan untuk menata ulang dan menjatuhkan paket tanpa memberi tahu siapa pun. Saat penataan ulang mendorong paket ke luar jendela anti-pengulangan tunnel, paket itu dibuang diam-diam dan sesi TCP di dalamnya hanya menunggu. Itulah mekanisme di balik handshake yang berhasil dan kueri yang tidak pernah kembali.
Memperbaiki jalur atau beralih ke TCP bergantung pada tiga hal. Pertama, apakah ada kehilangan paket nyata di jalur, atau hanya penataan ulang? Kedua, dapatkah Anda mengubah tempat inspeksi terjadi, atau mengecualikan tunnel ini dari komponen yang menata ulang? Ketiga, apakah beban kerja peka terhadap pola kemacetan, misalnya banyak sesi termultipleks yang berbagi satu tautan?
Jika jawaban pertama adalah kehilangan dan jawaban kedua tidak,TCP pada 443 adalah pilihan pragmatis. Jika jawaban kedua ya, perbaiki jalur dan pertahankan UDP.
Baca catatan firewall, bukan kesalahan aplikasi
Aplikasi melaporkan timeout, yang tidak memberi tahu apa pun tentang penyebabnya. Log firewall sendiri adalah tempat pembuangan atau pemblokiran muncul, jadi saring berdasarkan alamat basis data dan aplikasi serta cari pembuangan maupun penerimaan.Modul pencegahan ancaman dapat membuang paket tanpa menghasilkan kesalahan di tingkat aplikasi, dan itulah tepatnya bentuk kueri yang macet. Diam di log juga data: itu menunjuk ke sesuatu yang tidak mencatat log, seperti penataan ulang.
Periksa juga cluster. Cluster yang salah dikonfigurasi dapat menahan sesi di tabel status pada satu anggota sementara paket menempuh jalur anggota lain, sehingga balasan tiba di tempat yang tidak ada statusnya. Kemacetan semacam itu tampak acak dan tidak berkorelasi dengan beban.
Bandingkan kedua ujung sebelum mengubah apa pun, dan bandingkan urutan kedatangan alih-alih jumlah paket:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapBerapa sebenarnya biaya TCP pada 443 bagi Anda
Memindahkan tunnel ke TCP menghilangkan gejala penataan ulang, karena middlebox kini melihat aliran yang berurutan. Itu juga menciptakan TCP di atas TCP. Koneksi luar mengirim ulang apa yang sudah dikirim ulang koneksi dalam, dan satu kehilangan dapat menghentikan semua sesi termultipleks sekaligus. Pada jalur bersih itu tak terlihat. Pada jalur yang lossy, obatnya lebih buruk daripada gejalanya.
Pertukaran itu dapat diterima ketika alternatifnya adalah tidak ada konektivitas, dan itu harus didokumentasikan sebagai pengecualian dengan pemilik, bukan diserap sebagai hal normal.
Catat transport, port, contoh kueri, dan hasil yang diukur, plus tanggalnya. Tanpa catatan itu insinyur berikutnya mengulang eksperimennya, dan pengecualian itu diam-diam menjadi arsitektur.
Jaga keputusan tetap dapat ditinjau
Diagnosis jalur menua dengan buruk. Middlebox diganti, konfigurasi modul berubah, tautan ditingkatkan, dan alasan TCP pada 443 menghilang sementara konfigurasinya tetap. Beri tanggal tinjauan pada pengecualian itu dan sebutkan kondisi yang akan memungkinkan Anda kembali ke UDP.
Uji kedua transport dengan kueri kecil dan dengan kumpulan hasil besar. Penataan ulang muncul sebagai kemacetan yang bergantung pada ukuran, sedangkan kesalahan pendengar menghentikan kedua ukuran secara setara.