Ubuntu yükseltmesinden sonra OpenVPN neden bağlanmayı bıraktı?

Geçen hafta çalışan VPN profilleri bir Ubuntu sürüm yükseltmesinden sonra bozuluyor ve günlük yükseltmeden neredeyse hiç söz etmiyor. Adını verdiği şey, başarısız olan katmandır: TLS el sıkışması, veri kanalı için anlaşılan şifre, kurulan paket veya ikilinin başlangıçta yüklediği OpenSSL kopyası. Her katmanın kendi hata biçimi ve kendi onarımı vardır; bu yüzden sınıflandırma ilk iş, düzenleme ikinci iştir. Günlük adını verene kadar profili masum sayın.

Hangi katman başarısız oldu: el sıkışması, şifre, paket veya kütüphane

Profille oynamadan önce istemci günlüğünü okuyun. Çıktıdaki en erken hata katmanı tanımlayan hatadır; ondan sonra yazılan her şey genellikle o ilk başarısızlığın sonucudur. İstemci hiç başlamıyorsa, VPN günlüğü açılacak yanlış dosyadır.

Sertifika ve imza şikayetleri ya da anahtar uzunluğuyla ilgili bir ileti denetim kanalından ve onu yöneten kütüphane politikasından gelir. DEPRECATED OPTION ile başlayan bir uyarı ise bunun yerine veri kanalı anlaşmasına aittir.

Böyle bir satır Unrecognized option üçüncü kategoridir: yeni ikili, eskinin tolere ettiği bir direktifi artık kabul etmiyor, bu yüzden kütüphaneyi gevşetmek yerine profili yeniden yazmak gerekir. Paket arızaları yine farklı görünür çünkü herhangi bir tünel kodu çalışmadan önce olurlar. Eksik ikili, yüklenmeyen eklenti veya yanlış kod adını gösteren depo hep o biçimi verir. Dört belirti, bakılacak dört yer ve onarımlar arasında neredeyse hiç örtüşme yok.

El sıkışması başarısız olduğunda TLS politikası sertifikayı reddeder

Ubuntu 22.04 sistemi OpenSSL 3'e taşıdı ve o daldaki varsayılan güvenlik düzeyi sertifika imzaları ve anahtar boyutları konusunda 20.04'ten daha katı. Daha eski bir özetle imzalanmış CA sertifikası veya mevcut eşiğin altındaki anahtar artık el sıkışması sırasında başarısız oluyor. Henüz hiçbir şey kimlik doğrulamadığı için hata yanlış parola veya ölü sunucu gibi okunur.

Dar onarım, şifre dizisini yalnızca bu bağlantıya bağlar. Masaüstü düzenleyicide profili açın, gelişmiş ayarlara geçin ve DEFAULT:@SECLEVEL=0 değerini TLS şifre alanına koyun. NetworkManager anahtar dosyası [vpn] altında aynı değeri alır:

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

NetworkManager'ı yeniden başlatın ve yeniden bağlanın, çünkü arka plan süreci ayrıştırılmış profilleri önbelleğe alır ve aksi hâlde elindeki kopyayı kullanmayı sürdürür. Satırın ne yaptığını tutmadan önce bilin: bu ayar şifre adı değil, birkaç sertifika ve anahtar parametresi üzerinde bir eşiktir; düşürmek tek profilin kabul ettiği alanı genişletir. Hangi sunucunun bunu gerektirdiğini not edin ve operatör güncel malzemeyi yeniden yayımladığında ayarı bırakın. /etc/ssl/openssl.cnf değerini değiştirmek ise o dosyayı okuyan her program için aynı eşiğe ulaşır, bu da VPN'in çok ötesindedir.

OpenVPN 2.6 şifrenin anlaşma için listelenmesini gerektirir

Ubuntu 22.10 OpenVPN 2.6 ile geldi ve o sürümde --cipher veri kanalını kendi başına seçmeyi bırakır. Şifre ayrıca anlaşılan data-ciphers listesinde de bulunmalıdır, yoksa istemci kullanımdan kalkma uyarısı basar ve ardından tüneli kaldıramaz.

Aynı dönemin NetworkManager eklentisi hâlâ yalnızca eski direktifi yazıyordu. Bu ayrıntı tanıyı böler, çünkü elle düzeltilmiş bir profil kabuktan bağlanıp masaüstü uygulamasından yine başarısız olabilir. Listeyi bağlantı dosyasına [vpn] altında ekleyin:

