MTU per rute di Linux: tiga kendali ukuran, satu rute
MTU antarmuka, MTU rute, dan batas MSS bekerja pada lapisan berbeda. Pasang anggaran ke rute yang memenangi pencarian, dan jaga perubahan tetap dapat dibalik.
Tiga pengaturan pada klien Linux semuanya terdengar seperti «buat paket lebih kecil», dan ketiganya bekerja pada lapisan berbeda. MTU antarmuka membatasi setiap paket yang dikirim perangkat. MTU rute membatasi paket yang memakai rute itu, yang sering kali justru yang Anda inginkan untuk satu tujuan VPN. Batas TCP MSS mengubah apa yang dinegosiasikan kedua ujung, dan tidak melakukan apa pun untuk UDP.
Tiga kendali yang terlihat seperti tombol yang sama
Letakkan keduanya berdampingan sebelum memilih, karena memilih baris yang salah menjelaskan sebagian besar saran yang tidak berhasil:
| Control | Scope | What it cannot fix |
|---|---|---|
| Interface MTU | Every packet the device sends | Nothing, but it over-constrains unrelated traffic |
| Route MTU | Packets using that route | A send that the lookup never routes there |
| MSS clamp | TCP handshake on that path | UDP payload sizes and ICMP |
Menurunkan MTU Ethernet untuk seluruh mesin adalah versi kasar dari perbaikan ini. Ini berhasil, dan juga menghukum setiap aplikasi lain di host, termasuk yang rutenya baik-baik saja. Nilai per rute menyatakan maksud yang sama tanpa biaya sampingan.
Perbandingannya hanya berlaku untuk lalu lintas yang dihasilkan host itu sendiri. Meneruskan paket untuk klien lain melibatkan rute klien tersebut dan anggaran luar terowongan, dan metrik rute di host ini tidak menjangkau melewati batas itu.
Pasang anggaran pada rute yang memenangi pencarian
Contoh catatan rute IPv4 terlihat seperti ini:
ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380Baca catatan itu sebagai deskripsi maksud, bukan nilai untuk ditempel. Prefiks, perangkat, dan sumber pilihan harus cocok dengan konfigurasi sebenarnya, dan angkanya harus berasal dari bukti tentang jalur yang dienkapsulasi, bukan dari pos blog. MTU rute membatasi paket IP dalam, yang tidak sama dengan muatan TCP 1380 byte atau paket luar terenkripsi 1380 byte.
Lihat di mana pencarian benar-benar diselesaikan sebelum menambahkan apa pun. Host dengan aturan kebijakan dapat merutekan tujuan tertentu melalui tabel selain main, dan metrik yang hanya ada di main tidak terlihat oleh permintaan itu. Bandingkan ip -4 route show table all dengan jawaban dari ip route get, termasuk konteks tanda atau ruang nama saat aturan memakainya. Jika keduanya tidak cocok, tabel yang menjawab adalah yang membutuhkan metrik, bukan yang tampak lebih rapi.
mtu bukan mtu lock
Secara bawaan kernel masih dapat memperbarui MTU jalur dari umpan balik ICMP, dan untuk itulah penemuan MTU jalur ada. Menambahkan lock menghentikannya. Ini keputusan berbeda, bukan cara yang lebih kuat untuk menyimpan angka yang sama, dan untuk IPv4 ini mengubah penanganan terdokumentasi dari bit «jangan fragmentasi».
Mengunci masuk akal ketika Anda sudah mengukur jalur dan ingin nilainya tetap, apa pun yang datang. Ini bawaan yang buruk ketika jaringan mengirim umpan balik ukuran yang sah, karena kernel tidak dapat lagi menyesuaikan dan kegagalan berpindah ke gejala lain.
Jika ICMP difilter di suatu titik di jalur, tidak ada pengaturan rute yang memperbaikinya. Perbaikannya ada di filter, dan MTU yang lebih kecil adalah jalan pintas yang menyembunyikan kerusakan sebenarnya sampai jalur berikutnya berubah.
Perangkat lunak terowongan menambahkan kendali ukurannya sendiri
OpenVPN- mssfix menyesuaikan ukuran segmen TCP untuk kasus terowongan UDP yang didokumentasikannya. Ia bekerja pada percakapan TCP, jadi ini bukan ejaan lain dari MTU rute sistem operasi, dan tidak dapat membantu layanan UDP yang mengabaikan negosiasi.
Jangan menumpuk MTU rute, perubahan MTU antarmuka, dan batas MSS dalam satu jendela perubahan. Jika masalahnya hilang, Anda tidak akan tahu mana yang berpengaruh, dan yang Anda pertahankan akan membatasi lalu lintas bertahun-tahun tanpa alasan yang diingat siapa pun.
Buat dapat dibalik, lalu buktikan
Pemilik sebenarnya rute memutuskan apakah perubahan bertahan setelah sambung ulang. Klien VPN yang memasang rute secara dinamis biasanya akan membangunnya kembali tanpa metrik Anda, dan ip route add manual lalu tampak seperti perbaikan yang gagal sehari kemudian. Taruh nilainya di konfigurasi manajer, dan jika perlu percobaan sementara, catat dulu rute aslinya.
Uji dengan koneksi baru yang melakukan operasi yang macet, lalu pastikan rute privat yang dimaksud masih menang dan tujuan tak terkait tidak berubah. Sambungkan ulang terowongan dan baca rute lagi, karena nilai yang hilang saat sambung ulang bukan perbaikan.
Jika bukti tidak mendukung perubahan, hapus penimpaan lewat manajernya dan pulihkan atribut rute semula alih-alih menghapus rute. Lalu catat apa yang Anda ukur, di jalur mana, supaya orang berikutnya dapat membedakan perbaikan nyata dari percobaan yang dibiarkan berjalan.