Site-to-Site IPsec VPN Tasarımı: Route-Based ve Policy-Based

Site-to-site IPsec tüneli kurulduğu gün çalışır; sorun aylar sonra “dosya paylaşımı takılıyor”, “birincil hat gitti ama yedek tünele geçmedi” diye gelir. Bu arızaların büyük kısmı şifrelemeden değil, bağlantı ve yönlendirme tasarımından kaynaklanır. Aşağıda policy-based ve route-based VPN farkını, IKEv2 parametre uyumunu, tünel üzerinde dinamik routing’i, MTU/MSS ayarını ve yedek tünel tasarımını, örnek bir Cisco VTI yapılandırması ve konsolda sırayla bakılacak doğrulama komutlarıyla anlatıyoruz.

Site-to-site VPN topolojileri

Lokasyon sayısı arttıkça topoloji seçimi yönetim yükünü belirler:

• Hub-and-spoke: Her şube yalnız merkeze (hub) tünel kurar. Tünel sayısı şube sayısına eşittir; şubeler arası trafik hub üzerinden geçer. Uygulamaların merkezde olduğu yapılar için en yaygın model.
• Full mesh: Her lokasyon diğer her lokasyona tünel kurar; n lokasyon için n(n−1)/2 tünel gerekir. Örnek hesap: 10 lokasyonda 45, 20 lokasyonda 190 tünel. Elle yönetim hızla çıkmaza girer.
• Kısmi mesh: Yoğun trafik alışverişi olan lokasyonlar (örneğin merkez, veri merkezi ve felaket kurtarma lokasyonu) birbirine doğrudan, şubeler hub’a bağlanır.
• Dinamik mesh: Cisco DMVPN, Fortinet ADVPN gibi üreticiye özgü çözümler şubeler arasında ihtiyaç anında doğrudan tünel kurar. Bunun üstüne merkezi politika ve uygulama bazlı yol seçimi de isteniyorsa SD-WAN değerlendirmesi gündeme gelir.

Policy-based ve route-based VPN farkı

Policy-based VPN’de hangi trafiğin tünele gireceğini bir erişim listesi veya politika belirler. Örneğin “10.10.0.0/16 kaynaklı ve 10.20.0.0/16 hedefli trafik şifrelensin” kuralı, IKE müzakeresinde trafik seçicisi (traffic selector, bazı üreticilerde proxy ID) olarak karşı tarafa iletilir. Route-based VPN’de ise bir sanal tünel arayüzü (VTI) oluşturulur; trafik seçicileri genellikle iki yönde de 0.0.0.0/0’dır ve tünele hangi trafiğin gireceğine routing tablosu karar verir.

Policy-based yapının sahadaki klasik arızası trafik seçicisi uyumsuzluğudur. Bir uç 10.20.0.0/16, diğeri 10.20.1.0/24 tanımlamışsa IKEv2 müzakeresi TS_UNACCEPTABLE hatasıyla başarısız olur veya tünel yalnız bir yönde çalışır. Bazı uygulamalar her alt ağ çifti için ayrı IPsec SA oluşturduğundan, çok sayıda alt ağda SA sayısı hızla artar ve sorun giderme zorlaşır. Yeni kurulumlarda, karşı uç destekliyorsa route-based seçin. ACL ile routing yapılmaz.

IKEv2 ve IPsec parametre eşleşmesi

IKEv2 (RFC 7296) iki aşamada çalışır: önce IKE SA kurulur (şifreleme, bütünlük/PRF, Diffie-Hellman grubu ve kimlik doğrulama), ardından bunun üzerinden trafiği taşıyan Child SA’lar (IPsec SA) müzakere edilir. Farklı üreticiler arasında tünel kurarken iki taraf için tek bir parametre tablosu hazırlayıp karşı ekiple paylaşmak, devreye almada saatler kazandırır:

Sahada en sık gözden kaçan şey kimlik (IKE ID) uyumsuzluğudur: bir uç kimliğini IP adresi, diğeri FQDN olarak gönderiyorsa PSK doğru olsa bile kimlik doğrulama başarısız olur. Log “authentication failed” der, herkes anahtarı değiştirir, sorun çözülmez. Önce kimlik tipine bakın.

Uçlardan biri NAT arkasındaysa IKE UDP 500’den başlar, NAT tespit edildiğinde UDP 4500’e geçer ve ESP paketleri UDP içinde taşınır (NAT-T); NAT yoksa ESP, IP protokol 50 olarak gider. Firewall kurallarında bu üç akışın da açık olması gerekir. Algoritma seçimi ve anahtar yönetimi gibi güvenlik kontrolleri için kurumsal VPN güvenliği kontrolleri yazısına bakabilirsiniz.

Tünel üzerinden dinamik yönlendirme

Route-based tünellerde statik rota yerine dinamik routing kullanmak hem yeni alt ağ eklemeyi hem yedek tünele geçişi otomatikleştirir.

