Ağ değiştiğinde MOBIKE IKEv2 VPN'i nasıl ayakta tutar

Bir telefon Wi-Fi'dan ayrılıp hücresel ağa katılır, bir dizüstü bilgisayar Ethernet'ten hotspot'a geçer ve IKEv2 tüneli ya hayatta kalır ya kalmaz. MOBIKE, baştan başlamak yerine kaynak adresin değiştiğini uzak uca bildirerek tünelin hayatta kalmasını sağlayan uzantıdır. Yapmadığı şey, değişim boyunca her uygulamayı canlı tutmaktır. Bunlar iki iddiadır ve insanların genellikle kastettiği ikincisidir.

Geçişi aşamalar hâlinde inceleyin, çünkü her aşama farklı şekilde başarısız olur.

Güncelleme gerçekte neyi değiştirir

Güvenlik ilişkisi hâlâ geçerliyken başlatıcı yeni adresini öğrenir ve yanıtlayıcıya bir güncelleme gönderir; yanıtlayıcı da bu adresi aynı ilişki için kullanır. Güvenlik parametreleri sıfırdan yeniden müzakere edilmez. Bütün fayda budur: yeni bir kimlik doğrulama turu yok, yeni bir anahtar değişimi yok, kullanıcıya bir soru yok. Bu aynı zamanda hayatta kalan durumun hâlâ eski oturuma ait olduğu anlamına gelir.

MOBIKE trafiği UDP kapsüllemesine de taşıyabilir; bu yüzden çalışan bir tünel bazen ağ değişikliğinden sonra 4500 numaralı bağlantı noktasını kullanmaya başlar. Bu geçiş tek başına NAT'ın algılandığını kanıtlamaz, ancak ikisi sıklıkla birlikte görünür.

Profiliniz bunu gerçekten etkinleştiriyor

Her iki taraf da uzantıyı desteklemeli ve dağıtım onu etkinleştirmelidir. strongSwan'da davranış bağlantı başına yapılandırılabilir ve arayüz ya da rota değişiklikleri gerektiğinde bir yol aramasını ve güncellemeyi tetikleyebilir. Her IKEv2 profilinin bunu açtığını varsaymak yerine bağlantının gerçek ayarlarını inceleyin. Bu özellikten önce yazılmış bir kılavuzdan kopyalanan profil bunun yaygın bir nedenidir.

İki uçta müzakere edilen durum otoritedir, ürün ailesinin belgeleri değil.

Geçişi aşamalar hâlinde inceleyin

Ağları değiştirmeden önce uygulamanın durumunu kaydedin. Sonra değiştirin ve ardından istemcinin ve sunucunun durumunu kaydedin. Eksik bir adres, ulaşılamayan bir eş ve kendi oturumunu yeniden bağlaması gereken bir uygulama üç farklı sonuçtur. Yalnızca ilk ikisi VPN katmanına aittir; üçüncüsü uygulamanın konuştuğu protokole aittir.

Bir ağ geçişini durağan bir testle karşılaştırın, böylece hangi olayın sorunu tetiklediğini bilirsiniz. Son ağdaki aktarım hızı ölçümü bir geçişi yeniden üretemez. Varış noktasını ölçer, yolculuğu değil.

Arıza katmanlarını ayırın

Uzun ömürlü bir TCP oturumu IKEv2 alışverişinin dışındaki nedenlerle başarısız olabilir. Yeni ağ farklı filtreleyebilir, farklı çözümleyebilir veya farklı yönlendirebilir. Tünel adresi hiç değişmeyebilir, altındaki yol değişirken. Bu yüzden uygulamanın yeniden bağlanması VPN'in hiç bozmadığı bir şeyi düzeltebilir.

Kurtarma sırasında da engelleme politikasını yerinde tutun.

Otomatik hareketlilik ile doğrudan trafiği engelleyen kural farklı denetimlerdir ve birincisinin çalışması için ikincisini kapatmak kötü bir takastır. Hareketlilik güncellemesi başarısız olursa engel, tünelin çevresine trafik sızdırmak yerine ayakta kalmalıdır.

Tekrarlandığında ne kaydedilmeli

Her iki taraftan zaman damgalarını ve iki adres değerini saklayın. Bu kayıt, güncellemenin uygulama teması kaybetmeden önce tamamlanıp tamamlanmadığını gösterir; bu da bir hareketlilik hatası ile uygulama zaman aşımı arasındaki farktır. Ardından geçiş yönünü karşılaştırın: Wi-Fi'dan hücresel ağa çıkmak bunun tersiyle simetrik değildir. Bir yön çalışırken diğeri başarısız olabilir.

Bu asimetri, ilk test edilmesi gereken şey olacak kadar yaygındır.

Kayıt eldeyken olay artık başka bir bağlantısı kesilmiş simge olmaktan çıkar ve bilinen bir sahibi olan bir dizide tek bir olay hâline gelir. Ve bir geçişin dürüstçe vaat edebileceği tek şey budur.