FlexVPN

Önceki yazımda IKEv2’den bahsetmiş ve point-to-point VPN topolojilerinde kullanımına örnekler vermiştik. Bu yazımda da multipoint topolojilerde kullanımını inceleyeceğiz. DMVPN ile çok uçlu routing alt yapısı oluşturabileceğimizi zaten biliyoruz. IKEv2 ve IPSEC kullanarak da bunun güvenliğini sağlamamız mümkün. Ancak DMVPN’in yapabildiklerinin fazlasını da yapabilen, dolayısıyla IKEv2 kullanılırken tercih edilebilen FlexVPN adını verdiğimiz bir yapı da mevcut. Bu yazıda da aslında daha çok bu yapıyı inceliyor olacağız.

FlexVPN’i DMVPN faz 1 ile karşılaştırarak incelemeye başlayabiliriz. Hatırlayacak olursak DMVPN faz 1’in temel faydası bir adet multipoint tünel aracılığıyla tüm spoke’lara bağlantı sağlayabilmesiydi. mGRE interface’i kullanmak hub’da her spoke için ayrı bir tünel yapılandırma gerekliliğini ortadan kaldırmakta ve iş yükü anlamında bizi rahatlatmaktadır. FlexVPN ise her spoke için ayrı bir interface kullanmakta ve bunu yapılandırmayı daha karmaşık hale getirmeden yapmaktadır.  Bunu ise daha önce incelediğimiz bir yapıyı, virtual-template interface’leri kullanarak başarmaktadır.

Yukarıdaki örnek topoloji için örnek konfigürasyonlar aşağıdaki gibidir (EIGRP 20 ISP ile yapılan routing’i, EIGRP 10 ise tüneller üzerinden yapılan routing’i temsil ediyor):

Hub:

Spoke1:

Spoke2:

Gördüğümüz gibi IKE ve IPSEC kısmında önceki yazıya göre tek fark IKE profile’ın altında bir virtual-template belirtilmiş olması. Hub’a bağlanan her bir spoke için ayrı bir virtual-access interface oluşacak. Yani neticede tüm router’lar tek bir tunnel IP’ye bağlanacak (tüm virtual-access interface’leri aynı konfigürasyonu kopyalayacağı için IP’leri de aynı olacak) ama her router için ayrı ve point-to-point şeklinde çalışan bir interface oluşmuş olacak.

Tabi buna ek olarak (DMVPN’de de yapabildiğimiz gibi) şunu da yapabiliriz: Bir grup spoke’u başka bir IKE profile ile eşleştirip, bu IKE profile’ı başka bir IPSEC profile’a atayıp, bu IPSEC profile’ı da başka bir virtual-template’e (veya tunnel interface’e) atayabiliriz. Böylece o gruptaki spoke’ların virtual-access interface’leri farklı bir konfigürasyonu olan bir virtual-template’ten kopyalanmış olacaktır. İstersek bu virtual-template’e farklı QoS ayarları, farklı zone-based firewall ayarları vs. uygulayabiliriz. IP’sini de aynı interface’ten veya başka bir interface’ten kopyalatabiliriz.

Spoke’ları farklı IKE profile’larla eşleştirmek için ise bakabileceğimiz bir kaç kriter var. IKE kimlik denetimi PSK olduğunda ID olarak e-mail, IP adres bloğu, domain name veya keyfi seçilen bir string kullanabiliriz. Sertifika kullanmamız durumunda ise certificate map yapısı aracılığıyla sertifikadaki çeşitli değerleri kriter olarak kullanıp çok daha ölçeklenebilir sistemler elde etmemiz de mümkün.

Konfigürasyonun şu haliyle, yapılan özetleme sayesinde tüm spoke’lar tüm subnet’leri hub’ın arkasında biliyor, sadece hub hangi subnet’in hangi spoke’ta olduğunu biliyor. Yani DMVPN faz1’e benzer bir yapı elde ettik.

Gelelim spoke-to-spoke iletişime. Spoke’larda routing table’ları şişirmeden spoke-to-spoke iletişimi etkinleştirmek için hub’da ip nhrp redirect’i devreye alacağız. Böylece başka bir spoke’a gitmesi gereken bir paket hub üzerinden geçtiğinde hub paket gönderen spoke’u NHRP sorgusu yapması için uyaracak. NHRP’yi devreye aldığımızda bir nhrp network-id de belirtmemiz gerekecek:

