Lubang hitam MTU: mengapa permintaan kecil berfungsi tetapi muat naik tersekat

Halaman dimuatkan, panggilan API kecil kembali, dan kemudian muat naik fail tergantung sehingga klien menyerah. Tiada apa pun dalam log pelayan yang menjelaskannya, kerana paket digugurkan di tengah laluan tanpa jawapan berguna dihantar balik. Corak itu ialah lubang hitam MTU: pautan yang lebih sempit daripada andaian penghantar, ditambah penolakan senyap untuk mengatakannya. Saiz yang gagal boleh diulang, dan itulah yang menjadikannya boleh didiagnosis.

Apa yang menjadikan lubang itu hitam

Setiap pautan mempunyai unit penghantaran maksimum, dan paket yang lebih besar daripada had hop seterusnya mesti difragmentasi atau ditolak dengan mesej ICMP yang menyatakannya. Penemuan MTU laluan bergantung pada mesej itu tiba dan dihormati. Menapis atau mengabaikannya membiarkan penghantar mengulang paket yang tidak akan pernah muat.

Pengekapsulan menjadikan ini biasa di sekeliling VPN, kerana terowong menambah pengepala luar pada paket yang sudah bersaiz untuk pautan fizikal. Paket dalam sah pada 1500 bait dan yang dikekapsulasi tidak, jadi ia mati di sempadan sementara paket kecil lolos. Jabat tangan selesai dan halaman log masuk yang berfungsi hanya membuktikan paket kecil berfungsi. Paket terbesar yang cuba dihantar oleh aplikasi ialah yang penting.

Cari saiz di mana ia patah

Cari secara binari saiz muatan dengan ujian tanpa fragmentasi, dari hos di satu sisi terowong ke hos di sisi lain. Muatan terbesar yang berjaya ialah MTU laluan yang boleh digunakan tolak overhed pengepala.

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 berjaya pada laluan Ethernet bersih 1500 bait apabila 28 bait pengepala IPv4 dan ICMP ditambah. Apabila ujian yang sama hanya berjaya pada muatan lebih kecil selepas terowong dinaikkan, perbezaannya ialah overhed pengekapsulan, dan sempadan terowong ialah tempat mesej penolakan sepatutnya dijana. Catat kedua-dua nombor, sebelum dan selepas bersambung, kerana pasangan itu ialah buktinya. Ulang ujian untuk IPv6 apabila aplikasi menggunakannya, kerana pengepala lebih besar dan ambang kegagalan bergerak.

Baca bukti sebelum menyalahkan terowong

Ralat aplikasi jauh, kesesakan dan kehilangan biasa juga menyekat muat naik, jadi satu pemindahan gagal tidak mengenal pasti lubang hitam. Yang memisahkan mereka ialah hubungan saiz: kejayaan berulang pada 1200 bait dan tersekat berulang pada 1400 bait, dalam arah yang sama, melalui titik akhir yang sama.

Tangkapan di kedua-dua hujung menunjukkan paket besar keluar dan tidak pernah tiba, tanpa penolakan di antaranya. Itulah masanya untuk melihat peranti sempadan dan bukannya pelayan, yang menjawab setiap permintaan yang benar-benar diterimanya. Kesesakan juga tersekat, tetapi ia menyekat saiz berbeza pada masa berbeza, dan itu tandatangan yang berbeza.

Semak pembaikan pada kedua-dua pengangkutan

Pembaikan yang disokong ialah membiarkan sempadan melaporkan had sebenar, atau mengapit saiz segmen maksimum TCP di situ supaya tiada segmen terlalu besar dicuba. Menurunkan setiap MTU pada rangkaian, atau mematikan firewall, menyembunyikan gejala dan meninggalkan konfigurasi yang tiada siapa dapat menaakul kemudian.

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

Sahkan dengan ujian saiz yang sama, kemudian dengan aplikasi yang gagal, dan periksa protokol kedua, kerana aplikasi UDP tidak pernah menerima pembetulan saiz segmen TCP. Simpan nilai asal dalam tiket, kerana pembaikan yang tidak boleh diterbalikkan ialah masalah kedua yang menunggu berlaku. Jika ujian saiz lulus dan muat naik masih tersekat, lubang hitam bukan puncanya, dan siasatan harus diteruskan dan bukannya meluaskan perubahan.