Mengapa OpenVPN berhenti menyambung selepas peningkatan Ubuntu?

Profil VPN yang berfungsi minggu lalu rosak selepas peningkatan keluaran Ubuntu, dan log jarang menyebut peningkatan itu. Apa yang disebutnya ialah lapisan yang gagal: jabat tangan TLS, sifer yang dirundingkan untuk saluran data, pakej yang dipasang, atau salinan OpenSSL yang dimuatkan binari semasa mula. Setiap lapisan mempunyai bentuk ralat dan pembaikannya sendiri, jadi pengelasan ialah kerja pertama dan penyuntingan kerja kedua. Anggap profil itu tidak bersalah sehingga log menamakannya.

Lapisan mana yang gagal: jabat tangan, sifer, pakej atau pustaka

Baca log klien sebelum menyentuh profil. ralat paling awal dalam keluaran ialah yang mengenal pasti lapisan; semua yang dicetak selepasnya biasanya akibat kegagalan pertama itu. Apabila klien tidak bermula langsung, log VPN ialah fail yang salah untuk dibuka.

Aduan tentang sijil dan tandatangan, atau mesej tentang panjang kunci, datang dari saluran kawalan dan dasar pustaka yang mengawalnya. Amaran yang bermula dengan DEPRECATED OPTION pula tergolong dalam rundingan saluran data.

Baris seperti Unrecognized option ialah kategori ketiga: binari baharu tidak lagi menerima arahan yang ditoleransi binari lama, jadi profil perlu ditulis semula dan bukan pustakanya dilonggarkan. Kegagalan pakej kelihatan berbeza kerana ia berlaku sebelum sebarang kod terowong berjalan. Binari hilang, pemalam yang tidak dimuatkan, atau repositori yang menunjuk nama kod salah semuanya menghasilkan bentuk itu. Empat simptom, empat tempat untuk diperiksa, dan hampir tiada pertindihan antara pembaikannya.

Apabila jabat tangan gagal, dasar TLS menolak sijil

Ubuntu 22.04 memindahkan sistem ke OpenSSL 3, dan tahap keselamatan lalai dalam cabang itu lebih ketat terhadap tandatangan sijil dan saiz kunci daripada 20.04. Sijil CA yang ditandatangani dengan digest lama, atau kunci di bawah ambang semasa, kini gagal semasa jabat tangan. Oleh sebab belum ada yang disahkan, ralat itu terbaca seperti kata laluan salah atau pelayan mati.

Pembaikan sempit melampirkan rentetan sifer pada sambungan ini sahaja. Dalam editor desktop, buka profil, pergi ke tetapan lanjutan dan letakkan DEFAULT:@SECLEVEL=0 dalam medan sifer TLS. Fail kunci NetworkManager mengambil nilai yang sama di bawah [vpn]:

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

Mulakan semula NetworkManager dan sambung semula, kerana daemon menyimpan profil yang dihurai dalam cache dan jika tidak akan terus menggunakan salinan yang sudah dipegangnya. Ketahui apa yang baris itu lakukan sebelum mengekalkannya: tetapan itu ialah ambang merentas beberapa parameter sijil dan kunci, bukan nama sifer, jadi menurunkannya meluaskan apa yang diterima oleh profil tunggal. Catat pelayan mana yang memerlukannya dan lepaskan tetapan itu apabila pengendali mengeluarkan semula bahan semasa. Mengubah /etc/ssl/openssl.cnf mencapai ambang yang sama bagi setiap program yang membaca fail itu, jauh melebihi VPN.

OpenVPN 2.6 memerlukan sifer disenaraikan untuk rundingan

Ubuntu 22.10 membawa OpenVPN 2.6, dan dalam keluaran itu --cipher berhenti memilih saluran data sendiri. Sifer juga mesti ada dalam senarai data-ciphers yang dirundingkan, jika tidak klien mencetak amaran keusangan dan kemudian gagal menaikkan terowong.

Pemalam NetworkManager dari zaman yang sama masih hanya menulis arahan lama. Perincian ini memecahkan diagnosis, kerana profil yang dibetulkan dengan tangan boleh bersambung dari shell dan masih gagal dari applet desktop. Tambahkan senarai itu pada fail sambungan di bawah [vpn]:

data-ciphers=AES-256-CBC

