Kueri yang tergantung selepas handshake TCP bukan masalah penghalaan. Kerosakan laluan menggagalkan handshake, jadi sesi yang terbentuk kemudian senyap menunjuk ke bahagian dalam laluan: pemeriksaan, MTU, atau cara paket UDP terowong tiba. Keputusan di hadapan anda ialah membaiki laluan itu atau memindahkan terowong ke TCP. Tiga syarat menentukannya, dan tiada satu pun tentang pangkalan data.

Kelaskan kesekatan sebelum menyalahkan terowong

Empat hasil kelihatan sama kepada pengguna dan bermakna perkara yang sangat berbeza kepada jurutera.

What the client seesWhat it rules out
Connection refusedNothing is listening on the address and port the client reached
Timeout before the handshakeA filter, a missing route, or the wrong address
Handshake completes, query hangsThe session exists, so look at inspection, MTU and packet order
Stalls that recover on retryOften reordering, or a state table entry expiring

Hanya dua baris terakhir mewajarkan masa pada terowong. Sambungan yang ditolak melalui VPN biasanya pangkalan data yang hanya mendengar pada loopback, yang merupakan masalah pendengar, dan tamat masa sebelum handshake ialah penapis atau laluan. Kedua-duanya tidak bertambah baik dengan menukar enkapsulasi.

Tulis klasifikasi itu ke dalam tiket dahulu. Ia langkah paling murah dan menghapuskan sebahagian besar ruang carian.

Tiga syarat yang menentukan UDP berbanding TCP

Trafik IPsec yang dienkapsulasi bergerak melalui UDP, dan UDP memberi laluan kebebasan untuk menyusun semula dan menggugurkan tanpa memberitahu sesiapa. Apabila penyusunan semula menolak paket ke luar tetingkap anti-ulangan terowong, ia digugurkan secara senyap dan sesi TCP dalaman hanya menunggu. Itulah mekanisme di sebalik handshake yang berjaya dan kueri yang tidak pernah kembali.

Membaiki laluan atau beralih kepada TCP bergantung pada tiga perkara. Pertama, adakah kehilangan paket sebenar pada laluan, atau hanya penyusunan semula? Kedua, bolehkah anda menukar tempat pemeriksaan berlaku, atau mengecualikan terowong ini daripada komponen yang menyusun semula? Ketiga, adakah beban kerja sensitif terhadap corak kesekatan, contohnya banyak sesi bermultipleks yang berkongsi satu pautan?

Jika jawapan pertama ialah kehilangan dan yang kedua tidak,TCP pada 443 ialah alternatif pragmatik. Jika jawapan kedua ialah ya, baiki laluan dan kekalkan UDP.

Baca rekod tembok api, bukan ralat aplikasi

Aplikasi melaporkan tamat masa, yang tidak memberitahu apa-apa tentang punca. Log tembok api sendiri ialah tempat pengguguran atau sekatan muncul, jadi tapis mengikut alamat pangkalan data dan aplikasi serta cari pengguguran dan juga penerimaan.Bilah pencegahan ancaman boleh menggugurkan paket tanpa menghasilkan ralat pada peringkat aplikasi, dan itulah tepat bentuk kueri yang tergantung. Senyap dalam log juga data: ia menunjuk kepada sesuatu yang tidak merekod, seperti penyusunan semula.

Periksa juga kluster. Kluster yang salah dikonfigurasi boleh menahan sesi dalam jadual keadaan pada satu ahli sementara paket melalui laluan ahli lain, jadi balasan tiba di tempat yang tiada keadaan. Kesekatan seperti itu kelihatan rawak dan tidak berkorelasi dengan beban.

Bandingkan kedua-dua hujung sebelum menukar apa-apa, dan bandingkan urutan ketibaan bukan bilangan paket:

tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcap

Apa sebenarnya kos TCP pada 443 kepada anda

Memindahkan terowong ke TCP menghapuskan gejala penyusunan semula, kerana kotak tengah kini melihat aliran tersusun. Ia juga mencipta TCP atas TCP. Sambungan luar menghantar semula apa yang sambungan dalam sudah hantar semula, dan satu kehilangan boleh menghentikan semua sesi bermultipleks serentak. Pada laluan bersih itu tidak kelihatan. Pada laluan yang bergelora, ubat lebih buruk daripada gejala.

Pertukaran itu boleh diterima apabila alternatifnya ialah ketiadaan sambungan, dan ia harus didokumenkan sebagai pengecualian dengan pemilik dan bukan diserap sebagai perkara biasa.

Catat pengangkutan, port, contoh kueri dan hasil yang diukur, serta tarikh. Tanpa rekod itu jurutera seterusnya mengulangi eksperimen, dan pengecualian itu diam-diam menjadi seni bina.

Kekalkan keputusan boleh disemak semula

Diagnosis laluan cepat lapuk. Kotak tengah diganti, konfigurasi bilah berubah, pautan dinaik taraf, dan sebab TCP pada 443 hilang sementara konfigurasi kekal. Letakkan tarikh semakan pada pengecualian itu dan namakan syarat yang membolehkan anda kembali kepada UDP.

Uji kedua-dua pengangkutan dengan kueri kecil dan dengan set hasil besar. Penyusunan semula muncul sebagai kesekatan bergantung saiz, manakala kerosakan pendengar menghentikan kedua-dua saiz secara sama rata.

Artikel berkaitan