IPSEC Profile ve VTI (Virtual Tunnel Interface)

Merhaba

GRE over IPSEC yazısıyla IPSEC’te tünel interface’lerinin kullanılmasına giriş yapmış olduk. VPN bağlantılarının tünel interface’leri üzerinden yapılmasının bazı önemli avantajları var. Daha önce de bahsetmiş olduğum gibi GRE tünelleri üzerinden multicast destekledikleri için IGP çalıştırabiliriz. Bu tünelleri Firewall ve QoS uygulamalarında interface olarak kullanabilmek de bir diğer artısı. Ayrıca bir tünel interface’ini monitor etmek bir IPSEC bağlantısına kıyasla daha kolay olacaktır. Özetle elimizde artık bir interface olduğu için bir interface’le yapabileceğimiz pek çok şeyi yapabiliriz.

Son yaptığımıza benzer GRE over IPSEC konfigürasyonunun bir kısmına göz atalım:

 

 

 

 

 

 

 

 

 

 

 

Görüldüğü gibi routing tünel interface’i üzerinden yapılıyor. Crypto ACL tünel source IP’sinden tünel destination IP’sine giden GRE trafiğini tarif ediyor. Crypto map de tünel source interface’ine uygulanmış. Trafik yalnızca tünel uçları arasında gidip geldiğinden transport mode kullanılıyor.

Şimdi bir de aşağıdaki konfigürasyona bakalım:

 

 

 

 

 

 

 

 

 

Daha basit bir konfigürasyon olmakla beraber önceki konfigürasyonla aynı işi yapıyor. Peki daha az satırla IOS’a derdimizi anlatmamız nasıl mümkün oldu? Şöyle ki: Routing’i tünel interface’leri üzerinden yapınca crypto ACL yazmamıza gerek kalmadı. Çünkü yazdığımız ACL zaten tünele giren tüm trafiğin kriptolanmasını sağlıyordu. Ayrıca IPSEC tünel uçları arasında kurulacağından bir peer IP’si belirtmemize de gerek kalmadı. Tek yapmamız gereken IOS’a tünele giren tüm trafiği hangi transform-set’i kullanarak kriptolayacağını söylemek. İşte bu işe yapan araca IPSEC Profile adı veriliyor. Özetle eğer GRE over IPSEC yapacaksanız crypto map yerine IPSEC Profile kullanmak konfigürasyonu oldukça basitleştiriyor.

Gördüğünüz gibi konfigürasyonun güvenlikle ilgili kısmını tünel interface’ine uygulamamız sadece tek komut. Onun dışında bildiğimiz GRE konfigürasyonu. Bu aynı zamanda bu tüneli IP dışındaki adresleme protokollerini de IP network’ü üzerinden haberleştirmede kullanabileceğimiz anlamına geliyor. Bu protokollerden en önemlisi şüphesiz IPv6. Daha önce bu konuyla ilgili bir yazı yazmıştım. İki dual-stack router arasında bir GRE tüneli oluşturup, bu tünele IPv6 adresleri verip, bu tünel üzerinden IPv6 routing yaparak IPv6 network’lerinizi IPv4 network’ü üzerinden haberleştirebilirsiniz. Tabi aradaki router’ların IPv4 routing yapabilmesi için tünel source ve destination adresleri de IPv4 olmalı. Bu trafiğin güvenliğini sağlamak içinse tek yapılmanız gereken tünele IPSEC Profile atamak.

Şimdi bir aşama daha ileri gidelim. GRE tünellerinin farklı adresleme protokollerini taşıyabilme yeteneğinin kaynağı paketlere eklediği 4 byte’lık GRE başlığıdır. Eğer IPSEC kullanarak tünelin güvenliğini sağlamak istiyorsanız ve bu tüneli sadece IPv4 üzerinden IPv4 taşımak için kullanacaksanız, bu GRE başlığını atabilirisiniz. Bunun için yapmanız gereken interface altında tunnel mode ipsec ipv4 komutunu girmek. İşte bu anlattığım da VTI (Virtual Tunnel Interface)‘ın tanımını oluşturuyor.

VTI doğrudan IPv4 üzerinden IPv4 taşımak ve IPSEC’le bu trafiğin güvenliğini sağlamak üzere tasarlanmış bir teknolojidir. Multicast desteği de dahil olmak üzere GRE tünellerinin tüm özelliklerini taşır. Sadece diğer adresleme protokollerini taşıma yeteneği yoktur ama tam olarak da aynı sebepten 4 byte daha az overhead’i vardır.

VTI’a geçerken küçük bir değişiklik daha yapmamız gerekiyor: transform-set’i tünel moduna almak. Her ne kadar VTI’ın çalışma mantığı IPSEC transport mode’a benzese de konfigürasyon sadece tünel modunda çalışıyor. Bunun için de bildiğiniz gibi transform-set konfigürasyon modunda mode tunnel yazmamız gerekiyor.

Ayrıca VTI’ın statik ve dinamik diye iki türü var. Bu yazıda bahsettiğimiz statik VTI’dı. Dinamik VTI da aynı dinamik crypto map gibi remote-access VPN bağlantıları için kullanılabilir. Ancak bu başka bir yazının konusu 🙂

Küçük bir hatırlatma: IOS’ta default tunnel type GRE over IP’dir. Bu sebeple tünel interface konfigürasyonu altında tunnel mode gre ip komutu gözükmez. Aynı şekilde default’ta transform-set de tünel modundadır ve mode tunnel komutu gözükmez.

Tünel interface’lerinin en sevdiğim yanı sayelerinde uzak şubelerimizle servis sağlayıcılardan bağımsız bir şekilde routing yapabiliyoruz. Ayrıca tünel interface’lerine IPSEC konfigürasyonunu uygulamak da çok basit oluyor, crypto ACL veya crypto map konfigürasyonu yapmamıza gerek kalmıyor. Bu noktada crypto map’ler için şöyle bir savunma yapılabilir: crypto ACL olarak extended ACL yazıp daha detaylı trafik tarifi yapabiliriz. Örneğin sadece şu IP’den şu IP’lere veya sadece HTTP trafiği gibi. GRE over IPSEC veya VTI kullandığımızda ise sadece routing’e güvenerek yani hedef bazlı bir trafik tarifi yapabiliriz. Tabi eğer route-map’in ne demek olduğunu bilmiyorsak 🙂 route-map kullanarak extended ACL ile tarif ettiğimiz bir trafiği tünel interface’i üzerinden route edebiliriz ve bu durumda bu trafik de kriptolanacaktır. Ancak bunu uygulamak için route-map’i router’daki diğer tüm interface’lere girmeliyiz ki bu da yapının esnekliğini biraz azaltıyor. Daha da önemlisi route-map CPU’yu ciddi bir şekilde arttırabilir. Kısacası biraz fantastik bir çözüm ama mecbursanız imkansız değil. Detaylı bilgi için policy based routing yazıma ve diğer route-map yazılarıma (1.kısım, 2.kısım)bakabilirsiniz.

Bir sonraki yazımda görüşmek üzere.

“IPSEC Profile ve VTI (Virtual Tunnel Interface)” için bir cevap

Bir Cevap Yazın

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