Mengapa OpenVPN berhenti terhubung setelah pembaruan Ubuntu?

Profil VPN yang berfungsi pekan lalu rusak setelah pembaruan rilis Ubuntu, dan log jarang menyebut pembaruannya. Yang disebutnya adalah lapisan yang gagal: jabat tangan TLS, cipher yang dinegosiasikan untuk kanal data, paket yang dipasang, atau salinan OpenSSL yang dimuat biner saat mulai. Setiap lapisan punya bentuk galat dan perbaikan sendiri, sehingga klasifikasi adalah pekerjaan pertama dan penyuntingan yang kedua. Anggap profil tidak bersalah sampai log menyebutnya.

Lapisan mana yang gagal: jabat tangan, cipher, paket, atau pustaka

Baca log klien sebelum menyentuh profil. galat paling awal pada keluaran adalah yang mengidentifikasi lapisan; semua yang tercetak setelahnya biasanya merupakan akibat kegagalan pertama itu. Bila klien tidak pernah mulai, log VPN adalah berkas yang salah untuk dibuka.

Keluhan tentang sertifikat dan tanda tangan, atau pesan tentang panjang kunci, datang dari kanal kendali dan kebijakan pustaka yang mengaturnya. Peringatan yang dimulai dengan DEPRECATED OPTION justru termasuk negosiasi kanal data.

Baris semacam Unrecognized option adalah kategori ketiga: biner baru tidak lagi menerima direktif yang dulu ditoleransi biner lama, jadi profil perlu ditulis ulang, bukan pustakanya dilonggarkan. Kegagalan paket tampak lain lagi karena terjadi sebelum kode terowongan berjalan. Biner yang hilang, plugin yang tidak dimuat, atau repositori yang menunjuk nama kode keliru semuanya menghasilkan bentuk itu. Empat gejala, empat tempat memeriksa, dan nyaris tidak ada tumpang tindih antara perbaikannya.

Saat jabat tangan gagal, kebijakan TLS menolak sertifikat

Ubuntu 22.04 memindahkan sistem ke OpenSSL 3, dan tingkat keamanan bawaan di cabang itu lebih ketat soal tanda tangan sertifikat dan ukuran kunci daripada 20.04. Sertifikat CA yang ditandatangani dengan digest lama, atau kunci di bawah ambang saat ini, kini gagal saat jabat tangan. Karena belum ada yang diautentikasi, galatnya terbaca seperti kata sandi salah atau server mati.

Perbaikan sempit melampirkan string cipher hanya pada koneksi ini. Di editor desktop, buka profil, masuk ke pengaturan lanjutan, dan letakkan DEFAULT:@SECLEVEL=0 di kolom cipher TLS. Berkas kunci NetworkManager mengambil nilai yang sama di bawah [vpn]:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

Mulai ulang NetworkManager dan hubungkan lagi, karena daemon menyimpan profil yang telah diurai di cache dan jika tidak akan terus memakai salinan yang sudah dipegangnya. Ketahui apa yang dilakukan baris itu sebelum mempertahankannya: pengaturan tersebut adalah ambang pada beberapa parameter sertifikat dan kunci, bukan nama cipher, sehingga menurunkannya memperluas apa yang diterima profil tunggal. Catat server mana yang memerlukannya dan lepaskan pengaturan itu begitu operator menerbitkan ulang materi terkini. Mengubah /etc/ssl/openssl.cnf mencapai ambang yang sama bagi setiap program yang membaca berkas itu, jauh melampaui VPN.

OpenVPN 2.6 memerlukan cipher tercantum untuk negosiasi

Ubuntu 22.10 membawa OpenVPN 2.6, dan pada rilis itu --cipher berhenti memilih kanal data sendiri. Cipher juga harus ada dalam daftar data-ciphers yang dinegosiasikan, jika tidak klien mencetak peringatan usang lalu gagal menaikkan terowongan.

Plugin NetworkManager dari masa yang sama masih hanya menulis direktif lama. Detail itu membelah diagnosis, karena profil yang diperbaiki tangan bisa terhubung dari shell namun tetap gagal dari applet desktop. Tambahkan daftar itu ke berkas koneksi di bawah [vpn]:

data-ciphers=AES-256-CBC