data-ciphers=AES-256-CBC

Sunucunun duyurduğu değeri kullanın, hatırladığınızı değil; AES-256-GCM sunan bir sunucu yalnızca CBC adlandıran istemci listesiyle anlaşmaz. Yöneticiyi yeniden başlatın ve yeniden bağlanın, sonra kabuktan denemeyi yineleyin ve şifreyi hem anlaşma hem yedek için açıkça verin:

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

Bu komut tüneli kaldırırsa sunucu, sertifikalar ve kimlik bilgileri sağlamdır ve kalan tek kusur yöneticinin sakladığı seçenektir. keysize direktifiyle ilgili uyarı da aynı temizliğe aittir: yorum satırı yapın ve özgün dosyayı profilin yanında tutun.

Paket ve eklenti arızaları VPN arızaları gibi görünür

Yükseltmeden sonraki her başarısızlık kriptografik değildir. Sürümün kullanmadığı bir kod adı altında eklenen OpenVPN deposu hiç kurulmayan bir paket üretir, bu yüzden lsb_release -a ne bildirdiğini eklediğiniz liste dosyasıyla karşılaştırın. Eksik universe bileşeni veya güvenlik cebi hiç bulunamayan bir paket üretir. İki durumda da profil dokunulmamış, tünel olanaksız kalır.

VPN günlüğünden önce paket yöneticisinin hatasını okuyun. İstemci hiç kurulmadıysa hiçbir profil düzenlemesi el sıkışması üretmez.

Sormayı bırakan iki faktörlü profiller aynı hikâyenin eklenti sürümüdür. Meydan okuma bir kimlik doğrulama eklentisinden gelir ve onu düşüren veya değiştiren yükseltme profili sağlam bırakırken istem kaybolur. Bağlantının çalışması için ikinci faktörü silmek yerine desteklenen eklentiyi yeniden kurun.

Bir satıcı kütüphanesi politika hatasının arkasına gizlenebilir

Bir örüntü tanınmayı hak ediyor çünkü her politika onarımını alt ediyor. Bir donanım satıcısının yapılandırma aracı kendi OpenSSL kütüphanelerini kurup yükleyicinin arama yolunda sistem kopyalarının önüne koyabilir. İstemci sonra kimsenin yükseltmediği bir kütüphaneye karşı başlar ve başlangıç arızası tam olarak reddedilmiş bir sertifika gibi görünür.

VPN paketini yeniden kurmak hangi kütüphanenin önce bulunacağını değiştirmez ve TLS düzeyini düşürmek sistemden hiç gelmemiş bir kütüphaneye ulaşamaz. Yükleyiciye ikilinin gerçekte hangi kripto nesnelerini çözdüğünü sorun:

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

Satıcı kopyasını kaldırın veya yeniden yönlendirin, sonra aynı denetimi yeniden çalıştırın. Beklenen sürüm, profile dönmeden önce kullanımda olan sürüm olmalıdır.

Eski bir istemciyi sabitlemek zaman kazandırır, çözüm değildir

Önceki istemci sürümünü elde tutmak, tutma sürdükçe tüneli geri getirir. Aynı zamanda o paketin güvenlik güncellemelerini dondurur ve aynı kırılmayı bir sonraki yükseltmeye planlar, bu yüzden bunu çözüm değil tarihli bir geçici önlem olarak görün.

Yine de sabitlerseniz, denetimsiz bir yükseltmenin sabitlemeyi geri alamaması için paketi açıkça tutun, nedeni ve gözden geçirme tarihini yazın ve sağlayıcının bir sonraki profil sürümü için hatırlatıcı kurun. İzlenmeye değer koşul, güncel bir şifre üzerinde anlaşan sunucu profilidir; o var olduğunda sabitlemenin hiçbir gerekçesi kalmaz. Kaydedilmemiş bir sabitleme ise altı ay sonra kimsenin açıklayamayacağı bir kesintiye dönüşür, çünkü uygulayan kişi gitmiştir ve dosya hiçbir şey kaydetmez.

Bir dahaki sefere bir VPN sürüm yükseltmesinden sonra öldüğünde beş soruyu sırayla sorun: hangi katman ilk hatayı verdi, TLS politikası sertifikayı reddetti mi, şifre iki yönde de anlaşılabilir mi, paket ve eklentisi gerçekten kuruldu mu ve süreç hangi kütüphaneyi yüklüyor. Ancak beşi de temiz döndüğünde sürüm düşürmenin anlamı olur.