OpenVPN mi IKEv2 mi: protokol seçmeden önce dört kontrol

OpenVPN ile IKEv2 arasındaki seçim genellikle bir protokol sorusu olarak tartışılır ve bu çerçeve kararı boşa harcar. Kararı veren, sunucunuzun ve cihazlarınızın aynı eksiksiz profili destekleyip desteklemediği ve o profilin ağlar arasında hareket etme biçiminize dayanıp dayanmadığıdır. İki yığın birbirine dönüşmez: bir OVPN dosyası farklı sözdizimine sahip bir IKEv2 profili değildir. Sırayla yapılan dört kontrol, soruyu herhangi bir özellik tablosundan daha hızlı yanıtlar.

Eksik istemci tartışmayı bitirir

Windows ve macOS bir IKEv2 istemcisiyle gelir, bu yüzden bir IKEv2 profili orada dağıtım için ek maliyet getirmez ve işletim sisteminin zaten sunduğu sağlama seçeneklerini devralır. Aynı makinelerde OpenVPN, kurulması, güncellenmesi ve desteklenmesi gereken üçüncü taraf bir istemci anlamına gelir ve bu istemci profilin kullandığı her seçeneği kabul etmelidir. Başka herhangi bir şeyi karşılaştırmadan önce kapsamanız gereken platformları sayın, çünkü çalışan istemcisi olmayan bir platform karşılaştırma noktası bile değildir.

Windows'ta tek bir komut zaten var olan profilleri listeler ve her birinin hangi türde olduğunu gösterir. Yazdırdığı ad, sonraki kontrollerin kullandığı addır.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

İstemci kurulumu istemi, o platformlarda OpenVPN sütununun gerçek yanıtıdır ve bu protokol sınırlaması değil, dağıtım görevidir. Düzenlemelerin hiçbiri güven kontrollerini, kimlik doğrulamayı veya bakımı ortadan kaldırmaz. Taahhüt vermeden önce profillerin nasıl dağıtıldığını, kimlik bilgilerinin nasıl yenilendiğini ve kayıp bir cihazın nasıl kaldırıldığını sorun. Basit bir kurulum bile hafta sonu kimsenin çalıştırmak istemediği bir kurtarma sürecini saklayabilir.

Hareketlilik ortak bir ayardır, protokol vaadi değil

IKEv2, her iki uç da MOBIKE'ı destekleyip etkinleştirdiğinde onu kullanabilir; bu, istemcinin adresi değişirken tünelini korumasını sağlar. RFC 4555 bu uzantıyı tanımlar ve koşullu ifade önemlidir: bu yeteneği yok sayan sunucu bunun yerine yeniden müzakere eder. Sonuç bir dosya aktarımı için aynı, canlı bir çağrı için çok farklı görünebilir.

Gerçekten önemsediğiniz geçişi, izleyebileceğiniz bir şey çalışırken test edin. Windows'ta ping -t <internal-host> çalışmaya devam etsin, başka yerde düz ping, sonra Wi-Fi'den hücresele geçin ve boşlukları izleyin. MOBIKE hatası istemci günlüğünde sessiz bir adres güncellemesi olarak değil, tam yeniden kimlik doğrulama olarak görünür. Ölçtüğünüz şey tünelin değişime dayanıp dayanmadığıdır, protokolün destek duyurup duyurmadığı değil.

OpenVPN istemcileri kendi platform davranışlarına ve profil zamanlayıcılarına göre yeniden bağlanır, bu yüzden aynı test farklı bir kesinti biçimi üretebilir. Protokoldeki etiketi değil, kullanıcılarınız için önemli olan olayı karşılaştırın.

Kimlik bilgileri hizmete aittir, yığına değil

Sertifikalar ve diğer oturum açma düzenlemeleri bağlantıyı sonlandıran hizmete aittir. Bir istemcideki parola istemi başka bir istemciyle uyumluluk hakkında hiçbir şey söylemez ve başka bir ağ geçidine karşı çalışan bir profil bunun hakkında hiçbir şey söylemez. İki yığını karşılaştırırken sunucu kimliği kurallarını olduğu gibi koruyun. Arızayı belirlemeden protokol değiştirmek genellikle ikinci bir uyumsuz profil üretir.

Hangi protokolü suçlamadan önce istemcinin sunacağı kimlik bilgisini inceleyin, çünkü süresi dolmuş veya yanlış verilmiş bir sertifika ikisinde de aynı şekilde başarısız olur. Aşağıdaki çıktı özel anahtarı okumadan konu, veren ve geçerlilik tarihlerini gösterir.

openssl x509 -in client.crt -noout -subject -issuer -dates

Şirket bağlantısı için şirketin yayımladığı yöntemi kullanın ve karşılaştırmayı bir deney olarak görmeyi bırakın. İkisini kendiniz karşılaştırıyorsanız, önce iki seçeneğin de aynı ağ geçidinde bitip bitmediğini kontrol edin, çünkü sonucunuzun ne kadarının protokolle ilgili olduğunu bu tek ayrıntı belirler. Kimlik bilgisini adlandıran bir ret, kimlik bilgisi sorunudur ve hiçbir protokol değişikliği onu onarmaz.

Tünelin gerçekte neyi yönlendirdiğini kontrol edin

Bağlandıktan sonra ihtiyacınız olan rotanın var olduğunu ve adların çözüldüğünü doğrulayın. İç kaynaklar için var olan bir profil, normal gezinmeyi kasıtlı olarak yerel yolda bırakabilir ve bu bir politik karardır, arıza değil. Önemli olan, ekibinizin kullandığı hedeflere tünel üzerinden ulaşılıp ulaşılamadığıdır.

Windows'ta iki komut rotayı ve ad aramasını kapsar. Linux karşılıkları ip route show default ve resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

Ayağa kalkıp yararlı hiçbir şeyi yönlendirmeyen bir tünel, bir profil hizmetler arasında kopyalandığında sık görülen bir sonuçtur ve genel bağlantı testi bunu göstermez çünkü arayüz ayaktadır. Kullanıcılarınızın ilk açtığı kaynağı test edin, herhangi bir yolun ulaşabileceği genel bir adresi değil. Ad genel bir adrese çözülürken rota tünelin içini gösteriyorsa, DNS yanıtı ve rota farklı kararlara aittir ve ikisi de düzeltilmelidir.

Kontrollerden sonra bakımı tartın

Soyut anlamda hiçbir protokol diğerinden daha kolay bakımı yapılabilir değildir. Bakım, ağ geçidini kimin işlettiğine, profillerin cihazlara nasıl ulaştığına ve kayıp bir cihazın erişimi ne kadar hızlı kaybettiğine bağlıdır. Basit bir uç istemci, işletmesi daha zor bir sunucunun önünde durabilir ve bunun tersi de olur. Onu kuran kişi ayrıldıktan sonra ekibinizin ikisinden hangisini çalıştırmaya devam edebileceğini sorun.

İşi kapsayan desteklenen bağlantıyı seçin, sonra onu özellik listesine değil gerçekten ihtiyaç duyduğunuz erişime karşı test edin. Her seçeneğin hangi ağ geçidinde bittiğini kaydedin, çünkü iki farklı ağ geçidi karşılaştırmayı protokoller kadar rotalar hakkında da yapar. Dört kontrolü gerçekten taşıyacağınız cihazda yineleyin ve onda geçen profili saklayın.