VPN High Availability

Merhaba

Son yazımı 2013’te görüşürüz diye bitirip Mart ayına kadar beklediğimi fark edince uzun bir yazı yazmaya kadar verdim 🙂 Bu yazımı şimdiye kadar basitlik adına hiç değinmediğim bir konuya, VPN bağlantılarında yedekliliğe ayıracağım ve çeşitli yedeklilik konfigürasyonlarını inceleyeceğiz.

Öncelikle link yedekliliğini inceleyelim. VPN tünelini sonlandırdığımız router’lar birbirlerine farklı interface’lerinden ulaşabiliyorlarsa her interface için bir tünel oluşturulması ölçeklenebilir olmayacaktır. Bunun yerine her iki router’da da birer loopback oluşturup tünelleri bu interface’lerde sonlandırabiliriz. Aşağıdaki topolojiyi inceleyelim:

 

 

Şimdiye kadar incelediğimiz konfigürasyonlara göre iki noktada farklılık olacaktır. Birincisi, ISAKMP’de pre-shared key kullanıyorsak, bu anahtarları loopback adresleri için tanımlamalıyız. Yani:

R1(config)# crypto isakmp key Cisco123 address 10.0.2.1

İkincisi; sadece IPSEC bağlantısıysa peer adresini, GRE over IPSEC veya SVTI bağlantısıysa tunnel source ve destination adreslerini loopback’ler olarak tanımlamalıyız:

R1(config)# crypto map MAP 1 ipsec-isakmp

R1(config-crypto-map)# set peer 10.0.2.1

Veya

R1(config)# interface tunnel 0

R1(config-if)# tunnel source 10.0.1.1

R1(config-if)# tunnel destination 10.0.2.1

Küçük bir not: GRE over IPSEC’i crypto map kullanarak yapıyorsak hem peer hem de tunnel source ve destination olarak loopback adreslerini tanımlamalıyız.

Crypto map konfigürasyonları için yapmamız gereken küçük bir de ekleme var. Artık karşı taraf bizim loopback adresimizi geçerli kabul edeceği için, ISAKMP ve IPSEC negotiation mesajlarında source adres olarak kendi loopback’imizi kullanması gerektiğini router’a bildirmemiz gerekiyor. Bunu da şu komutla yapıyoruz:

R1(config)# crypto map MAP1 local-address Loopback0

Bu komut o crypto map’teki tüm satırları etkiliyor. Ayrıca IPSEC tarafındaki bir komut olsa da ISAKMP’yi de etkiliyor yani ISAKMP için ayrı bir komut girmeye gerek yok.

Tabi ki crypto map’leri dışa bakan tüm interface’lerde uygulamak gerekiyor. Ayrıca R1 için yapacağımız bu konfigürasyonların simetriği R2 için de geçerli.

Şimdi de cihaz yedekliliğini inceleyelim. İki site arasında IPSEC tüneli kurarken sitelerin birinde tüneli sonlandırabileceğimiz iki cihaz bulunabilir. Biz de haliyle bunu yedekli çalıştırmak isteyebiliriz. Bunun için de yine iki tünel kurmamıza gerek yok. Karşı taraftaki iki router’la tek bir IPSEC tüneli kurmak için bir kaç farklı yöntem bulunuyor.

En basitinden her iki router’ ı da ISAKMP ve IPSEC peer olarak tanımlayabiliriz. Ama router’ın karşı taraftaki router’lardan bir tanesi ulaşılamaz olduğunda bunu anlayabilmesi ve yedek router’la yeni tünel oluşturabilmesi gerekir. Bunun için ISAKMP Dead Peer Detection özelliğini yani ISAKMP keepalive mesajlarını kullanabiliriz.

Router(config)# crypto isakmp keepalive seconds [retries] [periodic | on-demand]

ISAKMP DPD’yi periodic (önerilen) veya on-demand (varsayılan) olarak kullanabiliriz. On-demand seçildiğinde sadece o peer’a gönderilecek bir trafik olması durumunda DPD mesajları gönderilirken, periodic seçildiğinde periyodik olarak peer kontrol edilir. Bu sebeple periodic seçeneği peer failure’larını daha çabuk tespit edebileceğinden önerilir. Ayrıca DPD mesajları için zaman aralığını (seconds) ve istersek başarısız DPD mesajlarından sonra tekrar denemek için beklenecek zaman aralığını (retries) da belirtebiliriz.

Örnek olarak aşağıdaki topolojiye bakalım. IP adreslerinin aynı ağdan gibi görünmesi sizi yanıltmasın, ortadaki switch’in İnterneti ya da bir WAN’ı sembolize ettiğini düşünelim.

Konfigürasyon şu şekilde:

R3(config)# crypto isakmp key Cisco123 address 10.0.0.1

