OpenVPN di PPPoE: turunkan link-mtu, tun-mtu, atau mssfix?

Ping menjawab, DNS menyelesaikan, dan setiap halaman yang membutuhkan segmen berukuran penuh menggantung. Pada uplink yang menambahkan enkapsulasi sendiri, jalur diam-diam kehilangan beberapa puluh byte anggaran, dan profil yang ditulis untuk Ethernet bersih terus meminta paket yang tidak dapat dibawa oleh jalur. Koneksi tidak lambat; ia membuang persis paket yang penting.

Tiga opsi dapat memperbaikinya, dan ketiganya bekerja pada lapisan berbeda. Memilih yang salah entah tidak melakukan apa pun atau membuat terowongan rapuh dengan cara baru, jadi pilihan dimulai dari apa yang sebenarnya didukung jalur.

Tiga tombol, tiga lapisan berbeda

link-mtu adalah anggaran luar: muatan terenkripsi ditambah header OpenVPN, header UDP, dan header IP luar. Ini menjelaskan apa yang keluar dari mesin, itulah sebabnya angka ini dibatasi oleh jalur fisik.

tun-mtu adalah anggaran dalam: antarmuka yang dilihat lalu lintas Anda. Nilainya lebih besar daripada yang dapat dibawa jalur tepat sebesar overhead terowongan, dan OpenVPN biasanya menurunkannya alih-alih memaksa Anda menyetelnya.

mssfix adalah mekanisme yang sama sekali berbeda. Ia menulis ulang ukuran segmen maksimum yang diumumkan selama jabat tangan TCP, sehingga rekan TCP memilih segmen yang muat setelah enkapsulasi. Ini tidak mengubah MTU antarmuka, dan tidak berpengaruh pada UDP.

Jika Anda menyetel link-mtu secara eksplisit, OpenVPN mengurangi overhead-nya sendiri untuk menurunkan MTU dalam. Overhead itu bukan konstanta tetap; nilainya bergantung pada cipher dan autentikasi, itulah sebabnya nilai yang disalin dari forum bisa salah pada profil lain. Menyetel link-mtu dan tun-mtu sekaligus memberi klien dua instruksi yang bertentangan.

Ukur jalur sebelum memilih angka apa pun

Ukurlah dari antarmuka fisik, bukan dari dalam terowongan, dan ingat bahwa ping melaporkan muatan, bukan ukuran paket. Tambahkan 28 byte untuk header IPv4 dan ICMP sebelum membandingkan muatan dengan bingkai 1500 byte, dan ingat koreksi itu ketika rekan melaporkan angka yang berbeda.

Pada klien Linux, ping -M do -s 1472 melarang fragmentasi dan gagal jika paket terlalu besar. Turunkan muatan sampai lolos, lalu tambahkan 28 untuk mendapatkan MTU jalur. PPPoE memakan 8 byte, jadi 1492 normal pada DSL. DS-Lite dan beberapa jalur seluler memakan 40 atau lebih, dan jawabannya biasanya lebih rendah daripada yang disiratkan kecepatan tautan nominal.

Jika setiap ukuran ping berhasil tetapi transfer besar tetap macet, curigai lubang hitam alih-alih batas ukuran sederhana. Pesan ICMP tentang fragmentasi yang diperlukan disaring di suatu tempat di sepanjang jalur, sehingga pengirim tidak pernah belajar mengecil, dan hanya aliran yang membutuhkan segmen besar yang menyadarinya.

Batasi TCP dulu, kecilkan terowongan kemudian

Jabat tangan TCP adalah satu-satunya hal yang disentuh mssfix, yang biasanya menjadikannya kontrol paling tidak mengganggu untuk dicoba lebih dulu. Setel sedikit di bawah anggaran nyata jalur, kirim nilai yang sama dari server agar kedua ujung sepakat, dan uji ulang unduhan besar. Jika kemacetan hilang, masalahnya adalah ukuran segmen TCP, dan tidak ada lagi yang perlu diubah.

Turunkan MTU dalam ketika lalu lintas yang terdampak bukan TCP. Layanan UDP, terowongan di dalam terowongan, atau aplikasi yang mengirim datagram berukuran penuh akan tetap gagal setelah pembatasan MSS karena tidak ada yang menulis ulang ukuran paketnya. Kurangi tun-mtu untuk kasus itu, atau setel link-mtu dan biarkan klien menurunkan nilai dalam, tetapi jangan pernah keduanya.

Jangan gunakan opsi fragmentasi lama. Opsi itu memecah paket di dalam terowongan, menambah overhead, dan sudah usang karena alasan yang baik; OpenVPN modern mengharapkan jalur dijelaskan secara akurat.

Mengapa pemeriksaan kecil tetap berfungsi

Kueri DNS, gema ICMP, dan jabat tangan TCP semuanya jauh di bawah ukuran yang gagal. Karena itu terowongan tampak sehat dalam setiap uji cepat sementara jabat tangan TLS dan respons HTTP diam-diam gagal. Kombinasi itulah, traceroute yang berfungsi dan peramban yang macet pada respons besar pertama, adalah tanda yang harus dicari. Gunakan pemeriksaan berukuran penuh sebelum menggunakan profil baru.

Verifikasi dengan lalu lintas yang gagal. Ambil halaman besar, kirim datagram UDP berukuran penuh jika itu layanan yang terdampak, dan ulangi dari klien kedua pada uplink lain. Catat MTU jalur yang terukur dan nilai yang Anda pilih, karena orang berikutnya yang menyentuh profil akan menganggap angka itu sembarang.

Jangan pernah menurunkan MTU dalam di bawah 1280 ketika IPv6 berjalan di atas terowongan, karena itulah minimum yang harus dibawa setiap tautan IPv6. MTU yang lebih kecil adalah fakta tentang jalur, bukan pengaturan kinerja yang disetel berdasarkan perasaan.