Kompresi OpenVPN: menolak, hanya menerima, atau LZO penuh?

Tiga baris dalam profil tampak seperti semuanya mematikan kompresi, dan hanya satu yang benar-benar melakukannya. Perbedaannya penting karena peringatan yang ingin Anda diamkan hanyalah gejala, sedangkan kebijakanlah yang menentukan apakah pihak lain masih dapat mengompresi. Membandingkan opsi pada satu sumbu, yaitu apa yang diizinkan masing-masing setelah perubahan, menghilangkan sebagian besar ambiguitas. Mana yang Anda inginkan bergantung pada apakah Anda bermigrasi atau menetap.

Tiga kebijakan yang tampak serupa di berkas konfigurasi

Setiap opsi menjawab pertanyaan yang berbeda. allow-compression no menolak muatan terkompresi secara langsung, allow-compression asym mendekompresi yang masuk dan tidak pernah mengompresi yang keluar, dan comp-lzo no lama menyisakan ruang bagi push pihak lain untuk mengaktifkan kompresi. Hanya yang pertama adalah kebijakan yang tidak dapat ditimpa server.

Tulis ketiganya dalam tabel sebelum memilih, karena namanya cukup mirip untuk menyesatkan peninjau. Dua di antaranya masih menjalankan kode dekompresi pada paket yang diterima, dan itulah yang menjadi pokok argumen keamanan. Yang ketiga menghapus kemampuan itu alih-alih membatasi arahnya. Jika catatan perubahan menyatakan kompresi dinonaktifkan, tepat satu baris memenuhi kalimat itu.

Peringatan yang memulai penyelidikan bukanlah tujuannya. Mendiamkannya sambil membiarkan kebijakan permisif tetap ada menghasilkan log bersih dan paparan yang tidak berubah.

Apa arti no pada opsi LZO lama

Pada opsi LZO yang usang, no menonaktifkan kompresi untuk sisi lokal tanpa melarang pihak lain mengaktifkannya di tempat kebijakan mengizinkannya. Asimetri itulah sebabnya memindahkan profil ke penolakan ketat mengubah perilaku dengan cara yang mungkin tidak pernah diungkapkan oleh uji laboratorium satu server.

Kekhawatiran keamanan bersifat bersyarat, bukan mutlak. Ketika penyerang dapat menempatkan teks biasa pilihan di samping rahasia dan mengamati bagaimana kompresi mengubah ukuran lalu lintas terenkripsi, ada kanal informasi. Beralih dari LZO ke LZ4 mengubah algoritme dan pembingkaian, bukan mekanisme itu.

Jadi kerangka yang jujur menyangkut apa yang bersedia Anda izinkan, bukan algoritme mana yang sedang direkomendasikan. Penolakan ketat adalah satu-satunya opsi yang tidak bergantung pada kerja sama pihak lain.

Hanya menerima adalah keadaan migrasi, bukan tujuan

Penerimaan asimetris ada agar satu pihak dapat berhenti mengompresi sementara pihak lain masih mengharapkannya. Ini jembatan, dan jembatan memerlukan tanggal akhir dan pemilik. Catat rekan mana yang masih mengirim lalu lintas terkompresi, karena kebijakan mengizinkan tepat lalu lintas itu. Tanpa daftar itu, keadaan migrasi menjadi konfigurasi permanen karena kelembaman.

Klien tidak dapat memaksa server yang tidak kompatibel meninggalkan pembingkaian lama dengan menyunting berkasnya sendiri. Arah push ditentukan di server, jadi migrasi sebenarnya selesai di konfigurasi server dan berkas per kliennya.

Mode stub mempertahankan pembingkaian sambil melewati pekerjaan kompresi itu sendiri, dan itu bukan padanan langsung opsi lama. Ujilah terhadap rekan tertua yang masih harus Anda dukung sebelum memilih salah satunya.

Di mana offload kanal data mengubah jawabannya

Offload kanal data memindahkan penanganan paket ke kernel, dan profil yang masih bergantung pada pembingkaian kompresi mungkin tidak cocok dengan jalur itu. Kegagalannya tidak selalu nyaring: klien terhubung lalu berperilaku berbeda dari terowongan yang Anda uji.

Periksa implementasi mana yang aktif sebelum dan sesudah perubahan, bukan hanya apakah koneksi berhasil. Ketika jalur offload menolak pembingkaian kompresi, kebijakan penolakan ketat dan penerapan offload sepakat, sedangkan kebijakan permisif dan penerapan offload tidak.

Kombinasi itu layak mendapat ujinya sendiri, karena di situlah berkas yang tampak benar diam-diam bukan berkas yang dipakai. Bandingkan keadaan yang dinegosiasikan dengan niat yang tercatat di profil, karena hanya satu dari keduanya terlihat di log.

Pilih kebijakan, lalu verifikasi hasil yang dinegosiasikan

Pilih penolakan ketat bila Anda dapat mengubah kedua ujung, penerimaan asimetris bila belum bisa, dan kompresi penuh hanya bila Anda dapat menjelaskan mengapa paparannya dapat diterima. Lalu verifikasi apa yang dinegosiasikan, bukan apa yang dikatakan berkas. Log yang lebih tenang hanya menjadi bukti bila cocok dengan kebijakan yang hendak Anda terapkan.

Simpan keputusan itu di samping profil yang bersangkutan, bersama tanggal dan rekan yang masih dikecualikan. Enam bulan kemudian, catatan itu adalah pembeda antara pengecualian yang disengaja dan kecelakaan yang tidak dapat diberi tanggal oleh siapa pun. Tuliskan di repositori yang sama dengan profil agar penyunting berikutnya melihat alasannya sebelum direktifnya.