OpenVPN mssfix: mengapa satu klien macet saat transfer besar

Satu laptop macet saat mengunggah melalui terowongan sementara setiap perangkat lain di server yang sama terus bekerja. Pola itu menunjuk ke satu jalur, bukan ke konfigurasi server, dan itulah pintu masuk biasa ke pertanyaan mssfix. Opsi ini dapat membantu, tetapi hanya untuk koneksi TCP yang benar-benar ditulis ulangnya. Mengetahui jangkauannya mencegah Anda mengubah server yang berfungsi demi menyelamatkan satu klien.

Apa yang ditulis ulang opsi ini

mssfix menyunting ukuran segmen maksimum yang diumumkan dalam jabat tangan TCP yang melewati terowongan, sehingga sisi pengirim memilih segmen yang muat dalam anggaran terenkapsulasi. Opsi ini bekerja pada jabat tangan, yang berarti koneksi yang dibuka sebelum perubahan tetap memakai nilai yang dinegosiasikan.

Opsi ini tidak mengecilkan datagram UDP dan tidak menetapkan MTU terowongan. Dua masalah berbeda menghasilkan gejala yang sama: pengirim TCP yang mengabaikan batas jalur, dan jalur yang diam-diam membuang paket besar pada ukuran apa pun. mssfix menangani yang pertama dan tidak melakukan apa pun untuk yang kedua.

Perbedaan itu menjelaskan eksperimen yang mengecewakan. Menetapkan nilai lebih kecil pada jalur berlubang hitam mengubah ukuran segmen tetapi bukan pembuangan yang menyusul, jadi transfer gagal di titik lain.

Cakupannya adalah TCP di dalam terowongan

Hanya lalu lintas TCP yang ditulis ulang. Sesi QUIC, gim, atau aplikasi yang mengirim datagram UDP besar akan mempertahankan ukuran paketnya sendiri, dan jika transfer itulah yang macet, perbaikannya lebih tepat berada di MTU terowongan atau jalur. Baca protokol mana yang dipakai transfer yang gagal sebelum meraih opsi TCP, karena lapisan yang salah punya perbaikannya sendiri.

Arah juga penting. Pengaturan klien memengaruhi lalu lintas yang dikirim klien itu ke terowongan, sedangkan server mencakup aliran yang diteruskannya ke arah klien. Jika hanya unduhan masuk yang macet, nilai di sisi klien bukan seluruh cerita.

Angka dan kata kunci tidak portabel

Versi komunitas OpenVPN 2.6 menerima kata kunci opsional setelah nilai. Dengan mtu, angka itu menjelaskan ukuran paket luar termasuk header IP dan UDP; tanpanya, argumen mengikuti konvensi penghitungan yang berbeda. Karena itu, baris yang disalin antarversi tidak menjelaskan anggaran paket yang sama. Periksa halaman manual yang disertakan dengan build yang benar-benar Anda jalankan, bukan tutorial untuk rilis lain.

Sintaksnya terlihat seperti ini:

mssfix 1400 mtu

Perlakukan 1400 sebagai pengganti, bukan rekomendasi untuk jalur Anda. Turunkan nilainya dari jalur yang diukur dan enkapsulasi yang benar-benar dipakai, dan ingat bahwa klien pada versi lama atau implementasi lain mungkin menolak atau menafsirkan ulang kata kunci itu.

Pastikan dulu pada satu klien itu

Ukur jalur dari mesin yang gagal sebelum mengubah apa pun. Muatan yang dapat dibawa jalur tanpa fragmentasi adalah angka yang Anda cari:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

Probe pertama muat dalam paket 1500 byte setelah 28 byte header ditambahkan. Jika gagal dengan kesalahan fragmentasi dan yang lebih kecil berhasil, ukuran yang dapat dipakai ada di antara keduanya, dan biaya tambahan terowongan dipotong dari atas.

Lalu ulangi transfer yang macet, pada koneksi baru, dan bandingkan. Jika klien tunggal membaik sementara yang lain tidak tersentuh, Anda telah menemukan cakupan masalahnya. Jika semua klien macet, nilai di sisi server adalah yang perlu ditinjau. Tidak ada dari kedua hasil itu yang membenarkan perubahan pada perangkat keras yang tidak pernah berada di jalur yang gagal.