Halaman dimuatkan tetapi muat naik tersekat pada VPN: punca mana menang
Tersekat yang bergantung pada saiz sepadan dengan kerosakan MTU laluan, dan juga sepadan dengan DNS, had aplikasi atau terowong yang tidak stabil. Empat pemerhatian menentukan yang mana.
Halaman dimuatkan, VPN melaporkan bersambung, dan muat naik fail membeku pada titik yang sama setiap kali. Empat penjelasan sepadan dengan huraian itu: masalah saiz paket, masalah penyelesaian nama, had aplikasi dan terowong yang sentiasa ditetapkan semula. Setiap satunya boleh disahkan atau dikecualikan dengan pemerhatian berbeza, jadi keputusannya ialah memilih ujian yang betul, bukan meneka puncanya.
Empat calon dan satu bentuk
Mulakan dengan bentuk kegagalan, kerana ia menyingkirkan sebahagian besar senarai sebelum sebarang alat dibuka. Tersekat yang berlaku pada saiz tetap ialah masalah saiz sehingga dibuktikan sebaliknya. Tersekat pada titik rawak ialah masalah kehilangan atau kestabilan. Kegagalan sebelum sambungan dibuka ialah masalah nama.
Calon keempat ialah aplikasi. Had muat naik, tamat masa permintaan dan had saiz badan pada proksi menghasilkan kegagalan yang kelihatan seperti kerosakan rangkaian dari pelayar, dan ia biasanya datang sebagai penolakan, bukan tersekat.
Catat bentuk yang diperhatikan sebelum menguji apa-apa. "Berhenti pada bilangan bait yang lebih kurang sama, setiap kali, dengan terowong hidup" ialah titik permulaan yang jauh lebih kukuh daripada "muat naik tidak berfungsi".
Kemudian kekalkan laluan itu semasa menguji. Menukar jalan keluar, protokol dan pelayan serentak menghasilkan keputusan yang tidak boleh anda kaitkan dengan mana-mana daripadanya. Satu pemboleh ubah setiap larian, dan catatkannya.
Bahagi dua saiz sebelum menyentuh dasar
Pembeza paling murah ialah prob yang mengubah satu nombor. Hantar ping tanpa pemecahan yang bertambah saiz ke destinasi, muat naik fail yang anda kawal ke perkhidmatan yang sama, kemudian bandingkan di mana setiap satu berhenti.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadPerintah pertama melaporkan sama ada paket bersaiz penuh melepasi laluan sama sekali. Pada MTU 1500 bait, muatan ICMP terbesar yang tidak dipecahkan ialah 1472 bait, dan terowong mengambil lebih banyak daripada belanjawan itu sebelum paket dalam bermula. Yang kedua memberi anda saiz dan tempoh untuk pemindahan peringkat aplikasi, dan itulah nombor yang benar-benar penting.
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
Baca kedua-duanya bersama. Prob yang gagal di atas ambang dan muat naik yang berhenti berhampiran ambang yang sama ialah cerita yang koheren. Prob yang semuanya berjaya manakala muat naik tersekat pada bilangan bait yang jelas dibawa laluan menunjukkan aplikasi atau pelayan, dan tiada kerja MTU akan mengubahnya. Keputusan negatif itu bernilai sama dengan yang positif. Ia menyingkirkan cabang siasatan yang paling mahal.
Kemudian semak kestabilan semasa pemindahan, kerana terowong yang memperbaharui kunci di tengah-tengah muat naik besar menghasilkan kegagalan yang kelihatan bergantung pada saiz tanpa sebenarnya. Bacaan masa operasi ialah cara paling murah untuk mengesahkannya.
Pilih antara pembaikan dan penyelesaian sementara
Jika bukti menunjukkan saiz, ada dua jawapan jujur dan satu tidak jujur. Yang jujur ialah memulihkan penemuan MTU laluan dengan membenarkan maklum balas ICMP yang diperlukan, atau mengehadkan saiz segmen yang diumumkan supaya rakan sebaya menghantar segmen lebih kecil. Yang tidak jujur ialah menurunkan MTU antara muka kepada nilai yang disalin dari forum dan tidak pernah mengesahkan apa yang diubahnya.
Pilihan bergantung pada apa yang anda kawal. Pada rangkaian yang anda kendalikan, membenarkan mesej ICMP ialah pembaikan yang lebih bersih kerana ia mengekalkan mekanisme berfungsi untuk setiap protokol. Pada laluan yang tidak anda kawal, pengehadan ialah pilihan praktikal, dan ia harus digunakan secara sempit dan bukan pada seluruh pelayan.
Jika bukti menunjukkan aplikasi, baiki aplikasi atau konfigurasi proksinya. Respons 413 dan sambungan tergantung ialah kegagalan berbeza, dan yang kedua biasanya tamat masa di suatu tempat dalam rantaian yang merangkumi proksi dengan hadnya sendiri.
Sama ada cara, simpan nilai asal dan uji semula selepas dikembalikan. Perubahan yang bertepatan dengan pemindahan yang berjaya bukan bukti bahawa ia menyebabkan kejayaan itu, dan keupayaan membatalkannya ialah yang memisahkan diagnosis daripada kebetulan.
Rekod keputusan supaya ia bertahan sehingga insiden seterusnya
Empat fakta sudah cukup: bentuk kegagalan yang diperhatikan, keputusan prob, perubahan yang anda buat dan keputusan ujian semula. Dengannya, orang seterusnya boleh memberitahu sama ada masalah itu sama atau masalah baharu dengan gejala yang sama.
Catat juga konteks laluan, kerana penemuan MTU adalah khusus kepada satu pautan. Komputer riba yang berfungsi di rumah dan gagal di hotel mempunyai dua laluan, dan pembaikan yang digunakan pada satu daripadanya tidak berkata apa-apa tentang yang lain.
Akhir sekali, bertahanlah dengan ringkasan bahawa "VPN merosakkan muat naik". Terowong itu hadir dalam kes yang berjaya dan yang gagal; yang berubah ialah saiz paket yang perlu dibawa laluan, atau tempat pemindahan dihentikan. Menamakan mekanisme sebenar itulah yang menjadikan nota ini berguna.