Frame jumbo tidak membuat jalur VPN membawa paket 9000 byte

Anda mengaktifkan frame 9000 byte di LAN dan berharap VPN menjadi lebih cepat. VPN malah melambat, atau berhenti melewatkan transfer besar sama sekali. Frame jumbo adalah kesepakatan tautan lokal; frame itu tidak memperbesar jalur yang dilewati terowongan.

Anggaran yang bisa dipakai ditentukan oleh batas terkecil di rute, termasuk enkapsulasi yang ditambahkan terowongan.

Apa yang sebenarnya diubah frame jumbo

MTU adalah sifat satu antarmuka. Menaikkannya di server dan switch-nya berarti keduanya bisa bertukar frame lebih besar tanpa fragmentasi. Itu tidak mengatakan apa pun tentang router di balik switch, tentang ISP, atau tentang sisi jauh sebuah terowongan. Perangkat itu punya batasnya sendiri, dan paket yang melebihi salah satunya dibuang atau difragmentasi menurut aturan yang tidak Anda tetapkan.

Kesepakatan lokal, konsekuensi global. Itulah seluruh kebingungannya.

Pajak enkapsulasi

Terowongan membungkus paket Anda di dalam paket lain. WireGuard di atas IPv4 UDP menambahkan sekitar 60 byte overhead; mode UDP OpenVPN berada di kisaran yang sama, dan IPsec bervariasi menurut mode dan algoritme. Byte itu diambil dari anggaran jalur luar, bukan dari udara.

Jadi tautan luar 1500 byte tidak bisa membawa paket dalam 1500 byte setelah header terowongan ditambahkan.

Perhitungannya layak dilakukan sekali. Pada jalur 1500 byte, antarmuka WireGuard menginginkan MTU sekitar 1420 agar paket terenkapsulasi muat. Setel antarmuka dalam ke 9000 dan setiap paket besar akan butuh fragmentasi yang tidak bisa dilakukan terowongan, atau akan dibuang.

Temukan tautan terkecil di jalur

Telusuri rute dan temukan MTU terendah. LAN biasanya 1500 atau 9000, WAN biasanya 1500, dan tautan seluler atau PPP bisa lebih rendah lagi. Lalu kurangi overhead terowongan. Jika hasilnya lebih kecil dari MTU antarmuka dalam, itulah jawaban Anda. Penemuan MTU jalur dapat menemukan ini secara otomatis, tetapi hanya bila pesan ICMP yang menjadi dasarnya diizinkan lewat.

ICMP yang tersaring adalah alasan klasik transfer besar menggantung sementara permintaan kecil berjalan baik.

Uji ketergantungan ukuran tanpa memperlebar perubahan

Gunakan transfer perwakilan dan simpan nilai asli agar bisa dikembalikan. ping -M do -s 1472 menguji paket 1500 byte dengan bit DF disetel; kecilkan ukurannya sampai lolos. Jika hanya paket besar yang gagal, Anda punya masalah ukuran, bukan masalah rute.

Waspadai offload di sisi host saat membaca tangkapan. Offload segmentasi dapat menampilkan frame jauh lebih besar daripada yang benar-benar melintasi kabel, sehingga jalur yang berfungsi tampak rusak dan yang rusak tampak baik.

Kapan MTU besar adalah desain yang tepat

Jaringan privat yang terkendali dapat secara sah menjalankan frame lebih besar dari ujung ke ujung, asalkan setiap perangkat di jalur setuju dan overhead terowongan diperhitungkan. Itu desain terkoordinasi dengan nilai terdokumentasi per tautan, bukan satu angka besar yang diketik ke klien.

Untuk keluar publik biasa, anggap 1500 atau kurang dan biarkan terowongan memilih MTU dalam yang aman. RFC 8201 mencakup penemuan MTU jalur untuk kasus IPv6 dan merupakan rujukan berguna tentang bagaimana umpan balik seharusnya bekerja.