Pakai nilai yang diumumkan server, bukan yang Anda ingat; server yang menawarkan AES-256-GCM tidak akan bernegosiasi dengan daftar klien yang hanya menyebut CBC. Mulai ulang manajer dan hubungkan lagi, lalu ulangi percobaan dari shell dengan cipher diberikan eksplisit untuk negosiasi maupun cadangan:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

Jika perintah itu menaikkan terowongan, server, sertifikat, dan kredensial semuanya sehat, dan satu-satunya cacat tersisa adalah opsi tersimpan manajer. Peringatan tentang direktif keysize termasuk dalam pembersihan yang sama: komentari dan simpan berkas asli di samping profil.

Cacat paket dan plugin tampak seperti cacat VPN

Tidak setiap kegagalan pascapembaruan bersifat kriptografis. Repositori OpenVPN yang ditambahkan dengan nama kode yang tidak dipakai rilis menghasilkan paket yang tidak pernah terpasang, jadi bandingkan apa yang dilaporkan lsb_release -a dengan berkas daftar yang Anda tambahkan. Komponen universe yang hilang atau kantong keamanan menghasilkan paket yang sama sekali tidak ditemukan. Kedua kasus membiarkan profil utuh dan terowongan mustahil.

Baca galat manajer paket sebelum log VPN. Bila klien tidak pernah dipasang, sebanyak apa pun penyuntingan profil tidak akan menghasilkan jabat tangan.

Profil dua faktor yang berhenti meminta adalah versi plugin dari kisah yang sama. Tantangannya datang dari plugin autentikasi, dan pembaruan yang menghapus atau menggantinya membiarkan profil utuh sementara permintaan hilang. Pasang ulang plugin yang didukung alih-alih menghapus faktor kedua agar koneksi bekerja.

Pustaka vendor bisa bersembunyi di balik galat kebijakan

Satu pola layak dikenali karena mengalahkan setiap perbaikan kebijakan. Alat konfigurasi vendor perangkat keras dapat memasang pustaka OpenSSL sendiri dan menempatkannya di depan salinan sistem pada jalur pencarian pemuat. Klien lalu mulai terhadap pustaka yang tidak diperbarui siapa pun, dan kegagalan awal tampak persis seperti sertifikat yang ditolak.

Memasang ulang paket VPN tidak mengubah pustaka mana yang ditemukan lebih dulu, dan menurunkan tingkat TLS tidak menjangkau pustaka yang tidak pernah berasal dari sistem. Tanyakan kepada pemuat objek kripto mana yang benar-benar diselesaikan biner:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

Hapus atau arahkan ulang salinan vendor, lalu jalankan pemeriksaan yang sama lagi. Versi yang diharapkan harus yang sedang dipakai sebelum Anda kembali ke profil.

Menyematkan klien lama membeli waktu, bukan solusi

Menahan versi klien sebelumnya memulihkan terowongan selama penahanan berlangsung. Itu juga membekukan pembaruan keamanan paket tersebut dan menjadwalkan kerusakan yang sama pada pembaruan berikutnya, jadi perlakukan sebagai solusi sementara bertanggal, bukan penyelesaian.

Jika tetap disematkan, tahan paket secara eksplisit agar pembaruan tanpa pengawasan tidak dapat membatalkan sematan, catat alasan dan tanggal untuk meninjau ulang, dan pasang pengingat untuk rilis profil berikutnya dari penyedia. Kondisi yang layak dipantau adalah profil server yang menegosiasikan cipher terkini; begitu ada, sematan tidak lagi punya alasan. Sebaliknya, sematan yang tidak tercatat menjadi gangguan yang tak dapat dijelaskan siapa pun enam bulan kemudian, karena orang yang menerapkannya sudah pergi dan berkas tidak mencatat apa pun.

Lain kali VPN mati setelah pembaruan rilis, ajukan lima pertanyaan berurutan: lapisan mana yang menghasilkan galat pertama, apakah kebijakan TLS menolak sertifikat, apakah cipher dapat dinegosiasikan di kedua arah, apakah paket dan pluginnya benar-benar terpasang, dan pustaka mana yang dimuat proses. Hanya setelah kelimanya bersih, penurunan versi masuk akal.