Mitos MTU pada VPN: mengapa paket Anda menyusut dan ke mana ruangnya pergi

Seseorang memberi tahu Anda bahwa VPN "kehilangan paket karena MTU", Anda menyetel terowongan ke 1400, dan transfer berfungsi lagi. Hasil itu terasa seperti diagnosis. Biasanya itu kebetulan aritmetika: Anda memilih angka yang cukup kecil untuk masuk di bawah batas yang tidak pernah Anda identifikasi, dan Anda akan bertemu batas yang sama lagi di jaringan berikutnya dengan anggaran yang berbeda.

Dua mitos menyebabkan sebagian besar hal ini. Yang pertama adalah MTU antarmuka terowongan adalah MTU jalur. Yang kedua adalah enkapsulasi memakan "satu tajuk" dan PPPoE tidak memakan apa pun yang layak dihitung. Keduanya salah dengan cara yang membuat angka yang Anda pilih tampak sembarangan padahal sebenarnya ditentukan.

Mitos satu: MTU terowongan adalah MTU jalur

Nilai yang Anda setel pada antarmuka terowongan adalah janji lokal tentang paket dalam terbesar yang akan diserahkan implementasi ke bawah. Kapasitas sebenarnya jalur adalah sifat setiap tautan antara Anda dan ujung jauh, dan dapat berubah ketika rute berubah, ketika koneksi seluler dialihkan, atau ketika lalu lintas mengambil peering lain. 1500 yang dikonfigurasi memberi tahu Anda apa yang akan dibangun host Anda, bukan apa yang akan diangkut jaringan.

Penemuan MTU jalur ada untuk menyelaraskan keduanya, dan bergantung pada umpan balik. Pada IPv4, router yang tidak dapat meneruskan paket berukuran penuh seharusnya mengirim pesan ICMP "fragmentation needed", dan pengirim menurunkan perkiraannya. Pada IPv6, padanannya adalah pesan Packet Too Big, dan router sama sekali tidak memfragmentasi dalam transit. Ketika umpan balik itu disaring, pengirim terus menghasilkan paket yang tidak dapat diangkut jalur, dan tidak ada yang memberitahunya mengapa.

Mitos dua: enkapsulasi memakan satu tajuk

Hitung lapisan luar dengan jujur. Tajuk IP luar adalah 20 byte pada IPv4 atau 40 pada IPv6. Enkapsulasi UDP untuk menembus NAT menambahkan 8. Protokol terowongan menambahkan tajuknya sendiri, vektor inisialisasi atau nonce, padding hingga batas blok atau perataan sandi, trailer, dan nilai pemeriksaan integritas. Tergantung protokol dan sandi, totalnya dengan nyaman berada di kisaran puluhan byte sebelum paket dalam dimulai.

Lalu kurangi lagi tajuk paket dalam itu sendiri. Segmen TCP di dalam terowongan membawa tajuk IP 20 byte dan tajuk TCP 20 byte miliknya sendiri, dan MSS TCP diturunkan dari MTU, bukan dari muatan nominal terowongan. Itu sebabnya ping dengan muatan lebih kecil bisa berhasil sementara transfer file tersendat: alat-alat itu menguji hal yang berbeda, dan hanya satu di antaranya melatih segmen TCP berukuran penuh.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

Perintah pertama melaporkan MTU terowongan yang dikonfigurasi. Kedua probe mengirim muatan 1472 byte, yang dengan 28 byte tajuk IPv4 dan ICMP adalah paket 1500 byte, lalu yang lebih kecil. Jika probe besar gagal total dan yang kecil berhasil, Anda punya kerusakan yang bergantung ukuran, bukan masalah perutean umum.

Mitos tiga: PPPoE masih memberi Anda 1500 bersih

Tautan akses PPPoE konvensional tidak mengangkut paket IP 1500 byte. Tajuk PPPoE plus bidang protokol PPP memakan 8 byte di dalam bingkai Ethernet, yang menyisakan 1492 untuk paket IP. Itu batas tradisional yang dijelaskan dalam RFC 2516. Jika Anda menjalankan VPN di atas tautan seperti itu, biaya tambahan terowongan berasal dari 1492 itu, bukan dari 1500.

RFC 4638 mendefinisikan cara menegosiasikan muatan PPP yang lebih besar ketika konsentrator akses dan peralatan pelanggan sama-sama mendukungnya, karena itu "koneksi ini memakai PPPoE" saja tidak membuktikan angka tertentu. Pengaturan lokal tidak dapat memaksa perangkat perantara menerima paket yang tidak pernah dikonfigurasi untuknya, jadi pertanyaan yang berguna adalah apa yang sebenarnya dinegosiasikan tautan, bukan apa yang dikatakan label.

Mengapa kegagalan tampak selektif

Permintaan kecil berhasil dan transfer besar tersendat adalah tanda khas lubang hitam MTU jalur. Jabat tangan, kueri DNS, dan panggilan API semuanya muat; transfer massal menghasilkan segmen berukuran penuh yang mati di satu tautan, dan pesan ICMP yang seharusnya melaporkan masalah tidak pernah tiba. Koneksi tampak baik-baik saja dan unduhan menggantung, yang membuat orang memeriksa server alih-alih jalur.

Kesalahan kedua yang terkait adalah mencampur tiga angka: MTU antarmuka, MSS TCP, dan pengaturan fragmentasi atau padding protokol itu sendiri. Penjepitan MSS pada router menulis ulang MSS yang diiklankan agar pengirim membangun segmen lebih kecil; itu tidak mengubah MTU terowongan, dan tidak membantu lalu lintas UDP. Memberi ketiganya angka yang sama karena tampak terkait adalah cara perubahan bermaksud baik merusak penyiapan yang berfungsi.

Apa yang diubah, dan dalam urutan apa

Mulailah dengan bukti. Pastikan dengan probe di atas bahwa kerusakan bergantung ukuran, lalu temukan ukuran terkecil yang lolos dan terbesar yang gagal. Periksa MTU sebenarnya dari tautan akses sebelum menyalahkan terowongan; tautan PPPoE membatasi anggaran sebelum VPN Anda menyentuhnya. Catat nilai aslinya agar perubahan dapat dibalik.

Lalu terapkan penyesuaian terkecil yang didokumentasikan klien. Banyak klien menawarkan MTU terowongan plus opsi perbaikan MSS, dan opsi MSS sering menjadi tuas yang lebih baik untuk TCP karena mencapai pengirim tanpa mengecilkan setiap paket. Uji ulang tujuan yang sama dan transfer yang sama, dan catat angka yang Anda tetapkan. Nilai terowongan yang berfungsi di satu jaringan akses bukan konstanta universal, dan situs berikutnya akan punya anggarannya sendiri.