VPN sitesi genişletmesi: ağ geçidinin ötesindeki dönüş yolunu izleyin

Bir şubeden gelen trafik, ulaşmanız istenen uygulamayı LAN'ında barındırmayan bir ağ geçidinde sonlanır. Sunucu, VPN'in hiç yapılandırmadığı bir iç bağlantının ötesindeki ikinci bir veri merkezindedir. Yakın ağ geçidine bir önek daha eklemek o durum için hiçbir şey yapmaz, çünkü uzak ağ geçidi son yönlendirici değil, bir şifreleme uç noktasıdır. Yolun ileri bir rotaya, uzak güvenlik sınırında bir kabul kararına ve hedefin kendi ağında bir dönüş kararına ihtiyacı vardır.

Uzak ağ geçidi bir şifreleme uç noktasıdır

Ağ geçitleri arası IPsec, iki güvenlik cihazı arasındaki trafiği korur ve iç adresler o segmentte şifrelenmiş olarak yol alır. Uzak ağ geçidinin ötesinde sıradan yönlendirme devreye girer, veri merkezleri arasında var olan her türlü politika dahil. Dolayısıyla korunan segment yolculuğun bir bölümünü kapsar, geri kalanını değil. Tersini varsaymak, bir tasarımın sağlıklı bir tünelle ve erişilemeyen bir uygulamayla sonlanma şeklidir.

Yolu üç parça halinde çizin: şubeden yakın ağ geçidine, yakından uzağa, uzak ağ geçidinden uygulamaya. Her parçanın kendi sahibi ve kendi arıza biçimi vardır.

Tünel politikasının iki yönünü de okuyun

Bir tünel politikası genellikle yerel tarafın bakış açısıyla yazılır ve kısmi yapılandırmalar tam da bu alışkanlıktan doğar. Her iki eş de şube kaynağını ve hedefi tünelin içinde görünecekleri biçimde listelemelidir; tasarımın amaçladığı her türlü dönüşüm dahil. Yalnızca yakın ucu güncellemek, yönlendirme arızası gibi görünen bir ikinci faz uyumsuzluğu üretir. Herhangi bir rotaya dokunmadan önce iki politika kümesini karşılaştırın.

Kaynağı ve hedefi site adları yerine adres olarak yazın. Buradaki belirsizlik daha sonra şaşırtıcı bir asimetri olarak yeniden ortaya çıkar.

İleri rotayı ekleyin ve kabulü doğrulayın

Uzak ağ geçidinin uygulama alt ağına doğru bir rotaya ihtiyacı vardır ve aralarındaki her yönlendirici şube kaynağını kabul etmelidir. Diyagramın iddia ettiğini değil, uzak ağ geçidinin gerçekte neye sahip olduğunu doğrulayın.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

İlk komut, uzak ağ geçidinin o kaynak için seçeceği çıkış arayüzünü ve sonraki atlamayı bildirir; bu, sıradan bir yönlendirme tablosunun yanıtlayamayacağı bir sorudur. İz, paketlerin nerede durduğunu gösterir ve uzak ağ geçidinden sonraki bir kopma tünele değil, iç geçişe işaret eder. Rota varsa ve trafik yine de kayboluyorsa, uzak ağ geçidinde yakalayın ve gelen kaynak adresini okuyun, çünkü beklenmeyen bir adres bir yerde plansız bir dönüşüm olduğu anlamına gelir. Buradaki tüm adresler yer tutucudur, bu yüzden gerçek şube, geçiş ve uygulama alt ağlarıyla değiştirin.

Şubeden test edin, ardından eski yolu yeniden test edin

Kabul, uzak ağ geçidinden bir sonda değil, gerçek bir kaynak gerektirir. Kontrolü şubedeki bir ana bilgisayardan çalıştırın ve daha önce çalışan hedefleri aynı testte tutun.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

Uygulamadan gelen yanıt, ileri yolu ve dönüş yolunu birlikte kanıtlar; eski hedefe yapılan ping ise değişikliğin zaten çalışanı bozmadığını kanıtlar. Uygulamanın kaydettiği kaynak adresini yakalayın, çünkü erişim kuralları ve herhangi bir dönüş rotası bu değerle eşleşmelidir. Şubenin tünelden önce dönüşüm yaptığı yerde, politika adresi ile uygulamanın gördüğü adres tasarım gereği farklıdır, bu yüzden ikisini de kaydedin. Anahtar yenilemesinden veya yönlendirme değişikliğinden sonra testi tekrarlayın, çünkü bu yollar genellikle bir kez doğrulanır ve sonra unutulur.

Üç segmentin her birine ve hedef ağ içindeki dönüş rotasına bir sahip atayın. Dört sahibi olan bir yol aralarındaki boşluklarda başarısız olur.