Penemuan MTU jalur melalui VPN: ukuran dan celah ICMP

Sebuah tunel menyelesaikan jabat tangan, permintaan kecil kembali, dan transfer besar pertama macet. Pola itu menunjuk ke MTU jalur jauh sebelum menunjuk ke throughput. Setiap tautan di sepanjang rute membatasi ukuran paket, dan enkapsulasi menghabiskan sebagian jatah itu untuk header luar, sehingga paket dalam harus lebih kecil daripada yang disiratkan jalur mentah. Kegagalannya senyap, dan itulah yang membuatnya mahal untuk didiagnosis.

Apa yang sebenarnya diukur MTU jalur

MTU jalur adalah MTU tautan terkecil pada rute antara dua host, bukan MTU yang tercetak pada antarmuka lokal Anda. Nilai lokal adalah titik awal perkiraan, dan jalur yang menentukan di mana perkiraan itu harus berakhir. Inilah sebabnya tunel yang identik dapat bekerja pada satu jaringan akses dan macet pada jaringan lain: rutenya berubah, bukan konfigurasinya. Mengukur sekali lalu mengasumsikan di mana-mana adalah kesalahan yang membuat masalah ini tetap hidup.

Untuk tunel, angka yang penting adalah MTU dalam, yaitu jatah jalur luar dikurangi apa yang dihabiskan enkapsulasi. WireGuard menambahkan header IP luar dan header UDP; transport lain menambahkan miliknya sendiri. Setel ukuran dalam terlalu tinggi dan setiap paket berukuran penuh membutuhkan fragmentasi yang mungkin tidak pernah terjadi.

Mengapa tunel memperkecil paket yang dapat dipakai

Jika antarmuka tunel mempertahankan MTU tautan fisik, setiap paket besar bergantung pada pihak di hilir yang bersedia memfragmentasikannya. IPv4 mengizinkannya secara prinsip, tetapi router yang diberi tahu untuk tidak memfragmentasi justru mengembalikan kesalahan. Router IPv6 tidak pernah memfragmentasi dalam transit sama sekali, sehingga setelan yang sama berperilaku berbeda menurut keluarga alamat. Bagaimanapun juga, pengirim tidak belajar apa pun sampai ada yang melaporkan balik.

Konsekuensi praktisnya adalah ukuran yang cocok untuk jabat tangan tetapi tidak untuk muatan. TLS ClientHello atau kueri DNS cukup kecil untuk melewati jalur yang menyusut tanpa tersentuh, sedangkan transfer massal tidak. Karena itu gejalanya mengelompok di sekitar operasi tertentu, bukan host tertentu.

Penemuan hanya bekerja ketika umpan balik tiba

Penemuan IPv4 bergantung pada bit don't-fragment: router yang tidak dapat meneruskan paket mengembalikan ICMP fragmentation-needed dengan MTU hop berikutnya, dan pengirim menurunkan perkiraannya. IPv6 menggunakan pesan Packet Too Big, karena router tidak memfragmentasi dalam transit. Kedua mekanisme mengasumsikan pesan menemukan jalan kembali ke pengirim, melewati tunel dan melewati firewall mana pun di jalur balik. Ketika asumsi itu gagal, pengirim terus mencoba ulang ukuran yang tidak dapat dibawa jalur.

Firewall yang mengizinkan echo request dan echo reply belum tentu mengizinkan jenis kesalahan itu. ICMP adalah sebuah keluarga, dan anggota yang penting di sini adalah kesalahannya, bukan pasangan echo. Periksa kebijakan lalu lintas kontrol di kedua ujung tunel dan pada jalur di antaranya, dan ikuti panduan platform yang didukung alih-alih mengizinkan setiap jenis ICMP di mana-mana.

Pemfilteran yang sama dapat berada di dalam tunel. Jika jalur dalam menjatuhkan kesalahan tetapi jalur luar membawanya, pengirim dapat menyesuaikan diri dengan batas yang tidak pernah benar-benar dilihat lalu lintas yang dienkapsulasi.

Uji jalur alih-alih menebak angka

Pertahankan tujuan, jaringan akses, dan tunel tetap, lalu ubah hanya ukuran paket. Uji don't-fragment yang gagal dengan petunjuk MTU memberi Anda batas hop berikutnya; ulangi sampai ada ukuran yang lolos, dan catat ukuran serta keluarga alamatnya.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Ping yang cocok tidak membuktikan segmen berukuran penuh aplikasi nyata cocok, jadi ulangi pengujian dengan transfer yang benar-benar gagal. Bandingkan uji terbesar yang berhasil dengan MTU tunel yang Anda konfigurasi, dan simpan kedua angka secara terpisah dalam catatan Anda. Jika keduanya berbeda sekitar satu header, Anda telah menemukan overhead enkapsulasi, bukan kesalahan.

PLPMTUD, yang dijelaskan dalam RFC 4821, menguji ke atas dan menggunakan pengakuan transport alih-alih mempercayai kesalahan yang dikirimkan. Ini membantu pada jalur yang memfilter ICMP, tetapi dukungannya berbeda-beda menurut stack dan aplikasi. Aliran TCP dapat pulih sendiri sementara aplikasi UDP dengan ukuran datagram tetap terus gagal.

Pilih nilai dan catat alasannya

Menurunkan MTU tunel adalah diagnostik sekaligus perbaikan yang sah setelah Anda mengetahui jalurnya. Itu bukan pengganti mengetahui jalur mana dan mekanisme umpan balik mana yang terlibat, karena nilai yang disetel untuk tautan seluler akan terlalu kecil tanpa perlu pada sambungan serat. Catat ukuran yang dipilih, uji yang membenarkannya, dan langkah pengembalian.

Mekanisme IPv4 dijelaskan dalam RFC 1191 dan panduan paketisasi IPv6 dalam RFC 8201; menyebutkan keduanya mencegah insinyur berikutnya menurunkan ulang asumsi itu. Jika transfer masih macet pada ukuran yang Anda pilih, berhenti menurunkan angkanya dan lihat lapisan berikutnya. Jalur yang gagal pada semua ukuran bukan masalah MTU.