• BGP: Çok sayıda şubeli kurumsal ağ altyapısında ölçeklenir; hangi şubeden hangi önekin kabul edileceği prefix-list ile sıkı kontrol edilir, tünel tercihi local-preference veya AS-path prepend ile yönetilir. Her şubeye özel (private) bir AS numarası vermek tasarımı netleştirir.
• OSPF: Az sayıda tünelde basittir. Tünel arayüzlerinde ağ tipinin point-to-point olduğunu doğrulayın (Cisco tünel arayüzlerinde varsayılan budur; bazı firewall’larda elle ayarlamak gerekir), şubeleri mümkünse stub alan olarak tasarlayın. Kampüs tarafındaki OSPF alan tasarımı için kampüs ağında OSPF tasarımı yazısına bakabilirsiniz.

Bu bölümün en can sıkıcı arızası özyinelemeli yönlendirmedir (recursive routing): karşı ucun genel IP adresine giden rota tünelin içinden öğrenilirse tünel kendi kendini taşımaya çalışır, kurulur, düşer, tekrar kurulur. Logda dakikada birkaç kez “tunnel up/down” görüyorsanız ilk şüpheli budur. Tünel uçlarının genel IP’lerini dinamik routing’den filtreleyin; bu adreslere her zaman fiziksel internet arayüzü üzerinden ulaşılmalı.

MTU, MSS ve parçalanma sorunları

ESP tunnel mode her pakete yeni bir IP başlığı, ESP başlığı, IV, dolgu ve bütünlük değeri ekler; NAT-T varsa 8 baytlık UDP başlığı da eklenir. Kullanılan algoritmaya göre ek yük yaklaşık 50–80 bayt arasında değişir. 1500 baytlık bir paket şifrelendikten sonra fiziksel arayüzün MTU’sunu aşar. Paket parçalanırsa performans düşer; DF biti işaretliyse ve ICMP “fragmentation needed” mesajları yol üzerinde engelleniyorsa paket sessizce kaybolur. Belirti hep aynıdır: ping ve küçük istekler çalışır, büyük dosya aktarımları, RDP ve bazı web uygulamaları takılır. Kullanıcı “VPN yavaş” der. Aslında paket kayboluyordur.

Pratik çözüm, tünel arayüzünde IP MTU’yu düşürmek ve TCP oturumlarının MSS değerini buna göre ayarlamaktır. Yaygın kullanılan güvenli değerler IP MTU 1400 ve MSS 1360’tır (1400 − 20 bayt IP − 20 bayt TCP). Alt hat PPPoE ise (1492 MTU) veya tünel GRE gibi ek bir kapsülleme içeriyorsa değerleri daha da düşürün. MSS ayarı yalnız TCP’yi kurtarır; büyük UDP paketleri gönderen uygulamalar için MTU tarafı doğru olmalıdır.

Yedek tünel, DPD ve failover

Şubede iki internet hattı varsa her hat üzerinden ayrı bir tünel kurmak ve ikisinde de dinamik routing komşuluğu çalıştırmak en temiz yöntemdir. Birincil tünelden öğrenilen rotalara daha yüksek local-preference (BGP) veya daha düşük maliyet (OSPF) verilir. Hatların kendi failover davranışı çift internet hattı yazısında anlatılıyor.

Arıza tespiti iki katmanda yapılır. IKEv2 liveness kontrolü (yaygın adıyla DPD) karşı ucun yanıt vermediğini anlayıp SA’ları temizler; routing protokolünün zamanlayıcıları ise rotaları geri çeker. BGP’nin varsayılan zamanlayıcıları (Cisco’da keepalive 60, hold 180 saniye) failover için uzundur; zamanlayıcıları düşürün veya platform destekliyorsa BFD kullanın. Üç dakika beklemek failover sayılmaz. Merkezde iki ayrı hub cihazı varsa şubeler ikisine de tünel kurarak cihaz arızasına karşı da korunur.

Örnek VTI yapılandırması ve doğrulama

Aşağıdaki örnek, Cisco IOS XE üzerinde merkez tarafında bir şubeye IKEv2 ve statik VTI ile tünel kurar ve tünel üzerinden BGP komşuluğu açar. Adresler dokümantasyon aralıklarından seçildi; merkez genel IP’si 203.0.113.10, şube genel IP’si 198.51.100.20.

crypto ikev2 proposal PROP-GCM
 encryption aes-gcm-256
 prf sha384
 group 20
crypto ikev2 policy POL-GCM
 proposal PROP-GCM
!
crypto ikev2 keyring KR-SUBE1
 peer SUBE1
  address 198.51.100.20
  pre-shared-key GUCLU_RASTGELE_ANAHTAR
