MTU atau MSS? Apa yang sebenarnya diperbaiki oleh perubahan VPN

Ping berhasil, transfer besar menggantung, dan terowongan melaporkan dirinya sehat. Seseorang menurunkan MTU antarmuka, orang lain membatasi MSS, dan kadang masalahnya hilang karena alasan yang tidak dicatat siapa pun. Kedua angka itu menggambarkan objek yang berbeda, jadi mengubah yang salah menghasilkan perbaikan yang tampak seperti keberuntungan. Inilah prosedurnya: kenali lapisannya, terapkan penyesuaian yang cocok, lalu uji pada koneksi baru.

Dua angka, dua objek

MTU milik sebuah tautan atau antarmuka: itu paket terbesar yang dapat diserahkan tanpa dipecah. MSS milik TCP: itu jumlah muatan TCP terbesar yang dapat dibawa satu segmen, dan itu mengecualikan header TCP maupun IP. Pada tautan Ethernet biasa dengan IPv4, MTU 1500 byte menghasilkan MSS 1460 byte yang sudah dikenal. Angka-angka itu menggambarkan lapisan berbeda dan dipertukarkan dengan mekanisme berbeda. Mudah tertukar karena keduanya diukur dalam byte dan keduanya berada dekat 1500.

Yang satu datang sebagai pengaturan antarmuka. Yang lain datang sebagai opsi di dalam segmen SYN, dinegosiasikan antara ujung yang tidak pernah melihat antarmuka Anda.

Di mana beban tambahan luar mendarat

VPN menaruh paket dalam ke dalam paket lain, dan paket luar harus muat di jalur fisik. Header enkapsulasi, header IP luar, header transport, dan tag autentikasi apa pun semuanya memakai byte yang tidak dapat digunakan paket dalam. Biarkan antarmuka terowongan di 1500 dan paket luar rutin melampaui apa yang dapat dibawa jalur. Dengan bit 'jangan pecah' disetel, router menjatuhkannya dan seharusnya mengirim balik galat ICMP; jika galat itu difilter, pengirim tidak pernah mengetahuinya.

Itulah sebabnya kegagalan tampak selektif. Permintaan kecil selesai dan apa pun yang memenuhi segmen terhenti, karena hanya paket besar yang dibuang. Terowongan yang meloloskan ping bukan terowongan yang membawa data.

Membatasi MSS, dan di mana penerapannya

Pembatasan MSS menulis ulang nilai dalam segmen SYN saat melewati titik yang dipilih, sehingga kedua ujung memilih muatan lebih kecil tanpa ada yang tahu mengapa. Di Linux ini adalah target tabel mangle yang diterapkan oleh aturan eksplisit, dan harus mengenai paket SYN ke arah yang Anda maksud. Batasi pada antarmuka terowongan dan rentang alamat, karena aturan luas mengubah perilaku lalu lintas yang tidak pernah masuk terowongan.

Efeknya hanya pada TCP. Aplikasi UDP, sesi QUIC, dan protokol apa pun yang membangun datagramnya sendiri tidak tersentuh.

Diagnosis dengan jalur tetap

Pertahankan satu variabel setiap kali. Uji dengan paket yang ukurannya Anda pilih sendiri, dan setel flag 'jangan pecah' agar kernel melaporkan hasilnya alih-alih menyembunyikannya.

Catat di mana kegagalan dimulai: di dalam terowongan, di antarmuka terowongan, atau di jalur fisik setelah enkapsulasi. Lalu ubah satu angka dan ulangi uji yang sama, bukan uji lain. Koneksi yang ada mempertahankan MSS yang dinegosiasikan, jadi perubahan kebijakan hanya terlihat pada koneksi baru, dan itulah sebabnya halaman yang di-cache tidak membuktikan apa pun ke arah mana pun. Jika satu unggahan besar mulai berfungsi, Anda belajar tentang jalur itu dan bukan tentang setiap protokol di atasnya.

Apa yang tidak diperbaiki setiap perubahan

Menurunkan MTU antarmuka tidak mengubah MSS sesi yang sudah terbentuk. Membatasi MSS tidak membantu aliran UDP, dan tidak memperbaiki jalur di mana galat ICMP difilter hanya satu arah. Setiap perubahan memperbaiki satu kelas masalah dan membiarkan sisanya persis seperti sebelumnya.

Catat penyesuaian mana yang Anda terapkan, di mana, dan uji mana yang menunjukkan perbedaannya, karena jika tidak, insinyur berikutnya menerapkan keduanya dan kehilangan kemampuan mengatakan mana yang penting. Jika batasannya nyata dan permanen, pilih MTU terowongan yang mencerminkannya daripada pembatasan yang menyembunyikannya. Jika Anda harus membatasi, biarkan aturannya sempit dan diberi komentar, karena aturan mangle yang tidak dijelaskan menjadi permanen secara default.