Burda akla şu soru gelebilir. Spoke’lardaki tunnel interface’lerin mutlipoint olduğunu belirtmedik, yani bunlar point-to-point. O halde spoke-to-spoke iletişim nasıl gerçekleşecek? Spoke tarafındaki konfigürasyona bakarak açıklayalım:

İşin püf noktası ip nhrp shortcut komutuna eklediğimiz virtual-template 1 parametresi. Bu sayede spoke-to-spoke iletişim yeni oluşan virtual-access interface’leri üzerinden gerçekleşiyor. Başka bir spoke’un kendisine shortcut yapması durumu için de IKE profile altına virtual-template 1 komutunu ekliyoruz. Tabi virtual-template interface’leri altına da ip unnumbered, nhrp network-id, tunnel protection gibi standart komutları girmemiz gerekiyor. Ben bir de test yaparken spoke-to-spoke tünellerin timeout olmasını çok beklememek için ip nhrp holdtime 60 komutunu girdim.

Böylece de DMVPN faz 3’e benzer bir yapı elde etmiş oluyoruz. Yani FlexVPN hem hub’da her spoke için ayrı bir interface elde etmemizi sağlıyor, hem de spoke’larda her spoke-to-spoke iletişim için ayrı bir interface kullanmamıza imkan veriyor. Böylece bir NBMA network ile uğraşmak yerine daha basit point-to-point network’ler ile çalışıyoruz (farkettiğiniz üzere routing protokollerinde split-horizon, next-hop-self, network type gibi özelliklerle hiç oynamak zorunda kalmadık). Hatta aslında FlexVPN; her türlü point-to-point, multipoint ve remote access IPSEC bağlantıları için aynı konfigürasyon yapılarını kullanıyor (One VPN to rule them all 🙂 ). Ayrıca yedeklilikle ilgili de önümüzdeki yazılarda değineceğim ekstra özellikleri mevcut.

Bu arada ben bu topolojide hızlı olması için EIGRP kullanmış olsam da aslında FlexVPN için ancak en küçük yapılarda EIGRP öneriliyor. Büyük ölçekli yapılarda BGP kullanılması veya eğer daha statik bir yapıysa IKEv2 ile rota paylaşımı yapılması tavsiye ediliyor. BGP kullanılırken de dikkat edilmesi gereken nokta bazı noktalar var:

Tunnel interface’leri üzerinden bir IGP çalıştırmak söz konusu olduğunda, IGP’ler multicast kullanarak haberleştiği için ve bu multicast paketlere GRE encapsulation otomatik olarak uygulandığı için ( ip nhrp map multicast {dynamic | <tunnel IP>} sayesinde ) komşuluklar direk kurulur. Ancak bildiğimiz gibi BGP yapılandırmasında komşunun IP’sini tanımlamak gerekir. Bu sorun değil: Spoke’ta Hub’ı tünel IP’sini kullanarak tanımlarız; Hub’da ise Spoke’lar için bir peer group tanımlayıp bgp listen range 10.0.0.0/24 peer-group PEERS komutuyla tünel IP’lerinin bulunduğu bloktan gelen komşuluk isteklerini kabul etmesini söyleriz.

Sorun şu ki IGP kullanmadığımız için  Hub’ın tünel IP’si Spoke’larda routing table’a eklenmez (aynı şekilde Spoke’ların IP’leri de Hub’da eklenmez). Böyle olunca da BGP komşuluğu kurulmaz. Bunun olmasını engellemek için IKEv2 ile rota paylaşımı kullanılır. Böylece tünel IP’si (/32’lik bir statik rota) karşı tarafın routing table’ına yeni kurulan virtual-access interface üzerinden erişilebilir olarak eklenir.

Bunu ikev2 authorization policy altında, önceki yazımda bahsettiğim gibi ACL kullanarak yapabiliriz. Fakat daha basit bir yolu da var: route set interface komutu router’ın tünel IP’sini IKEv2 kullanarak /32’lik bir statik rota olarak karşı tarafa öğretir.

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