!
crypto ikev2 profile PROF-SUBE1
 match identity remote address 198.51.100.20 255.255.255.255
 identity local address 203.0.113.10
 authentication remote pre-share
 authentication local pre-share
 keyring local KR-SUBE1
 dpd 10 3 on-demand
!
crypto ipsec transform-set TS-GCM esp-gcm 256
 mode tunnel
crypto ipsec profile IPSEC-SUBE1
 set transform-set TS-GCM
 set pfs group20
 set ikev2-profile PROF-SUBE1
!
interface Tunnel10
 description VPN-SUBE1
 ip address 172.31.255.1 255.255.255.252
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/0/0
 tunnel mode ipsec ipv4
 tunnel destination 198.51.100.20
 tunnel protection ipsec profile IPSEC-SUBE1
!
ip prefix-list SUBE1-IN seq 10 permit 10.20.0.0/16 le 24
!
router bgp 65000
 neighbor 172.31.255.2 remote-as 65001
 neighbor 172.31.255.2 timers 10 30
 address-family ipv4
  network 10.10.0.0 mask 255.255.0.0
  neighbor 172.31.255.2 activate
  neighbor 172.31.255.2 prefix-list SUBE1-IN in

network komutunun 10.10.0.0/16 önekini duyurabilmesi için bu önekin routing tablosunda birebir bulunması gerekir (örneğin bir özet statik rota ile). Şube tarafı aynı parametrelerle, adresler ters çevrilerek yapılandırılır. Konsolda doğrulama sırası:

1. show crypto ikev2 sa: IKE SA durumu READY olmalı; seçilen şifreleme ve DH grubu kontrol edilir.
2. show crypto ipsec sa interface Tunnel10: #pkts encaps ve #pkts decaps sayaçları iki yönde de artmalı. Yalnız biri artıyorsa sorun genellikle karşı uçtaki routing veya firewall kuralındadır.
3. show ip bgp summary: komşuluk kurulu olmalı, şubeden beklenen önek sayısı alınmalı.
4. ping 10.20.0.1 source Loopback0 size 1400 df-bit: parçalanmasız paket boyutu testi; başarısızsa MTU değerlerini gözden geçirin.
5. Yedek tünel varsa birincil hattı planlı olarak kapatın, rotaların ve oturumların geçiş süresini ölçün.

Bu sırayı atlamayın. IKE SA yoksa routing’e bakmanın anlamı yoktur; sayaçlar tek yönlüyse MTU’ya bakmanın anlamı yoktur. Katman katman ilerleyin.

İki lokasyonda aynı alt ağ kullanılıyorsa tünel kurulsa bile trafik yönlendirilemez; bu durumda adres çevirisi gerekir ve kurumsal NAT tasarımı yazısındaki iki yönlü NAT bölümü uygulanabilir. Lokasyonlar arası routing ve segmentasyon tasarımı için VLAN, routing ve ağ segmentasyonu, hat tarafı için Metro Ethernet ve internet hat yönetimi sayfalarına bakabilirsiniz.

Sık sorulan sorular

Farklı üreticilerin cihazları arasında route-based VPN kurulabilir mi?

Evet. IKEv2 ve IPsec standart protokoller olduğu için iki uçta da VTI veya tünel arayüzü destekleniyorsa route-based tünel kurulur. Uçlardan biri yalnız policy-based çalışıyorsa, route-based tarafta trafik seçicilerini karşı tarafın beklediği alt ağlara göre tanımlamak gerekir; birçok üretici bunun için proxy ID veya benzeri ayarlar sunar.

Tünel kuruluyor ama bazı uygulamalar çalışmıyor; ilk neye bakmalıyım?

Ping çalışıyor ama dosya paylaşımı, web uygulaması veya RDP gibi büyük paket gönderen uygulamalar takılıyorsa ilk şüpheli MTU ve MSS ayarıdır. Tünel arayüzünde IP MTU’yu düşürün, TCP MSS değerini buna göre ayarlayın ve parçalanmasız ping testiyle tünelin taşıyabildiği en büyük paketi doğrulayın.

Hub-and-spoke yapıda şubeler birbirine nasıl erişir?

Klasik hub-and-spoke’ta şubeler arası trafik hub üzerinden geçer; hub şubelerden öğrendiği rotaları diğer şubelere duyurur. Şubeler arası trafik yoğunsa ve gecikme önemliyse, ihtiyaç anında doğrudan tünel kuran DMVPN, ADVPN gibi üreticiye özgü çözümleri veya SD-WAN’ı değerlendirin.

IKEv2’de SA ömürleri iki tarafta aynı olmak zorunda mı?

IKEv2’de SA ömürleri müzakere edilmez; her uç kendi süresi dolduğunda yeniden anahtarlamayı başlatır. Farklı değerler tüneli kurulamaz hale getirmez. Yine de iki tarafta tutarlı değerler kullanmak log yorumunu ve sorun gidermeyi kolaylaştırır.