OpenVPN pada PPPoE: turunkan link-mtu, tun-mtu atau mssfix?
Ping berfungsi tetapi halaman besar tersekat pada pautan PPPoE atau DS-Lite. Putuskan antara link-mtu, tun-mtu dan mssfix dengan mengukur laluan, bukan meneka.
Ping menjawab, DNS menyelesaikan, dan setiap halaman yang memerlukan segmen bersaiz penuh tersekat. Pada pautan yang menambah enkapsulasi sendiri, laluan kehilangan beberapa dozen bait bajet secara senyap, dan profil yang ditulis untuk Ethernet bersih terus meminta paket yang talian tidak dapat bawa. Sambungan tidak perlahan; ia membuang tepat paket yang penting.
Tiga pilihan boleh membaiki ini, dan ia berfungsi pada lapisan berbeza. Memilih yang salah sama ada tidak melakukan apa-apa atau menjadikan terowong rapuh dengan cara baharu, jadi pilihan bermula dengan apa yang benar-benar disokong oleh laluan.
Tiga tombol, tiga lapisan berbeza
link-mtu ialah bajet luar: muatan disulitkan serta pengepala OpenVPN, pengepala UDP dan pengepala IP luar. Ia menerangkan apa yang keluar dari mesin, dan itulah sebabnya ia nombor yang dihadkan oleh laluan fizikal.
tun-mtu ialah bajet dalam: antara muka yang dilihat oleh trafik anda. Ia lebih besar daripada apa yang laluan boleh bawa tepat dengan overhed terowong, dan OpenVPN biasanya memperolehnya daripada memaksa anda menetapkannya.
mssfix ialah mekanisme yang sama sekali berbeza. Ia menulis semula saiz segmen maksimum yang diumumkan semasa jabat tangan TCP, supaya rakan TCP memilih segmen yang muat selepas enkapsulasi. Ia tidak mengubah MTU antara muka, dan tiada kesan pada UDP.
Jika anda menetapkan link-mtu secara eksplisit, OpenVPN menolak overhednya sendiri untuk memperoleh MTU dalam. Overhed itu bukan pemalar tetap; ia bergantung pada sifer dan pengesahan, itulah sebabnya nilai yang disalin daripada forum boleh salah pada profil lain. Menetapkan kedua-dua link-mtu dan tun-mtu memberi klien dua arahan yang bercanggah.
Ukur laluan sebelum memilih sebarang nombor
Ukur dari antara muka fizikal, bukan dari dalam terowong, dan ingat bahawa ping melaporkan muatan, bukan saiz paket. Tambah 28 bait untuk pengepala IPv4 dan ICMP sebelum membandingkan muatan dengan bingkai 1500 bait, dan ingat pembetulan itu apabila rakan melaporkan nombor yang berbeza.
Pada klien Linux, ping -M do -s 1472 melarang pemecahan dan gagal jika paket terlalu besar. Turunkan muatan sehingga ia lulus, kemudian tambah 28 untuk mendapatkan MTU laluan. PPPoE memakan 8 bait, jadi 1492 adalah normal pada DSL. DS-Lite dan sesetengah laluan mudah alih memakan 40 atau lebih, dan jawapannya biasanya lebih rendah daripada yang disarankan oleh kelajuan pautan nominal.
Jika setiap saiz ping berjaya tetapi pemindahan besar masih tersekat, syaki lubang hitam dan bukan had saiz semata-mata. Mesej ICMP tentang pemecahan yang diperlukan ditapis di suatu tempat di sepanjang laluan, jadi penghantar tidak pernah belajar mengecil, dan hanya aliran yang memerlukan segmen besar menyedarinya.
Hadkan TCP dahulu, kecilkan terowong kemudian
Jabat tangan TCP adalah satu-satunya perkara yang mssfix sentuh, yang biasanya menjadikannya kawalan paling kurang mengganggu untuk dicuba dahulu. Tetapkan ia sedikit di bawah bajet sebenar laluan, hantar nilai yang sama dari pelayan supaya kedua-dua hujung bersetuju, dan uji semula muat turun besar. Jika tersekat hilang, masalahnya ialah saiz segmen TCP, dan tiada apa-apa lagi perlu diubah.
Turunkan MTU dalam apabila trafik yang terjejas bukan TCP. Perkhidmatan UDP, terowong di dalam terowong, atau aplikasi yang menghantar datagram bersaiz penuh akan terus gagal selepas had MSS kerana tiada apa-apa yang menulis semula saiz paketnya. Kurangkan tun-mtu untuk kes itu, atau tetapkan link-mtu dan biarkan klien memperoleh nilai dalam, tetapi jangan sekali-kali kedua-duanya.
Jangan gunakan pilihan pemecahan lama. Ia memecahkan paket di dalam terowong, menambah overhed, dan telah ditamatkan atas sebab yang baik; OpenVPN moden menjangka laluan diterangkan dengan tepat.
Mengapa ujian kecil terus berfungsi
Pertanyaan DNS, gema ICMP dan jabat tangan TCP semuanya jauh di bawah saiz yang gagal. Oleh itu terowong kelihatan sihat dalam setiap ujian pantas sementara jabat tangan TLS dan respons HTTP gagal secara senyap. Gabungan itulah, traceroute yang berfungsi dan pelayar yang tersekat pada respons besar pertama, adalah tanda yang perlu dicari. Gunakan ujian bersaiz penuh sebelum menggunakan profil baharu.
Sahkan dengan trafik yang gagal. Ambil halaman besar, hantar datagram UDP bersaiz penuh jika itu perkhidmatan yang terjejas, dan ulangi dari klien kedua pada pautan lain. Catat MTU laluan yang diukur dan nilai yang anda pilih, kerana orang seterusnya yang menyentuh profil akan menganggap nombor itu sewenang-wenangnya.
Jangan sekali-kali menurunkan MTU dalam di bawah 1280 apabila IPv6 berjalan di atas terowong, kerana itulah minimum yang setiap pautan IPv6 mesti bawa. MTU yang lebih kecil ialah fakta tentang laluan, bukan tetapan prestasi yang dilaras mengikut perasaan.