Çakışan IP blokları arasında IPSEC VPN

Merhaba

IPSEC VPN’in uzak noktalardaki iki site arasında güvenli bağlantı sağlayan bir teknoloji olduğunu biliyoruz. IPSEC VPN bir kurumun uzak noktalardaki şubeleri arasında güvenli bağlantı sağlamak amacıyla kullanılabileceği gibi, iki farklı kurumun karşılıklı anlaşmasıyla bu kurumlar arasındaki belli bir trafiğin güvenliğinin sağlanması amacıyla da kullanılabilir. Bu “kurumlar arası” VPN türünde “kurum içi” VPN’de karşılaşılması pek olası olmayan bir durum ortaya çıkabilir: İki kurumun da aynı private IP aralığını kullanıyor olması.

İki kurum da aynı private IP aralığını kullanıyorsa şöyle bir sorun oluşma ihtimali vardır: Bir kurumun VPN’e sokacağı IP bloğu karşı tarafın iç ağında herhangi bir yerde zaten kullanılıyor olabilir. Böyle bir durumda routing’in düzgün çalışmayacağı açıktır. Bu şekilde VPN kurulmaya çalışılırsa  yereldeki IP bloğuna ve/veya uzaktaki IP bloğuna erişim sorunu yaşanır.

Aşağıdaki topolojide bu sorun en üst seviyeye çıkarılmış durumda. Şans bu ya kurumunuzdaki ve karşı kurumdaki IPSEC VPN üzerinden haberleştirilmek istenen sunucuların IP blokları tam da birbirinin aynısı denk gelmiş olsun.

Böyle bir topoloji GNS3’te karşımıza geldiğinde hızlı bir şekilde herhangi bir tarafın LAN IP’lerini değiştirerek sorunu çözebiliriz 🙂 Ancak gerçek hayatta bu işlem büyük olasılıkla hiç de istenmeyen bir durum olacaktır. Bu durumda uygulanabilecek en iyi çözüm karşı tarafa yerel adresimizi olduğundan farklı bir şekilde bildirmektir. Tabi bu sahte IP’leri gerçek IP’lere çevirmek için de NAT kullanılması gerekir.

Yukarıdaki topolojide CORP1’in 10.0.2.0/24 bloğunu, CORP2’nin de 10.0.1.0/24 bloğunu iç ağında herhangi bir yerde kullanmadığını düşünelim. Bu durumda CORP1 kendi sunucularının 10.0.1.0/24 bloğunda olduğunu, CORP2 de kendi sunucularının 10.0.2.0/24 bloğunda olduğunu söyler ve routing bu mantığa göre yapılır. Bundan sonra yapılması gereken 10.0.0.0/24 bloğunun 10.0.1.0/24 ve 10.0.2.0/24 bloklarına düzgün bir şekilde NAT’lanmasıdır.

Kullanılması gereken NAT türü statiktir. Çünkü dışarıdan trafik başlatılabilmesi gerekmektedir. inside veya casino online outside NAT kullanılabilir. Aşağıdaki konfigürasyonlar inside NAT kullanılarak yapılmıştır.

Konfigürasyonları anlamak için bir sunucudan diğer sunucuya trafik giderken neler olduğunu adım adım inceleyelim:

  • CORP1 karşı sunucuların 10.0.2.0/24 bloğunda olduğunu düşünmektedir. Dolayısıyla S1 kaynak ve hedef IP’leri 10.0.0.2 -> 10.0.2.2 şeklinde bir paket gönderir.
  • R1’de paket inside interface’ten outside interface’e route edilir.
  • R1’de NAT kuralı çalışır ve source IP’yi 10.0.1.2 olacak şekilde değiştirir. IP başlığı 10.0.1.2 -> 10.0.2.2 şekline gelmiş olur.
  • Bu trafik crypto ACL’e match eder ve VPN kurulur. Trafik kriptolanır ve başına 20.0.0.1 -> 20.0.0.2 şeklinde yeni bir IP başlığı eklenir.
  • Trafik R2’ye ulaştığında kripto çözülür. 10.0.1.2 -> 10.0.2.2 paketi elde edilmiş olur.
  • R2’deki NAT kuralı tersten çalışır ve destination IP’yi 10.0.0.2 olacak şekilde değiştirir. IP başlığı 10.0.1.2 -> 10.0.0.2 şekline gelmiş olur.
  • R2 paketi 10.0.0.2’ye yani S2’ye route eder.
  • CORP2 zaten karşı sunucuların 10.0.1.0/24 bloğunda olduğunu düşünmektedir ve kendisine 10.0.1.2 IP’sinden bir paket geldiğini görür. Dolayısıyla bu trafiğe cevap dönerken aynı olaylar tersten gerçekleşir (önce R2’deki NAT kuralı çalışır sonra R1’deki NAT kuralı tersten çalışır).

