IPsec Lab Phase-3

SD-WAN Olmadan Hat Yedekliliği (Failover): Manuel IPsec ve MPLS Senaryosu

Serimizin bu bölümünde, laboratuvar ortamımızda çok önemli bir evreye geçiyoruz. Hatırlayacağınız üzere bir önceki dersimizde, merkez (HQ) ve şube (BRANCH) lokasyonlarımız arasında tek bir hat üzerinden IPsec VPN tünellerimizi inşa etmiştik.

Bu dersimizde ise yapıyı gerçeğe daha yakın ve yedekli bir mimariye kavuşturuyoruz: SD-WAN teknolojisi kullanmadan, tamamen geleneksel yönlendirme yöntemleriyle ikinci bir yedek hat yapılandıracağız ve bir Failover (Hattan hatta otomatik geçiş) senaryosu uygulayacağız.

Senaryomuzun nihai amacı; LAN networklerindeki bilgisayarlar (VPC) arasında kesintisiz bir ping (ping -t) trafiği başlatmak, ardından ana hattı (Main Network) manuel olarak devre dışı bırakıp (disable), trafiğin yedek tünele ne kadar sürede geçeceğini, kaç paket kaybı yaşanacağını ve SD-WAN olmadan bu geçişi yönetmenin dezavantajlarını canlı canlı gözlemlemek.

Edit kısmına geliyoruz.

Ethernet kısmını 5 yapıp cihazı PnetLab üzerinde stop-start yapıyoruz.

Topolojimiz yukarıdaki gibi olacak şekilde yapılandırıyoruz.

ISP INTERFACE YAPILANDIRMASI

HQ INTERFACE YAPILANDIRMASI

BRANCH INTERFACE YAPILANDIRMASI

Yukarıdaki görsellerde de adım adım gösterdiğim gibi, öncelikle her iki lokasyonumuzdaki Firewall cihazlarımızın ilgili portlarına topolojimize uygun IP adreslerini tanımladık ve ISP bacaklarımızın karşılıklı olarak birbirini pingleyebildiğini (Ping Check) doğruladık.

Arayüz bağlantılarımızı başarıyla sağladıktan sonra, şimdi operasyonun en kritik aşamalarından birine geçiyoruz: Statik Rotaların (Static Route) Yapılandırılması.

Neden Statik Rota Yazıyoruz? (Default Route Mantığı)

“Arayüzlere IP verdik, cihazlar birbirini pingliyor, o halde LAN networkleri neden hâlâ haberleşemiyor?” sorusu, networke yeni başlayanların en sık karşılaştığı çıkmazlardan biridir. Gelin, statik rota yazmadan önce arka plandaki mantığı inceleyelim:

Mevcut yapımızda, cihazlarımızın üzerinde tanımlı olan tek bir varsayılan rota (Default Route — 0.0.0.0/0) bulunur. Bu rota şu anlama gelir: Cihaz, kendi üzerinde doğrudan tanımlı olmayan bir hedef ağa gitmek istediğinde, kaynak ne olursa olsun bu trafiği tek bir çıkış kapısına yönlendirir.

• HQ (Merkez) Tarafında: Varsayılan rota, tüm trafiği doğrudan 30.30.30.2/30 (ISP port2) adresine soruyor.
• BRANCH (Şube) Tarafında: Varsayılan rota, tüm trafiği doğrudan 40.40.40.1/30 (ISP port4) adresine soruyor.

Gördüğünüz gibi, cihazlar hedefteki iç ağların (LAN networklerinin) nerede olduğunu henüz bilmiyor. Eğer şu anda statik bir rota yazmadan karşı taraftaki LAN networküne ping atmayı denerseniz, trafiğin hedefe ulaşamadığını ve paketin drop olduğunu göreceksiniz.

İşte bu yüzden; cihazlarımıza karşı tarafın yerel ağ haritasını tanıtmak, trafiğin hangi hattan (MPLS mi yoksa IPsec tüneli mi) akacağını belirlemek ve en önemlisi SD-WAN olmadan failover (yedeklilik) mekanizmasını kurabilmek için statik rotalarımızı manuel olarak yazmak zorundayız.

BRANCH firewall’ una HQ firewall’ umun MPLS bacağını verip search ediyorum.

Gördüğünüz gibi paket 40.40.40.0/30 bacağına gidiyor.

Bu bacağa gittiği içinde paket yolunu bulamayacaktır.

HQ-BRANCH Static Route

Yukarıdaki gibi static rotalarımızı yazıyoruz ve ISP firewall’ umuza gelip MPLS bacaklarımız için kural yazıyoruz

Her zaman iki taraflı iletişimlerde reverse policy konumlandırmayı unutmamak gerekiyor.

Ve BRANCH’ten HQ firewall’un MPLS bacağını pinglediğimizde pingin gittiğini görüyoruz.

Bu durumda artık tünellerimizi oluşturabiliriz.