Gunakan nilai yang diumumkan pelayan, bukan yang anda ingat; pelayan yang menawarkan AES-256-GCM tidak akan berunding dengan senarai klien yang hanya menamakan CBC. Mulakan semula pengurus dan sambung semula, kemudian ulangi percubaan dari shell dengan sifer diberikan secara jelas untuk rundingan dan sandaran:

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

Jika arahan itu menaikkan terowong, pelayan, sijil dan kelayakan semuanya sihat, dan satu-satunya kecacatan yang tinggal ialah pilihan yang disimpan pengurus. Amaran tentang arahan keysize tergolong dalam pembersihan yang sama: komenkannya dan simpan fail asal di sebelah profil.

Kecacatan pakej dan pemalam kelihatan seperti kecacatan VPN

Bukan setiap kegagalan selepas peningkatan bersifat kriptografi. Repositori OpenVPN yang ditambah di bawah nama kod yang tidak digunakan keluaran menghasilkan pakej yang tidak pernah dipasang, jadi bandingkan apa yang dilaporkan lsb_release -a dengan fail senarai yang anda tambah. Komponen universe yang hilang atau poket keselamatan menghasilkan pakej yang langsung tidak ditemui. Kedua-dua kes membiarkan profil utuh dan terowong mustahil.

Baca ralat pengurus pakej sebelum log VPN. Jika klien tidak pernah dipasang, sebarang jumlah penyuntingan profil tidak akan menghasilkan jabat tangan.

Profil dua faktor yang berhenti bertanya ialah versi pemalam bagi kisah yang sama. Cabaran datang dari pemalam pengesahan, dan peningkatan yang menggugurkan atau menggantikannya membiarkan profil utuh sementara gesaan hilang. Pasang semula pemalam yang disokong dan bukan memadam faktor kedua supaya sambungan berfungsi.

Pustaka vendor boleh bersembunyi di sebalik ralat dasar

Satu corak patut dikenali kerana ia mengalahkan setiap pembaikan dasar. Alat konfigurasi vendor perkakasan boleh memasang pustaka OpenSSL sendiri dan meletakkannya di hadapan salinan sistem dalam laluan carian pemuat. Klien kemudian bermula terhadap pustaka yang tidak dinaik taraf oleh sesiapa, dan kegagalan permulaan kelihatan tepat seperti sijil yang ditolak.

Memasang semula pakej VPN tidak mengubah pustaka mana yang ditemui dahulu, dan menurunkan tahap TLS tidak dapat mencapai pustaka yang tidak pernah datang dari sistem. Tanya pemuat objek kripto mana yang benar-benar diselesaikan binari:

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

Alih keluar atau ubah hala salinan vendor, kemudian jalankan pemeriksaan yang sama sekali lagi. Versi yang dijangka mesti yang sedang digunakan sebelum anda kembali kepada profil.

Menyemat klien lama membeli masa, bukan penyelesaian

Mengekalkan versi klien sebelumnya memulihkan terowong selagi pengekalan berlangsung. Ia juga membekukan kemas kini keselamatan pakej itu dan menjadualkan kerosakan yang sama untuk peningkatan seterusnya, jadi anggap ia penyelesaian sementara bertarikh, bukan penyelesaian.

Jika anda tetap menyematkannya, kekalkan pakej secara jelas supaya peningkatan tanpa pengawasan tidak boleh membatalkan sematan, catat sebab dan tarikh untuk semakan semula, dan tetapkan peringatan untuk keluaran profil seterusnya daripada pembekal. Keadaan yang wajar dipantau ialah profil pelayan yang merundingkan sifer semasa; sebaik ia wujud, sematan tiada lagi justifikasi. Sematan yang tidak direkodkan pula menjadi gangguan yang tiada siapa dapat jelaskan enam bulan kemudian, kerana orang yang menerapkannya sudah beredar dan fail tidak merekodkan apa-apa.

Lain kali VPN mati selepas peningkatan keluaran, tanya lima soalan berturutan: lapisan mana menghasilkan ralat pertama, adakah dasar TLS menolak sijil, bolehkah sifer dirundingkan dalam kedua-dua arah, adakah pakej dan pemalamnya benar-benar dipasang, dan pustaka mana yang dimuatkan proses. Hanya selepas kelima-limanya kembali bersih barulah penurunan versi masuk akal.