Penemuan MTU laluan melalui VPN: saiz dan jurang ICMP
Tunel mengecilkan paket yang boleh dibawa laluan, dan penemuan hanya berfungsi jika maklum balas tiba. Ukur, uji dan sahkan laluan dan bukan meneka.
Tunel melengkapkan jabat tangan, permintaan kecil kembali, dan pemindahan besar pertama tersekat. Corak ini menunjuk kepada MTU laluan jauh sebelum menunjuk kepada daya pengeluaran. Setiap pautan di sepanjang laluan mengehadkan saiz paket, dan enkapsulasi membelanjakan sebahagian elaun itu pada pengepala luar, jadi paket dalam mesti lebih kecil daripada yang dicadangkan laluan mentah. Kegagalan itu senyap, dan itulah yang menjadikannya mahal untuk didiagnosis.
Apa yang sebenarnya diukur oleh MTU laluan
MTU laluan ialah MTU pautan terkecil pada laluan antara dua hos, bukan MTU yang dicetak pada antara muka tempatan anda. Nilai tempatan ialah titik permulaan anggaran, dan laluan menentukan di mana ia mesti berakhir. Inilah sebabnya terowong yang sama boleh berfungsi pada satu rangkaian akses dan tersekat pada yang lain: laluan berubah, bukan konfigurasi. Mengukur sekali dan menganggap di mana-mana ialah kesilapan yang memastikan masalah ini kekal hidup.
Untuk terowong, nombor yang penting ialah MTU dalam, iaitu elaun laluan luar tolak apa yang digunakan oleh enkapsulasi. WireGuard menambah pengepala IP luar dan pengepala UDP; pengangkutan lain menambah milik mereka sendiri. Tetapkan saiz dalam terlalu tinggi dan setiap paket saiz penuh memerlukan pemecahan yang mungkin tidak pernah berlaku.
Mengapa terowong mengecilkan paket yang boleh digunakan
Jika antara muka terowong mengekalkan MTU pautan fizikal, setiap paket besar bergantung pada seseorang di hilir yang sanggup memecahkannya. IPv4 membenarkannya pada dasarnya, tetapi penghala yang diberitahu supaya tidak memecahkan akan mengembalikan ralat. Penghala IPv6 tidak pernah memecahkan dalam transit, jadi tetapan yang sama berkelakuan berbeza mengikut keluarga alamat. Walau apa pun, penghantar tidak belajar apa-apa sehingga sesuatu melaporkan balik.
Akibat praktikalnya ialah saiz yang muat dalam jabat tangan tetapi tidak dalam muatan. TLS ClientHello atau pertanyaan DNS cukup kecil untuk melintasi laluan yang mengecil tanpa disentuh, manakala pemindahan pukal tidak. Oleh itu gejala berkumpul di sekitar operasi tertentu dan bukan hos tertentu.
Penemuan hanya berfungsi apabila maklum balas tiba
Penemuan IPv4 bergantung pada bit don't-fragment: penghala yang tidak dapat meneruskan paket mengembalikan ICMP fragmentation-needed dengan MTU hop seterusnya, dan penghantar menurunkan anggarannya. IPv6 menggunakan mesej Packet Too Big sebaliknya, kerana penghala tidak memecahkan dalam transit. Kedua-dua mekanisme menganggap mesej itu menemui jalan kembali kepada penghantar, melalui terowong dan melepasi mana-mana tembok api di laluan balik. Apabila andaian itu gagal, penghantar terus mencuba saiz yang tidak dapat dibawa oleh laluan.
Tembok api yang membenarkan echo request dan echo reply belum tentu membenarkan jenis ralat itu. ICMP ialah sebuah keluarga, dan ahli yang penting di sini ialah ralat, bukan pasangan gema. Semak dasar trafik kawalan di kedua-dua hujung terowong dan pada laluan di antaranya, dan ikuti panduan platform yang disokong dan bukan membenarkan setiap jenis ICMP di mana-mana.
Penapisan yang sama boleh berada di dalam terowong. Jika laluan dalam menggugurkan ralat tetapi laluan luar membawanya, penghantar mungkin menyesuaikan diri dengan had yang tidak pernah benar-benar dilihat oleh trafik yang dienkapsulasi.
Uji laluan dan bukan meneka nombor
Kekalkan destinasi, rangkaian akses dan terowong tetap, kemudian ubah hanya saiz paket. Ujian don't-fragment yang gagal dengan petunjuk MTU memberi anda had hop seterusnya; ulangi sehingga satu saiz lulus, dan rekod kedua-dua saiz dan keluarga alamat.
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 muat tidak membuktikan segmen saiz penuh aplikasi sebenar muat, jadi ulangi ujian dengan pemindahan yang benar-benar gagal. Bandingkan ujian terbesar yang berjaya dengan MTU terowong yang anda konfigurasikan, dan simpan kedua-dua nombor secara berasingan dalam nota anda. Jika ia berbeza kira-kira satu pengepala, anda telah menemui overhed enkapsulasi dan bukan kerosakan.
PLPMTUD, yang diterangkan dalam RFC 4821, menguji ke atas dan menggunakan pengakuan pengangkutan dan bukan mempercayai ralat yang dihantar. Ia membantu pada laluan yang menapis ICMP, tetapi sokongan berbeza mengikut timbunan dan aplikasi. Aliran TCP mungkin pulih sendiri manakala aplikasi UDP dengan saiz datagram tetap terus gagal.
Pilih nilai dan rekod alasannya
Menurunkan MTU terowong ialah diagnosis dan pembaikan yang sah setelah anda mengetahui laluan. Ia bukan pengganti mengetahui laluan mana dan mekanisme maklum balas mana yang terlibat, kerana nilai yang ditala untuk pautan mudah alih akan terlalu kecil tanpa keperluan pada sambungan gentian. Rekod saiz yang dipilih, ujian yang membenarkannya dan langkah pengunduran.
Mekanisme IPv4 diterangkan dalam RFC 1191 dan panduan pengpaketan IPv6 dalam RFC 8201; menyebut kedua-duanya menghalang jurutera seterusnya daripada memperoleh semula andaian itu. Jika pemindahan masih tersekat pada saiz yang anda pilih, berhenti menurunkan nombor itu dan lihat lapisan seterusnya. Laluan yang gagal pada setiap saiz bukan masalah MTU.