Bu konfigürasyondaki routing’i değiştirmeden sadece NAT kurallarını değiştirerek aynı işi outside NAT kullanarak yapalım:

Not: inside NAT paket içerden dışarıya geçerken IP değiştirecek şekilde tanımlanırken, outside NAT paket dışardan içeriye geçerken IP değiştirecek şekilde tanımlanır. Fakat her iki durumda da NAT kuralı iki yönde de uygulanır.

R1(config)# no ip nat inside source static network 10.0.0.0 10.0.1.0 /24
R1(config)# ip nat outside source static network 10.0.0.0 10.0.2.0 /24
R1(config)# ip access -list extended CRYPTO
R1(config-ext-nacl)# no 10
R1(config-ext-nacl)# permit ip 10.0.0.0 0.0.0.255 10.0.0.0 0.0.0.255

R2(config)# no ip nat inside source static network 10.0.0.0 10.0.2.0 /24
R2(config)# ip nat outside source static network 10.0.0.0 10.0.1.0 /24
R2(config)# ip access-list extended CRYPTO
R2(config-ext-nacl)# no 10
R2(config-ext-nacl)# permit ip 10.0.0.0 0.0.0.255 10.0.0.0 0.0.0.255

Konfigürasyon böyle olduğunda adımlar aşağıdaki gibi olur:

  • S1 yine 10.0.0.2 -> 10.0.2.2 şeklinde bir paket gönderir.
  • R1’de paket inside interface’ten outside interface’e route edilir.
  • *R1’deki NAT kuralı tersten çalışır ve destination IP’yi 10.0.0.2 olacak şekilde değiştirir. IP başlığı 10.0.0.2 -> 10.0.0.2 şekline gelmiş olur.
  • Bu trafik crypto ACL’e match eder** ve VPN kurulur. Trafik kriptolanır ve başına 20.0.0.1 -> 20.0.0.2 şeklinde yeni bir IP başlığı eklenir.
  • Trafik R2’ye ulaştığında kripto çözülür. 10.0.0.2 -> 10.0.0.2 paketi elde edilmiş olur.
  • *R2’deki NAT kuralı çalışır ve source IP’yi 10.0.1.2 olacak şekilde değiştirir. IP başlığı 10.0.1.2 -> 10.0.0.2 şekline gelmiş olur.
  • R2 paketi 10.0.0.2’ye yani S2’ye route eder.

*: inside NAT yerine outside NAT kullanıldığında değişen adımlar.

**: paketin kaynak ve hedef IP’lerinin değişme sırası değiştiğinden crypto ACL de değişmelidir.

Bu konfigürasyona aşağıdaki komutları ekleyerek sunucuların İnternet erişimi için dinamik NAT overload da yapabiliriz:

R1’e:

 

 

 

R2″ye:

 

 

 

Bu adımları daha iyi anlayabilmek için içeriden dışarıya ve dışarıdan içeriye giden trafik durumunda işlem sırasını bilmek gerekiyor:

İçeriden dışarıya: Routing, NAT, Encryption

Dışarıdan içeriye: Decryption, NAT, Routing

Bu bilgiler ışığında şunları söyleyebiliriz: Örneğin kurum içi VPN’de VPN trafiğinin NAT’a girmesi genellikle istenmez. Dolayısıyla VPN trafiğinin NAT ACL’inde deny edilmesi gerekir. Ama IP adreslerinin çakışması gibi bir durumda mecburen NAT kullandığımızdan crypto ACL’i NAT sonrası IP’lere göre yazmak 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