R3(config)# crypto isakmp key Cisco123 address 10.0.0.2

R3(config)# crypto isakmp keepalive 10 3 periodic

R3(config)# crypto map MAP 10 ipsec-isakmp

R3(config-crypto-map)# set peer 10.0.0.1 default

R3(config-crypto-map)# set peer 10.0.0.2

Eğer yedekli çalıştırmak istediğimiz iki router arasında şekilde olduğu gibi gerçekten bir ethernet bağlantısı varsa bu iki router’ı HSRP konuşturup VPN bağlantısını HSRP IP’sine de kurabiliriz. Bu durumda karşı router’da bildiğimiz IPSEC VPN konfigürasyonu yaparken, yedekli router’ların VPN sonlandıran interface’lerindeki konfigürasyonlara bazı eklemeler yapıyoruz:

R1(config-if)# ip address 10.0.0.1 255.255.255.0

R1(config-if)# standby 1 ip 10.0.0.3 !!! HSRP Virtual IP

R1(config-if)# standby 1 priority 150 !!! Birincil router

R1(config-if)# standby 1 preempt

R1(config-if)# standby 1 name VPN-HA

R1(config-if)# crypto map MAP1 redundancy VPN-HA

R2(config-if)# ip address 10.0.0.2 255.255.255.0

R2(config-if)# standby 1 ip 10.0.0.3 !!! HSRP Virtual IP

R2(config-if)# standby 1 priority 50 !!! İkincil router

R2(config-if)# standby 1 preempt

R2(config-if)# standby 1 name VPN-HA

R2(config-if)# crypto map MAP1 redundancy VPN-HA

R3’teki konfigürasyon da şu şekilde olmalı:

R3(config)# crypto isakmp key Cisco123 address 10.0.0.3

R3(config)# crypto map MAP 10 ipsec-isakmp

R3(config-crypto-map)# set peer 10.0.0.3

Cihaz yedekliliği kısmında şimdiye kadar incelediklerimiz stateless failover idi. Yani aktif cihazda bir sorun olduğunda o tünel düşüp yedek cihazla tünel kurulana kadar geçen zamandaki trafik drop ediliyordu. Bir diğer deyişle “state” yani “durum” korunamıyordu. HSRP kullandığımızda stateful failover yapmamız da mümkün. Yani Standby router Active olduğu anda IPSEC bağlantısı tünelinin yeniden kurulmasına gerek kalmadan aynen devam edecektir. Router’lar bunu SSO (Stateful SwitchOver) kullanarak aralarında sürekli IPSEC ve ISAKMP durum bilgileri gönderip alarak başarır. Ancak bazı gereklilikleri ve kısıtlamaları var: HSRP cihazlarının IOS imajları, VPN konfigürasyonları, varsa VPN donanımları aynı olmalı ve iç ve dış interface’ler bir LAN üzerinden birbirine bağlı olmalı gibi.

Konfigürasyon şu şekilde:

redundancy inter-device

scheme standby VPN-HA !!! yazdıktan sonra reload gerekir

ipc zone default

association 1

no shutdown

protocol sctp

local-port 10000

local-ip 10.0.0.1

remote-port 10000

remote-ip 10.0.0.2

Router’ların birbirleriyle haberleşmesi için birer IP ve port tanımlamamız gerekiyor. Ben bu örnekte HSRP IP’lerini kullandım. Portlar da karşılıklı eşleştiği sürece keyfi seçilebilir. Son olarak interface’in altındaki crypto map komutunda da ufak bir değişiklik yapıyoruz:

R1(config-if)# crypto map MAP1 redundancy VPN-HA stateful

HSRP ve/veya SSO kullanarak crypto map’lerle yaptığımız konfigürasyonu aynı zamanda GRE ve SVTI için de yapabiliriz. Bu yapılandırmada redundancy tanımlamaları interface’e crypto-map atarken yapılamayacağından, ipsec profile altında yapılır. Tahmin edebileceğiniz gibi tunnel source IP olarak HSRP IP’si kullanılır.

R1(config)# crypto ipsec profile PROF1

R1(ipsec-profile)# redundancy VPN-HA [stateful]

R1(config)# interface Tunnel 0

R1(config-if)# tunnel source 10.0.0.3

R1(config-if)# tunnel protection ipsec profile PROF1

Yazımı bitirirken son bir hatırlatma yapayım. Özellikle cihaz yedekliliği planlanırken sadece bu konfigürasyonları yapmak muhtemelen yeterli olmayacaktır. Aynı zamanda IPSEC tünelini sonlandıran ve bu tüneli kullanan router’lar arasındaki routing’in de aktif cihaz düştüğünde yedek cihaz üzerinden dönebilecek şekilde dikkatle tasarlanması gerekir.

Bir sonraki yazıda görüşmek üzere 🙂

Bir Cevap Yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir