IKEv2 (Internet Key Exchange version 2)

Merhaba

Bu yazımda IKEv2’den bahsedeceğim. Daha önceki yazılarda incelediğimiz üzere ISAKMP protokolü IPSEC bağlantısını güvenli bir şekilde başlatma görevini üstlenen bir protokoldür. Önceden çok detaylı bahsetmemiş olsam da ISAKMP aslında daha geniş ve IKE adını verdiğimiz bir protokolün bir parçası. İkisi aynı şey olmasa da yapılandırma perspektifinden hemen hemen aynı şeyi ifade etmekte ve neticede cümle içinde kullanılırken de çoğu kez birbirlerinin yerine kullanılmaktadır. İşte IKEv2 de IPSEC için aynı amaca yönelik tasarlanmış yeni bir protokol.

IKE ve ISAKMP ile ilgili daha fazla detaya girmeden IKEv2’nin özelliklerini sıralayıp sonra da konfigürasyon örneklerine bakalım. İlk olarak şunu belirteyim ki IKEv1 ve IKEv2, her nekadar ikisi de UDP 500 veya UDP 4500 kullanıyor olsa da, tahmin edebileceğiniz üzere birbirleriyle uyumlu değildir.

IKEv2 özellikleri:

    • Öncelikle daha yeni 🙂 Yani yeni tasarlanan bir protokol olduğu için IKEv1’e göre daha düzenli ve anlaşılır.
    • Mesajlaşmalar daha basit tanımlanmış vekarmaşıklık azaltılmış. Ayrıca mesajlaşmalarda geri bildirim özelliği eklenmiş.
    • Main/Aggressive mode ayrımı yok. Mesajlaşmalarda kimlik bilgisi hep korunuyor.
    • Yeni nesil kriptolama algoritmalarının tanımlandığı Suite-B desteği mevcut.
    • Daha kapsamlı kimlik denetimi için EAP desteği mevcut.
  • Anti-DoS özelliği mevcut.

Aşağıdakiler de birazdan inceleme fırsatı bulacağımız bazı daha somut özellikler :

  • Asimetrik kimlik denetimi. Yani VPN cihazlarının birbirlerini farklı şekillerde kimlik denetiminden geçirebilme yeteneği.
  • IKEv2 ile tünel interface’i üzerinden rota paylaşımı (AAA Authorization ile mümkün).
  • IKEv2 ile tünel interface’e IP adresi atanması (AAA Authorization ile mümkün)

Konfigürasyon örneklerine geçelim. İlk örneğimiz iki site arasında basit bir “düz IPSEC” yapılandırması:

Yukarıdaki örnekte R1 R2’yi PSK ile kimlik denetiminden geçirirken, R2 R1’i sertifika ile kimlik denetiminden geçiriyor. R2’de aldığı sertifikayı çeşitli özellikleri üzerinden ikev2 profile’a match ettirebilmesi için certificate map tanımlanması gerekiyor. Bu örnekte sertifikadaki issuer-name alanının ogul-ca string’ini içermesi şart koşulmuş (co = contains). Sertifikayı gönderen tarafta yani R1’de ise local identity olarak DN (Distinguished Name) kullanılması gerekiyor.

İkinci örneğimiz ise iki site arasında static VTI yapılandırması (VTI’dan GRE over IPSEC’e geçmek için tunnel0 altında da tunnel mode gre ip yazmak gerekir, ek olarak da transform-set altında mode transport yazılması tavsiye edilir):

Bu örnekte iki taraf da kimlik denetimi için PSK kullanıyor. Ancak R1 R2’ye “cisco1” PSK’sını, R2 R1’e “cisco2” PSK’sını göndererek kimlik denetiminden geçiyor. Ayrıca R1’in kimliği kendi IP adresi iken, R2’nin kimliği keyfi belirtilmiş bir string. Kimlik olarak FQDN ve e-mail seçeneklerini kullanmak da mümkün. Bunlara ek olarak cihazlar arkalarındaki subnet’leri IKEv2 aracılığıyla birbirleriyle paylaşıyor. Bu rotalar routing table’da static olarak gözükecektir. Son olarak da bu örnekte R2’nin tünel IP’sini de IKEv2 aracılığıyla R1 atıyor.

IKEv1’de ISAKMP policy ile tanımladığımız kripto algoritmalarını burda istersek IKEv2 proposal ile tanımlayabiliriz. Ancak varsayılanda zaten default IKEv2 proposal bulunduğundan bu mecburi değil. Yine istenirse IKEv2 policy kullanarak cihaz üzerindeki hangi adres için hangi proposal’ın kullanılacağı seçilebilir. R1 için bir örnek verecek olursak:

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