Halaman termuat tetapi unggahan macet di VPN: penyebab mana yang menang
Macet yang bergantung pada ukuran cocok dengan gangguan MTU jalur, juga cocok dengan DNS, batas aplikasi, atau terowongan yang berkedip. Empat pengamatan menentukan yang mana.
Halaman termuat, VPN melaporkan terhubung, dan unggahan file membeku di titik yang sama setiap kali. Empat penjelasan cocok dengan deskripsi itu: masalah ukuran paket, masalah resolusi nama, batas aplikasi, dan terowongan yang terus mengatur ulang. Masing-masing dapat dipastikan atau disingkirkan dengan pengamatan berbeda, jadi keputusannya adalah memilih uji yang tepat, bukan menebak penyebabnya.
Empat kandidat dan satu bentuk
Mulailah dari bentuk kegagalannya, karena itu menyingkirkan sebagian besar daftar sebelum alat apa pun dibuka. Macet yang terjadi pada ukuran tetap adalah masalah ukuran sampai terbukti sebaliknya. Macet pada titik acak adalah masalah kehilangan atau stabilitas. Kegagalan sebelum koneksi terbuka adalah masalah nama.
Kandidat keempat adalah aplikasi. Batas unggahan, batas waktu permintaan, dan plafon ukuran badan pada proksi menghasilkan kegagalan yang tampak seperti gangguan jaringan dari peramban, dan biasanya datang sebagai penolakan, bukan sebagai macet.
Catat bentuk yang teramati sebelum menguji apa pun. "Berhenti pada jumlah byte yang kira-kira sama, setiap kali, dengan terowongan menyala" adalah titik awal yang jauh lebih kuat daripada "unggahan tidak berfungsi".
Lalu jaga jalurnya tetap selama pengujian. Mengubah jalan keluar, protokol, dan server sekaligus menghasilkan hasil yang tidak dapat Anda kaitkan dengan salah satunya. Satu variabel per percobaan, dan catat.
Belah ukurannya sebelum menyentuh kebijakan
Pembeda termurah adalah probe yang mengubah satu angka. Kirim ping tanpa fragmentasi berukuran makin besar ke tujuan, unggah file yang Anda kendalikan ke layanan yang sama, lalu bandingkan di mana masing-masing 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 apakah paket berukuran penuh sama sekali melewati jalur. Pada MTU 1500 byte, muatan ICMP terbesar yang tidak terfragmentasi adalah 1472 byte, dan terowongan mengambil lebih banyak dari anggaran itu sebelum paket dalam mulai. Yang kedua memberi Anda ukuran dan durasi untuk transfer tingkat aplikasi, dan itulah angka 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 keduanya bersama. Probe yang gagal di atas ambang dan unggahan yang berhenti di dekat ambang yang sama adalah cerita yang koheren. Probe yang semuanya berhasil sementara unggahan macet pada jumlah byte yang jelas diangkut jalur menunjukkan aplikasi atau server, dan tidak ada pekerjaan MTU yang akan mengubahnya. Hasil negatif itu bernilai sama dengan hasil positif. Ia menyingkirkan cabang penyelidikan yang paling mahal.
Lalu periksa stabilitas selama transfer, karena terowongan yang memperbarui kunci di tengah unggahan besar menghasilkan kegagalan yang tampak bergantung ukuran tanpa benar-benar demikian. Pembacaan waktu aktif adalah cara termurah untuk memastikannya.
Pilih antara perbaikan dan akal-akalan
Jika bukti mengarah ke ukuran, ada dua jawaban jujur dan satu tidak jujur. Yang jujur adalah memulihkan penemuan MTU jalur dengan mengizinkan umpan balik ICMP yang diperlukan, atau membatasi ukuran segmen yang diiklankan agar rekan mengirim segmen lebih kecil. Yang tidak jujur adalah menurunkan MTU antarmuka ke nilai yang disalin dari forum dan tidak pernah memeriksa apa yang diubahnya.
Pilihannya bergantung pada apa yang Anda kendalikan. Pada jaringan yang Anda operasikan, mengizinkan pesan ICMP adalah perbaikan yang lebih bersih karena menjaga mekanisme tetap bekerja untuk setiap protokol. Pada jalur yang tidak Anda kendalikan, pembatasan adalah pilihan praktis, dan harus diterapkan secara sempit, bukan untuk seluruh server.
Jika bukti mengarah ke aplikasi, perbaiki aplikasi atau konfigurasi proksinya. Respons 413 dan koneksi menggantung adalah kegagalan berbeda, dan yang kedua biasanya batas waktu di suatu tempat dalam rantai yang mencakup proksi dengan batasnya sendiri.
Apa pun itu, simpan nilai asli dan uji ulang setelah dikembalikan. Perubahan yang bertepatan dengan transfer yang berhasil bukan bukti bahwa perubahan itulah penyebabnya, dan kemampuan membatalkannya adalah yang memisahkan diagnosis dari kebetulan.
Catat keputusannya agar bertahan hingga insiden berikutnya
Empat fakta cukup: bentuk kegagalan yang teramati, hasil probe, perubahan yang Anda buat, dan hasil uji ulang. Dengan itu, orang berikutnya dapat mengatakan apakah masalahnya sama atau masalah baru dengan gejala yang sama.
Catat juga konteks jalurnya, karena temuan MTU spesifik untuk sebuah tautan. Laptop yang berfungsi di rumah dan gagal di hotel memiliki dua jalur, dan perbaikan yang diterapkan pada salah satunya tidak mengatakan apa pun tentang yang lain.
Terakhir, tolak ringkasan bahwa "VPN merusak unggahan". Terowongan itu ada baik pada kasus yang berhasil maupun yang gagal; yang berubah adalah ukuran paket yang harus diangkut jalur, atau tempat transfer dihentikan. Menyebut mekanisme sebenarnya itulah yang membuat catatan ini berguna.