opt-verify eklemek OpenVPN şifreleme hatanızı neden düzeltmez

Bir öneri bulup opt-verify ekliyorsunuz, satırı ekliyorsunuz ve şifreleme hatası tam olarak olduğu yerde kalıyor. Bu sonuç öngörülebilir, çünkü seçenek hiçbir zaman bir şifreleme müzakere etmedi. Bu, 2.6'da kullanımdan kaldırılan ve 2.7'de silinen bir seçenek tutarlılığı denetimiydi ve onunla hâlâ ayrıştırılan bir profil bununla hiçbir şey uygulamış olmuyor.

Satırın eskiden ne yaptığını bilmek, onun eksik parça olduğu sonucuna varmadan önce yardımcı olur. Tarihçe, şimdi neden yardımcı olamayacağını da açıklar.

Seçeneğin eskiden ne uyguladığı

2.6 kılavuzu opt-verify seçeneğini kullanımdan kaldırılmış olarak işaretler ve önceki davranışı açıklar: sunucu, bildirdiği seçenekleri kendininkilerle eşleşmeyen istemcileri düşürür; cihaz türü ve MTU gibi şeyleri karşılaştırır. Bu denetim, seçenek tutarlılığı denetiminin açık kalmasına da bağlıdır, bu yüzden disable-occ ile çalışan bir sunucuda o hiç olmamıştır. Karşılaştırmanın neden kurulduğuna dikkat edin: karşı tarafın yapılandırmasını tanımlayan metinden. Veri kanalının hangi şifrelemeyi kullanacağı hakkında hiçbir şey söylemez.

Bayrağın bir şifreleme hatasını onaramamasının ilk nedeni budur. Şifreleme seçimi data-ciphers politikası ve her iki tarafın desteklediği şeyler tarafından yönetilir; metinsel bir tutarlılık denetimi ne bu listeyi genişletir ne de müzakereyi gerçekleştirir. İkinci neden kapsamdır: denetim, bildirilen seçeneklerin uyumlu görünüp görünmediğiyle ilgilidir, ortaya çıkan yolun kalitesiyle değil.

2.7 satırı görünce ne yapar

2.7'de seçenek yok. Ayrıştırıcı adı hâlâ tanır, bu yüzden eski bir profil sözdizimi hatası olmadan yüklenir ve seçeneğin kaldırıldığını bildirir, sessizce atlamaz. Bir adı tanımak ile bir davranışı uygulamak farklı şeylerdir ve şu anda yalnızca ilki oluyor. Kaldırma notları nedeni verir: parametreler müzakere edilebilir hale geldiğinde, iki taraf bağlantı üzerinde anlaşırken meşru olarak farklı seçenek dizelerine sahip olabilir.

Bu nedenle ayrıştırılan bir profil, herhangi bir kabul denetiminin çalıştırıldığının kanıtı değildir. Tek sinyaliniz istemcinin bağlandığıysa, sözdiziminin kabul edildiğini öğrenmişsinizdir.

Arıza gerçekte nerede yaşıyor

Herhangi bir şeyi değiştirmeden önce ilk somut hatayı saklayın, çünkü sonraki iletiler genellikle onun sonuçlarıdır. Veri kanalı müzakere hatası onaylanmış şifreleme politikasına ve her iki tarafın gerçekten duyurduğu yeteneklere aittir. TLS sürüm veya paket hatası kontrol kanalına aittir. Bir sertifika reddi kimliği ve güven zincirini gerektirir, uyumluluk bayrağını değil.

Her iki uçtaki motoru da belirleyin. Bir masaüstü uygulaması, test ettiğiniz komut satırı ikiliden farklı bir derleme içerebilir ve seçenek desteği aralarında farklıdır. Bir profili içe aktaran her programın aynı davrandığını varsaymak yerine o motorun belgelerine bakın.

Yalnızca satırı değil, niyeti de değiştirin

Eski bir yönetilen sunucu gerçekten tutarlılık denetimine dayanıyorsa, yükseltmeden önce hangi kısıtlamayı uyguladığını not edin. Daha yeni bir profilde yok sayılan bir seçeneği tutmak bu politikayı koruyamaz, satırları gelişigüzel silmek de koruyamaz.

Tüm şifrelemelerin devre dışı olduğu yönündeki eski bir öneriye her tarihsel algoritmayı etkinleştirerek yanıt vermeyin.

Onaylanmış bir düzeltmeden sonra, yeni bir bağlantıda müzakere edilen sonuçları inceleyin ve kullanıcının gerçekten ihtiyaç duyduğu uygulamayı test edin. Sunucu sürümünü ve geçerli politikayı o sonucun yanında tutun, böylece sonraki kişi yalnızca neyin kabul edildiğini değil neyin kararlaştırıldığını görsün.

Amaç, hâlâ ayrıştırılan eski bir bayrak değil, desteklenen bir kısıtlama ve çalışan kimliği doğrulanmış bir yoldur.