Bingkai jumbo tidak menjadikan laluan VPN membawa paket 9000 bait

Anda mengaktifkan bingkai 9000 bait pada LAN dan menjangka VPN akan menjadi lebih pantas. Ia menjadi lebih perlahan, atau berhenti melepasi pemindahan besar sama sekali. Bingkai jumbo ialah persetujuan pautan setempat; ia tidak meluaskan laluan yang dilalui terowong.

Bajet yang boleh digunakan ditentukan oleh sempadan terkecil pada laluan, termasuk enkapsulasi yang ditambah oleh terowong.

Apa yang sebenarnya diubah oleh bingkai jumbo

MTU ialah sifat satu antara muka. Menaikkannya pada pelayan dan suisnya bermakna kedua-duanya boleh bertukar bingkai lebih besar tanpa pemecahan. Ia tidak berkata apa-apa tentang penghala di sebalik suis, pembekal perkhidmatan, atau sebelah sana terowong. Peranti itu mempunyai hadnya sendiri, dan paket yang melebihi salah satunya digugurkan atau dipecahkan mengikut peraturan yang anda tidak tetapkan.

Persetujuan setempat, akibat global. Itulah keseluruhan kekeliruan.

Cukai enkapsulasi

Terowong membalut paket anda di dalam paket lain. WireGuard melalui IPv4 UDP menambah kira-kira 60 bait overhed; mod UDP OpenVPN berada dalam julat yang sama, dan IPsec berbeza mengikut mod dan algoritma. Bait itu datang daripada bajet laluan luar, bukan entah dari mana.

Jadi pautan luar 1500 bait tidak boleh membawa paket dalaman 1500 bait apabila pengepala terowong ditambah.

Aritmetik itu wajar dilakukan sekali. Pada laluan 1500 bait, antara muka WireGuard mahukan MTU sekitar 1420 supaya paket terenkapsulasi muat. Tetapkan antara muka dalaman kepada 9000 dan setiap paket besar memerlukan pemecahan yang terowong tidak dapat lakukan, atau akan digugurkan.

Cari pautan terkecil pada laluan

Jelajah laluan dan cari MTU paling rendah. LAN biasanya 1500 atau 9000, WAN biasanya 1500, dan pautan mudah alih atau PPP boleh jadi lebih rendah lagi. Kemudian tolak overhed terowong. Jika hasilnya lebih kecil daripada MTU antara muka dalaman, itulah jawapan anda. Penemuan MTU laluan boleh menemuinya secara automatik, tetapi hanya apabila mesej ICMP yang menjadi asasnya dibenarkan lalu.

ICMP yang ditapis ialah sebab klasik pemindahan besar tergantung manakala permintaan kecil berjalan baik.

Uji kebergantungan saiz tanpa meluaskan perubahan

Gunakan pemindahan yang mewakili dan simpan nilai asal supaya anda boleh meletakkannya semula. ping -M do -s 1472 menguji paket 1500 bait dengan bit DF ditetapkan; kecilkan saiz sehingga ia lulus. Jika hanya paket besar gagal, anda mempunyai masalah saiz dan bukan masalah penghalaan.

Berhati-hati dengan offload di sebelah hos semasa membaca tangkapan. Offload pembahagian boleh menunjukkan bingkai jauh lebih besar daripada yang benar-benar melintasi wayar, sehingga laluan yang berfungsi kelihatan rosak dan yang rosak kelihatan baik.

Bila MTU besar ialah reka bentuk yang betul

Rangkaian peribadi terkawal boleh menjalankan bingkai lebih besar dari hujung ke hujung secara sah, dengan syarat setiap peranti pada laluan bersetuju dan overhed terowong diambil kira. Itu reka bentuk terkoordinasi dengan nilai terdokumentasi bagi setiap pautan, bukan satu nombor besar yang ditaip ke dalam klien.

Untuk keluar awam biasa, anggap 1500 atau kurang dan biarkan terowong memilih MTU dalaman yang selamat. RFC 8201 merangkumi penemuan MTU laluan untuk kes IPv6 dan merupakan rujukan berguna tentang cara maklum balas sepatutnya berfungsi.