Membawa paket dalam 1,500 byte yang tetap melalui VPN

Anda punya persyaratan yang tidak bisa ditawar: sisi jauh harus menerima paket IP 1,500 byte yang sama dengan yang dikirim pengirim, termasuk header-nya. Terowongan tidak dapat membungkus paket itu beserta framing-nya sendiri di dalam paket IP 1,500 byte kedua, jadi ada sesuatu dalam desain yang harus mengalah. Urutan di bawah ini yang saya pakai dalam jendela perubahan: tulis anggaran byte, buktikan apa yang benar-benar dapat diangkut jaringan dasar, lalu pilih tepat satu mekanisme pengangkutan dan konfirmasi paket dalam di sisi jauh.

Tulis anggaran byte sebelum menyunting profil

Enkapsulasi menambah byte pada beberapa lapisan, dan totalnya adalah sifat profil Anda, bukan konstanta yang bisa dicari. Keluarga alamat, pilihan cipher, protokol transport, dan opsi kompresi atau framing apa pun menggeser angka itu, karena itu pengurangan yang disalin dari penerapan lain tidak berguna sebagai anggaran. Mulailah dari persyaratan dalam, tambahkan overhead per paket yang terukur dari konfigurasi Anda sendiri, dan tulis ukuran luar yang dihasilkan pada tiket perubahan sebelum siapa pun menyunting berkas.

Dua angka menentukan desain: paket luar terbesar yang diangkut jalur tanpa fragmentasi, dan byte tambahan yang dibutuhkan enkapsulasi Anda. Ketika yang pertama lebih kecil dari yang kedua ditambah 1,500, salah satunya harus berubah. Pilihannya lalu sempit, bukan kreatif, karena itu saya menulis kedua angka sebelum membahas opsi. Tidak ada apa pun di lapisan terowongan yang memampatkan byte itu, dan tidak ada satu bilangan MTU pun yang menghapus persyaratan yang Anda terima.

Uji jaringan dasar dengan ping tanpa fragmentasi

Ukur jalur alih-alih memercayai MTU antarmuka, karena tautan terkecil di jalur luar itulah yang penting. Di Linux, -M do menyetel bit larangan fragmentasi dan -s mengambil muatan ICMP, sehingga bingkai 1,500 byte menjawab pada 1,472 byte muatan setelah header IP 20 byte dan header ICMP 8 byte dikurangi. Naikkan muatan sampai uji gagal, lalu lompat ke ukuran jumbo untuk melihat apakah jalur mengangkutnya sama sekali.

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

Jalur yang lolos 1,472 dan gagal pada 8,972 tidak dapat mengangkut paket dalam 1,500 byte ditambah overhead dalam satu paket luar. Itulah jawaban yang Anda butuhkan sebelum membuka konfigurasi VPN. Ini juga menentukan bagian mana dari dua bagian berikutnya yang berlaku bagi Anda, jadi simpan kedua hasil uji di samping tiket. Menebak di sini memakan satu jendela pemeliharaan, karena terowongan yang melaporkan dirinya aktif tidak mengatakan apa pun tentang paket terbesar yang akan diterima jalur.

Naikkan MTU jalur hanya di tempat setiap hop setuju

Bingkai jumbo adalah sifat ujung ke ujung, bukan pengaturan yang Anda aktifkan pada dua titik akhir yang kebetulan Anda kendalikan. Setiap sakelar, perute, dan titik serah penyedia di jalur luar harus menyetujui ukuran yang lebih besar, dan satu hop 1,500 byte akan membuang diam-diam paket yang baru saja Anda besarkan. Menaikkan antarmuka lokal saja adalah setengah perubahan klasik yang membuat terowongan tampak rusak sementara jaringan dasar diam-diam menjatuhkan paket.

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

Ubah antarmuka, lalu uji ulang jalur yang sama sebelum mengubah hal lain. Jika uji masih gagal, kembalikan dengan ip link set dev eth1 mtu 1500 dan beralihlah ke fragmentasi alih-alih berdebat dengan penyedia tentang tautan yang bukan milik Anda.

Gunakan fragmentasi terowongan ketika jaringan dasar tidak dapat tumbuh

Mekanisme fragmentasi yang didukung di bawah paket dalam memungkinkan beberapa paket luar mengangkut satu paket dalam, dan titik akhir terowongan jauh menyusunnya kembali sebelum menyerahkan yang asli ke tumpukan. Opsi fragmentasi UDP Community OpenVPN adalah salah satu penerapan gagasan itu, dan tidak sama dengan fragmentasi IP biasa pada paket luar. Kedua pihak harus menjalankan versi yang mendukung format tersebut, dan jalur data harus yang Anda pikirkan: klien OpenVPN 3 dan kanal data yang dipercepat kernel memiliki batas berbeda, sehingga profil yang berfungsi pada satu klien dapat gagal pada klien lain.

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

Fragmentasi luar biasa adalah opsi lainnya, dan itu yang lebih lemah. Perute IPv6 tidak memfragmentasi paket yang diteruskan sama sekali, sehingga paket luar yang kebesaran langsung mati dan pengirim hanya mengetahuinya jika pesan ICMPv6 terkait bertahan melewati jalur. Fragmen juga mengundang penyaringan dan penguatan kehilangan, karena itu saya memperlakukannya sebagai cadangan, bukan rencana.

Pengangkut luar berbasis aliran menghindari soal ukuran dengan menyegmentasikan aliran byte-nya sendiri, dan paket dalam yang direkonstruksi tetap bisa 1,500 byte. Itu keputusan transport dengan biayanya sendiri, termasuk perilaku TCP di dalam TCP yang sudah dikenal, jadi ambillah dengan sengaja, bukan sebagai efek samping perdebatan MTU.

Pastikan paket dalam tiba tanpa perubahan

Verifikasi bukanlah handshake yang berhasil. Tangkap pada antarmuka terowongan di kedua ujung dan bandingkan ukuran serta isi paket yang benar-benar dikirim aplikasi dengan yang diterima sisi jauh.

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

Jika tangkapan menunjukkan paket dalam berukuran penuh di ujung jauh, pilihan pengangkutan berfungsi dan tugas yang tersisa adalah mencatatnya. Jika tidak menunjukkan apa pun sementara terowongan melaporkan dirinya aktif, paket luar dibuang di suatu tempat di antara titik akhir, yang mengembalikan Anda ke pengujian, bukan ke pengaturan cipher.

Catat tiga hal di tiket sebelum menutupnya: anggaran luar yang terukur, mekanisme yang Anda pilih, dan perintah yang membuktikan paket dalam bertahan. Orang berikutnya yang menyentuh terowongan ini akan membutuhkan ketiganya, dan tidak satu pun dapat direkonstruksi hanya dari berkas konfigurasi.