Pengaturan MSS TCP di gateway IPsec Linux: apa yang diperbaikinya
Permintaan kecil berhasil dan respons besar macet. Periksa apakah aturan MSS pada jalur TCP dalam adalah perbaikan yang tepat, dan di mana aturan itu harus berada.
Ping berhasil, SSH berhasil, halaman kecil termuat, lalu setiap respons besar macet sampai waktu habis. Pola klasiknya menunjuk ke ukuran paket, bukan keterjangkauan: jalur membawa handshake dan beberapa kilobyte pertama, lalu segmen berukuran penuh menghilang. Di gateway IPsec Linux, aturan TCP MSS sering menjadi solusinya, tetapi hanya jika Anda memahami apa yang diubahnya dan di mana paket yang disentuhnya benar-benar berada. Urutan di bawah mengikuti paket dari gejala hingga penempatan aturan, sehingga Anda dapat berhenti begitu penjelasannya tidak lagi cocok.
Gejala yang menunjukkan MSS
TCP menegosiasikan ukuran segmen maksimum dalam handshake. Jika nilai itu lebih besar daripada yang dapat dibawa jalur setelah enkapsulasi, pengirim terus menghasilkan segmen yang tidak pernah tiba, dan koneksi macet setelah putaran pertama. Respons kecil muat; yang besar tidak.
Umpan balik ICMP dapat menyelamatkan koneksi melalui penemuan MTU jalur, dan firewall yang membuang pesan itu mengubah kemacetan menjadi lubang hitam senyap. Itulah sebabnya terowongan yang sama berhasil untuk satu aplikasi dan gagal untuk aplikasi lain tanpa perbedaan konfigurasi yang jelas.
Apa yang dilakukan aturan TCPMSS dan apa yang tidak
Aturan itu menulis ulang opsi MSS pada paket handshake TCP saat melewatinya. Aturan ini tidak menetapkan MTU antarmuka terowongan, tidak mengubah kebijakan IPsec, dan pada kernel saat ini hanya menurunkan nilai yang diumumkan, bukan menaikkan nilai yang sudah lebih kecil. Aturan ini juga hanya menyentuh TCP; muatan UDP, perilaku DNS, dan pemilih lalu lintas yang dinegosiasikan berada di luar jangkauannya.
Karena perubahan terjadi selama handshake, koneksi yang sudah ada dan dibangun sebelum aturan tetap memakai nilai lamanya. Ujilah dengan koneksi baru, dan perkirakan bahwa percobaan pertama setelah perubahanlah yang memberi tahu Anda sesuatu. Tidak ada bagian dari aturan yang menjangkau koneksi yang sudah terbuka. Itulah sebabnya perbaikan yang diterapkan di tengah insiden bisa tampak tidak melakukan apa pun.
Letakkan aturan pada jalur TCP dalam
Di gateway Linux berbasis kebijakan, paket yang diteruskan masih tampak seperti TCP biasa saat firewall melihatnya. Kebijakan IPsec memutuskan bahwa paket akan dilindungi; firewall tidak melihat header ESP untuk aliran dalam, jadi pencocokan dengan ESP di sini menggambarkan paket yang sama sekali berbeda. Ketidakcocokan itulah sebabnya beberapa aturan tampak benar dan tidak pernah cocok.
Dalam istilah iptables, aturan itu termasuk tabel mangle pada jalur penerusan, dibatasi pada paket handshake: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. Angkanya adalah contoh, bukan konstanta universal; turunkan dari overhead enkapsulasi dan MTU jalur yang sebenarnya. Padanan nftables menetapkan ukuran segmen maksimum dalam rantai forward atau postrouting.
Pisahkan aturan pendengar luar untuk IKE dan ESP dari aturan penerusan dalam. Satu aturan yang mencoba mengizinkan aliran aplikasi dan protokol luar sekaligus akhirnya tidak cocok secara andal dengan keduanya.
Hormati pemilik firewall dan urutan NAT
Jika UFW memiliki firewall host, tambahkan perubahan mangle dan penerusan melalui konfigurasi permanen yang didukungnya, bukan dengan mengetik perintah yang hilang pada pemuatan ulang berikutnya. Aturan yang dimasukkan ke tabel yang salah atau setelah aturan terminal tidak berpengaruh, dan tabel aktif menyembunyikannya dari Anda.
Terjemahan sumber adalah keputusan terpisah yang sering berinteraksi dengan yang ini. Pengecualian yang ditempatkan sebelum aturan masquerade umum mencegah lalu lintas terlindungi kehilangan sumber yang diwajibkan kebijakannya; ini tidak memperbaiki masalah ukuran, dan aturan ukuran tidak memperbaiki masalah terjemahan.
Verifikasi secara sempit, lalu berhenti
Buka koneksi baru ke layanan yang gagal dan amati aplikasi maupun penghitung aturan. Jika kemacetannya hilang, Anda punya bukti tentang jalur TCP itu dengan enkapsulasi tersebut. Anda tidak punya bukti bahwa setiap protokol VPN cocok, bahwa setiap aplikasi UDP sudah diperbaiki, atau bahwa layanan hulu tertentu adalah penyebab aslinya.
Biarkan umpan balik ukuran ICMP bekerja di tempat kebijakan mengizinkannya, dan tangani penyesuaian otomatis berbasis MTU rute dengan hati-hati ketika jalur IPsec luar tidak diwakili oleh rute dalam. Semakin sempit kesimpulannya, semakin mudah insiden berikutnya didiagnosis.