Lubang hitam MTU: mengapa permintaan kecil berhasil tetapi unggahan macet

Sebuah halaman dimuat, panggilan API kecil kembali, lalu unggahan berkas menggantung sampai klien menyerah. Tidak ada apa pun di log server yang menjelaskannya, karena paket dibuang di tengah jalur tanpa jawaban berguna dikirim balik. Pola itu adalah lubang hitam MTU: tautan yang lebih sempit daripada perkiraan pengirim, ditambah penolakan diam-diam untuk mengatakannya. Ukuran yang gagal bersifat berulang, dan itulah yang membuatnya bisa didiagnosis.

Apa yang membuat lubangnya hitam

Setiap tautan memiliki unit transmisi maksimum, dan paket yang lebih besar dari batas hop berikutnya harus difragmentasi atau ditolak dengan pesan ICMP yang menyatakannya. Penemuan MTU jalur bergantung pada pesan itu tiba dan dihormati. Memfilternya atau mengabaikannya membuat pengirim mengulangi paket yang tidak akan pernah muat.

Enkapsulasi membuat ini umum di sekitar VPN, karena terowongan menambahkan tajuk luar ke paket yang sudah berukuran untuk tautan fisik. Paket dalam sah pada 1500 bait dan yang terenkapsulasi tidak, jadi ia mati di batas sementara paket kecil lolos. Handshake yang selesai dan halaman masuk yang berfungsi hanya membuktikan bahwa paket kecil berfungsi. Paket terbesar yang coba dikirim aplikasi adalah yang penting.

Temukan ukuran tempat ia putus

Cari secara biner ukuran muatan dengan uji tanpa fragmentasi, dari host di satu sisi terowongan ke host di sisi lain. Muatan terbesar yang berhasil adalah MTU jalur yang dapat Anda pakai dikurangi beban tajuk.

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

Muatan 1472 bait berhasil pada jalur Ethernet bersih 1500 bait setelah 28 bait tajuk IPv4 dan ICMP ditambahkan. Ketika uji yang sama hanya berhasil pada muatan lebih kecil setelah terowongan menyala, selisihnya adalah beban enkapsulasi, dan batas terowongan adalah tempat pesan penolakan seharusnya dihasilkan. Catat kedua angka, sebelum dan sesudah terhubung, karena pasangan itu adalah buktinya. Ulangi uji untuk IPv6 ketika aplikasi memakainya, karena tajuknya lebih besar dan ambang kegagalan bergeser.

Baca buktinya sebelum menyalahkan terowongan

Kesalahan aplikasi jarak jauh, kemacetan dan kehilangan biasa juga membuat unggahan macet, jadi satu transfer gagal tidak mengidentifikasi lubang hitam. Yang memisahkan keduanya adalah hubungan ukuran: keberhasilan berulang pada 1200 bait dan kemacetan berulang pada 1400 bait, pada arah yang sama, melalui titik akhir yang sama.

Tangkapan di kedua ujung menunjukkan paket besar keluar dan tidak pernah tiba, tanpa penolakan di antaranya. Itulah saatnya melihat perangkat batas alih-alih server, yang menjawab setiap permintaan yang benar-benar diterimanya. Kemacetan juga macet, tetapi ia membuat ukuran berbeda macet pada waktu berbeda, dan itu tanda tangan yang berbeda.

Periksa perbaikan pada kedua transport

Perbaikan yang didukung adalah membiarkan batas melaporkan batas sebenarnya, atau menjepit ukuran segmen maksimum TCP di sana agar tidak ada segmen kebesaran yang dicoba. Menurunkan setiap MTU di jaringan, atau mematikan firewall, menyembunyikan gejala dan meninggalkan konfigurasi yang tidak bisa dipikirkan siapa pun nanti.

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

Verifikasi dengan uji ukuran yang sama, lalu dengan aplikasi yang gagal, dan periksa protokol kedua, karena aplikasi UDP tidak pernah menerima koreksi ukuran segmen TCP. Simpan nilai asli di tiket, karena perbaikan yang tidak dapat dibalik adalah masalah kedua yang menunggu terjadi. Jika uji ukuran lolos dan unggahan masih macet, lubang hitam bukan penyebabnya, dan penyelidikan harus berlanjut alih-alih memperluas perubahan.