Site VPN adreslerini yeniden numaralandırmadan ISS değiştirin

Bir şube internet sağlayıcısını değiştirir ve dosya sunucusu adresini korur. Bu sonuç yönlendirilmiş bir site VPN'de normaldir ve tünelin uç nokta adresini uygulamanın adresi sanan herkes için şaşırtıcıdır. İkisi tasarımın farklı katmanlarında yaşar ve yalnızca biri yer değiştirdi. Onları tek şey olarak ele almak, sağlayıcı geçişini bir yeniden numaralandırma projesine dönüştürür.

Bağımsız hareket eden iki adres planı

İç plan, uygulamaların kullandığı özel adresleri tanımlar: 10.55.8.20 adresindeki şube sunucusu, ona yönlendiren merkez ofis öneki ve geri dönüş yolu. Dış plan ise iki ağ geçidinin birbirine nasıl ulaştığını tanımlar: eş adresleri, dinleme bağlantı noktaları ve internet üzerinden izlenen yol.

Sağlayıcı değişikliği dış plana dokunur. Kendi başına iç planın değişmesini gerektirmez.

İki envanteri ayrı tutmak, uygulama kendi trafiğini zaten şifrelese bile bir kaplama ağı çalıştırmanın pratik nedenidir. Kaplama size dış dalgalanmaya dayanan kararlı bir iç topoloji verir. Uygulama adresini, güvenlik duvarı kurallarını ve DNS kayıtlarını korur. Yalnızca aktarım girdileri değişir ve bu çok daha küçük bir incelemedir.

Dış tünel iç konuşmayı taşır

Ağ geçidinden ağ geçidine bir tünelde dış IP başlığı iki ağ geçidini adresler. İç başlık ise hâlâ gerçek uygulama uç noktalarını adlandırır. RFC 7296'nın ağ geçidinden ağ geçidine tanımı bunu trafiği tünel uç noktaları üzerinden teslim eden olağan yönlendirme olarak ele alır.

Bu yüzden şube sunucusu ağ geçidinin genel adresi değişirken 10.55.8.20 adresini koruyabilir. İç paket sağlayıcının adresini hiç içermez.

Ayrım bir tasarım özelliğidir, otomatik bir garanti değil. Yedek üst bağlantı desteklenen tüneli kuramazsa ya da iç yollar yeniden kurulmazsa, adresi değişmese bile uygulama yolunu kaybeder.

Sağlayıcı geçişinin yine de bir kontrol listesi var

Dış kontrol listesinin beş maddesi vardır: eş adresi ya da bakımı yapılan ad, dinleyici ve varsa üst akış filtresi, yol üzerindeki çeviri, beklenen eş kimliği ve diğer ağ geçidinin izin verilen ayarları. Her biri tek başına başarısız olabilir. Yönetimi taşıyan bağlantıyı değiştirirken ayrı bir kurtarma yolu bulundurun. Üst bağlantı geçişi sırasında uzaktan erişimi kesmek, kendi yarattığınız bir kesintidir.

Ardından şube önekini, her iki yöndeki yolu, koruma ilkesini ve gerçek bir uygulama akışını denetleyin. Yeni kimlik doğrulaması yapılmış bir tünel, eski özel alt ağa işaret eden bir yolu düzeltmez.

Başka bir bağlı siteyle adres çakışması ayrı bir planlama sorunudur. Sağlayıcı değişikliği onu yaratmaz, ama genellikle ortaya çıktığı an geçiş dönemidir.

Ayakta kalmayanlar: genel kaynak ve oturumlar

Kararlı bir özel sunucu adresi, kararlı bir genel kaynak değildir. Tarama doğrudan yeni sağlayıcı üzerinden çıkarsa, web siteleri yeni sağlayıcıya bakan adresi görür.

O adresi kararlı tutmak, kendi kullanılabilirliği ve ilkesi olan bilinçli bir çıkış tasarımı gerektirir. Tünelle birlikte bedava gelmez.

Kurulmuş oturumlar da yol değişikliğinden sağ çıkmaz. Tünel saniyeler içinde yeniden kurulabilir ve yine de eski yola sabitlenmiş uzun ömürlü bağlantıları koparır. Geçişi, yeniden bağlanmaların kabul edilebilir olduğu bir zaman aralığına planlayın. Belirli istemciler ve onların zaman aşımları sınanmadıkça geçişin görünmez olacağını iddia etmeyin.

Geçişi dört denetimle doğrulayın

Değişiklikten sonra dört şeyi sırayla doğrulayın: tünel amaçlanan eşle kuruldu, şube önekine giden iç yol var, ilke uygulama akışına izin veriyor ve uygulama yanıt veriyor. Her birinin kendi komutu vardır.

Bir Linux ağ geçidinde bu üçü o listenin ortasını kapsar:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

Aktarım adreslerini bir envanterde, uygulama adreslerini başka bir envanterde tutun. Yalnızca gerçekten yer değiştiren girdileri güncelleyin. Tünelin dış adresi değişti diye iç bağımlılıkları yeniden numaralandırmak kaçınılabilir bir iştir.