HQ_TO_BRANCH_MPLS TÜNEL-STATIC ROUTE

POLICY

1. IPsec Tünel Yapılandırması

Bu aşamada yedek hattımız için IPsec tünel kurulumunu gerçekleştiriyoruz. Local Gateway ve Remote Gateway adres alanlarını bu senaryoya özel olarak “Default” (0.0.0.0/0) olarak bıraktım. Bu yaklaşım, tünelin karşı taraftaki tüm network bloklarını kapsamasını sağlayarak esneklik kazandırıyor.

2. Statik Rota (Static Route) ve Öncelik Ayarı

Tünel arayüzü oluştuktan sonra trafiği bu tünele yönlendirmek için statik rota tanımı yapıyoruz. Ancak sistemde zaten 70.70.70.0/24 subnetine doğru giden mevcut (birinci) bir rotamız bulunuyor.

Yeni oluşturduğumuz bu rotanın doğrudan devreye girmemesi ve yedek (backup) hat olarak beklemesi için Administrative Distance (Mesafe) değerini 11 olarak yapılandırdım. Böylece ana hattın mesafesi daha düşük (öncelikli) kalacak, bu tünel ise yalnızca ana hat koptuğunda trafiği devralacaktır.

3. Firewall Politikaları (Policy Optimization)

Son olarak, oluşturduğumuz yedek tünel üzerinden veri trafiğinin geçebilmesi için firewall kurallarını tanımlıyoruz. Güvenlik duvarı üzerinde hem merkezden şubeye hem de şubeden merkeze olacak şekilde çift yönlü (Inbound/Outbound) kuralları yazarak paket geçişlerini güvenli bir şekilde sağladık.

Yeni kurduğumuz tünelde artık ayakta

Tüm yapılandırmalarımızı tamamladığımıza göre, artık senaryomuzun asıl amacına ulaşabiliriz. Statik rotalarda verdiğimiz mesafe (distance) değerlerinin ve manuel yedeklilik mimarisinin canlı ortamda nasıl tepki verdiğini hep birlikte ölçeceğiz.

1. Trafiğin Başlatılması

İlk olarak, HQ tarafındaki 60.60.60.2 IP adresli cihazımızdan, BRANCH tarafındaki 70.70.70.2 yerel IP adresine doğru sürekli bir ping (ping 70.70.70.2 -t) başlatıyoruz. Şu anda paketlerimizin ana hat üzerinden sorunsuz bir şekilde karşı tarafa ulaştığını ve yanıt döndüğünü görüyoruz.

2. Yapay Kesinti Oluşturma (Simülasyon)

Ana hattın kopma anını simüle etmek ve trafiğin otomatik olarak mesafe (distance) değerini 11 yaptığımız yedek IPsec tüneline ne zaman geçeceğini gözlemlemek için kuralları devre dışı bırakıyoruz. Bu doğrultuda, HQ (Merkez) firewall cihazı üzerinde BRANCH yönüne doğru çalışan mevcut iki ana kuralımı (Policy) “Disable” konuma getiriyorum.

HQ üzerindeki kuralları devre dışı bıraktığımız andan itibaren ping ekranımızı takip ettiğimizde, tam 5 paketlik bir kayıp (Timeout) yaşandığını, ardından trafiğin otomatik olarak mesafe (distance) değerini 11 verdiğimiz yedek IPsec tüneline başarıyla geçtiğini gözlemledik.

Laboratuvar ortamımızda bu geçiş her ne kadar hızlı gerçekleşmiş gibi görünse de gerçek dünya senaryolarında, saha koşullarında ve yoğun trafik altında bu süreler her zaman bu kadar şanslı veya hızlı olmayabiliyor. Bazen cihazların rotayı düşürmesi ve tüneli ayağa kaldırması çok daha uzun süreler alabiliyor, bu da kullanıcı tarafında hissedilir kesintilere yol açıyor.

Peki bu yöntem tamamen kullanışsız mı? Tabii ki hayır. Elinizde SD-WAN lisansı veya bu teknolojiyi destekleyen uygun bir altyapı/donanım bulunmadığı durumlarda, operasyonun tamamen durmasını engellemek adına bu geleneksel statik yöntemle yedekli bir yapı inşa edebilir ve iş sürekliliğini kurtarabilirsiniz.

Ancak günümüz network mimarilerinde her zaman önceliğimiz, hatları sadece kopma anında değil, performans kayıplarında da akıllıca yöneten SD-WAN teknolojisini kullanmaktır.

Tam da bu sebepten dolayı, serimizin bir sonraki fazında (FAZ-4) geleneksel yöntemleri bir kenara bırakacak; SD-WAN teknolojisinin temellerinden, işleyiş mantığından bahsedecek ve laboratuvar ortamımızda adım adım SD-WAN yapılandırmasını gerçekleştireceğiz..

TEŞEKKÜRLER…..