VPN Nedir? Site-to-Site, Uzaktan Erişim ve IPsec'te Route-Based / Policy-Based Tasarım

“Tünel up görünüyor ama şubeden merkezdeki sunucuya ulaşılamıyor.” IPsec sorunlarının büyük kısmı bu cümleyle başlar. Çoğu zaman sorun şifrelemede değil, tasarımdadır: hangi trafiğin tünele gireceği nasıl belirlendi, iki uç bunu aynı şekilde mi tanımladı ve trafik tünele gerçekten yönlendiriliyor mu?

Bu yazının ana konusu bu soruların cevabını belirleyen tasarım kararı: route-based ve policy-based VPN. Önce VPN türlerini ve IPsec’in parçalarını kısaca toparlayacağız, sonra bu farkı merkezde Cisco, Huawei ve FortiGate, şubede MikroTik ve Teltonika örnekleriyle ve sorun gidermeyle birlikte ele alacağız.

Senaryo

Önceki yazılardaki kampüs bu kez merkez. Ona bir şube ve evden çalışan personel ekleniyor.

Hedef: şube ile merkez arasında kalıcı bir tünel ve evden çalışanların merkeze güvenli erişimi. Örneklerdeki adresler belgeleme için ayrılmış aralıklardandır.

VPN türleri

Site-to-site VPN, iki ağı birbirine bağlar. Tünel iki ağ geçidi (router ya da firewall) arasında kurulur; şubedeki kullanıcılar VPN’den habersizdir, trafikleri ağ geçidinde şifrelenir.

Uzaktan erişim VPN’i, tek bir kullanıcı cihazını merkeze bağlar. Üç yaygın biçimi vardır:

• IPsec istemcisi: Cihazda bir VPN istemcisi çalışır ve merkezle IPsec tüneli kurar (dial-up VPN olarak da anılır).
• SSL/TLS VPN tünel modu: Tünel TLS üzerinden kurulur; istemci yine cihazda çalışır.
• İstemcisiz (web) erişim: Kullanıcı tarayıcıyla bir portala bağlanır ve yalnızca portalın sunduğu uygulamalara erişir.

Uzaktan erişimde bir değişikliği özellikle not etmek gerekiyor: Fortinet, FortiOS 7.6.3 ile SSL VPN tünel modunu kaldırdı ve IPsec VPN’e geçişi öneriyor. SSL VPN’in web modu ise Agentless VPN adıyla devam ediyor; varsayılan olarak kapalıdır ve her modelde desteklenmez. Fortinet’in açıklamasına göre 2 GB veya daha az belleği olan modeller iki modu da desteklemez ve bu modellerde dial-up IPsec VPN kullanılmalıdır. Agentless VPN, FortiGate 40F, 60F ve 90G serilerinde desteklenmez; giriş seviyesi G serisi modellerde ise SSL VPN, 7.2.12 ve 7.4.8 sürümlerinden itibaren kaldırılmıştır. FortiGate üzerinde SSL VPN tünel modu kullanan bir yapı 7.6.3 veya sonrasına yükseltilmeden önce IPsec’e taşınmalıdır.

Bu yazıdaki konfigürasyonlar site-to-site tünel içindir. Uzaktan erişim tarafında FortiGate için yol, Fortinet’in SSL VPN’den IPsec’e geçiş kılavuzudur.

VPN protokolleri ve tünelleme teknolojileri

Şube ve saha cihazlarında, özellikle MikroTik ve Teltonika’da, IPsec’in yanında başka tünel protokolleri de sık kullanılır. Cisco, Huawei ve FortiGate ile kurulacak üreticiler arası bir tünelde ortak payda genellikle IPsec’tir; diğer protokoller daha çok aynı tip cihazlar arasında ya da uzaktan erişimde tercih edilir.

RouterOS dokümantasyonu bunların yanında SSTP, IPIP, EoIP ve ZeroTier’i de listeler. Teltonika ise OpenVPN tabanlı yönetilen bir hizmet olarak RMS VPN sunar. Bu yazı IPsec’e odaklanıyor; MikroTik ve Teltonika için IPsec örnekleri konfigürasyon bölümünde.

IPsec’in parçaları

IPsec tek bir protokol değil, birlikte çalışan bir parçalar kümesidir.

• IKE (Internet Key Exchange): İki ucun birbirini doğruladığı ve anahtarları ürettiği kontrol protokolüdür. Güncel tercih IKEv2’dir; IKEv1 eski kurulumlarla uyumluluk için hâlâ karşımıza çıkar. IKE, UDP 500 üzerinden konuşur; arada NAT varsa UDP 4500’e geçer (NAT-T).
• IKE SA ve Child SA: IKE önce kendi güvenli kanalını (IKEv2’de IKE SA, IKEv1’de faz 1) kurar. Kullanıcı trafiğini taşıyan IPsec SA’lar (IKEv2’de Child SA, IKEv1’de faz 2) bu kanal üzerinden müzakere edilir. Sahada “faz 1” ve “faz 2” terimleri IKEv2 için de kullanılır.
• ESP: Kullanıcı trafiğini şifreleyen ve bütünlüğünü koruyan protokoldür. Site-to-site VPN’de tunnel modu kullanılır: orijinal IP paketi bütünüyle şifrelenir ve önüne yeni bir IP başlığı eklenir.
• Öneriler (proposal): İki ucun üzerinde anlaşacağı şifreleme, bütünlük ve Diffie-Hellman grubu setleri. İki uçta ortak bir set yoksa müzakere başarısız olur. Cisco’nun IKEv2 dokümantasyonu DES, MD5 ve DH grup 1, 2 ve 5 yerine SHA-256 ve DH grup 14 veya üzerini önerir.
• PFS: Child SA yenilenirken yeni bir Diffie-Hellman değişimi yapılmasıdır. Bir anahtarın ele geçirilmesi önceki ve sonraki anahtarları açığa çıkarmaz. İki uçta aynı şekilde açık ya da kapalı olmalıdır.
• Kimlik doğrulama: Önceden paylaşılan anahtar (PSK) ya da sertifika. PSK kurulumu kolaydır ama her tünel için güçlü ve ayrı bir anahtar gerekir; çok sayıda tünelde sertifika yönetimi daha sürdürülebilirdir.

Route-based ve policy-based VPN

Bir IPsec ağ geçidi, bir paketi şifreleyip tünele göndermeye iki farklı yolla karar verebilir. Bu seçim konfigürasyonun yapısını, ölçeklenmeyi ve sorun gidermeyi doğrudan belirler.

Policy-based

Policy-based VPN’de hangi trafiğin şifreleneceğini bir politika belirler: genellikle bir ACL ya da firewall politikası. “10.0.20.0/24’ten 10.2.10.0/24’e giden trafik bu karşı uca, şifreli gitsin” gibi. Cisco’da bunun klasik biçimi fiziksel WAN arayüzüne uygulanan crypto map’tir; Huawei’de ACL ile eşleşen trafiği seçen bir IPsec politikası (IPsec policy) WAN arayüzüne uygulanır; FortiGate’te firewall politikasının eylemi ipsec olur.

Bu modelde tünelin bir arayüzü yoktur. Politikada tanımlanan her kaynak–hedef ağ çifti, karşı uçta da aynen tanımlanmak zorundadır ve çoğu zaman her çift için ayrı bir IPsec SA kurulur. Merkezde üç, şubede bir VLAN olan senaryomuzda bu üç ağ çifti demektir; şubeye ikinci bir VLAN eklendiğinde altıya çıkar.

Avantajı basitliğidir: değişmeyen birkaç ağ için hızlı kurulur ve eski cihazlarla birlikte çalışmak için bazen tek seçenektir. Dezavantajları ise büyüdükçe ortaya çıkar:

• Yeni bir ağ eklemek iki uçta da politika değişikliği ister.
• Dinamik yönlendirme kullanılamaz; tünelin bir arayüzü olmadığı için OSPF ya da BGP komşuluğu kurulamaz.
• Yedek tünele geçiş (failover) zor ya da imkânsızdır.
• NAT ile etkileşim dikkat ister: trafik şifrelenmeden önce NAT’a uğrarsa politikayla eşleşmez. Cisco’da crypto map kullanılan bir arayüzde NAT varsa, VPN trafiği NAT’tan muaf tutulmalıdır.

Route-based

Route-based VPN’de tünel, bir sanal tünel arayüzü olarak görünür (Cisco’da VTI, Huawei’de tunnel arayüzü, FortiGate’te IPsec arayüzü). Hangi trafiğin tünele gireceğine yönlendirme tablosu karar verir: “10.2.0.0/16’ya giden trafik Tunnel1 üzerinden gider.” Tünele giren her şey şifrelenir.

Bu yaklaşımın sonuçları:

• Yeni bir ağ eklemek çoğu zaman yalnızca bir route değişikliğidir.
• Tünel üzerinden OSPF ya da BGP çalıştırılabilir; yedek tünele geçiş yönlendirme protokolüne bırakılabilir.
• Firewall politikası, NAT, QoS ve izleme tünel arayüzü üzerinden ayrı ayrı uygulanabilir. Cisco, VTI’de bu özelliklerin tünel başına uygulanabildiğini belirtir.
• Trafik seçicileri genellikle geniştir (0.0.0.0/0 ya da özet ağlar); asıl ayrımı yönlendirme ve firewall politikası yapar.

FortiGate’te varsayılan mod route-based’dir. Fortinet, karşı uç destekliyorsa her zaman route-based tüneli tercih etmeyi önerir; policy-based tüneli eski (legacy) yöntem olarak tanımlar ve karşı uç sanal tünel arayüzü kullanamıyorsa ya da WAN arayüzüne bağlı crypto map yapısındaysa tek seçenek olarak görür.

İki model birbirine bağlandığında: trafik seçicileri

Gerçek hayatta iki uç her zaman aynı modeli kullanmaz. Merkezde route-based bir FortiGate, karşıda yalnızca policy-based destekleyen eski bir cihaz olabilir. Burada sorun trafik seçicileridir (proxy ID olarak da anılır): IPsec SA müzakeresinde her uç, SA’nın hangi kaynak ve hedef ağları kapsadığını bildirir.

Route-based uç varsayılan olarak geniş bir seçici (örneğin 0.0.0.0/0) önerirken policy-based uç belirli ağ çiftleri bekliyorsa, bu uyuşmazlık faz 2 hatasına neden olabilir. IKEv2, yanıt veren ucun önerilen seçiciyi kendi politikasına göre daraltmasına izin verir (traffic selector narrowing, RFC 7296); bu yüzden bazı cihaz çiftleri geniş seçiciyle de anlaşabilir. Ama her cihaz bunu desteklemez ya da aynı şekilde uygulamaz; bu davranışa güvenmek yerine seçicileri açıkça eşlemek daha öngörülebilirdir. Çözüm, route-based uçta da seçicileri karşı ucun beklediği ağlara daraltmaktır. FortiGate’te bu faz 2 tanımındaki kaynak ve hedef alt ağlarla yapılır. Cisco IOS XE’de 16.12 ile gelen Multi-SA VTI, tünel arayüzüne bir şifreleme ACL’si bağlayarak VTI özelliklerini koruyup protokol seviyesinde policy-based gibi davranmayı sağlar.

Kural basit: iki uçtaki seçiciler birbirinin aynası olmalıdır. Merkezde “10.0.0.0/16 → 10.2.0.0/16”, şubede “10.2.0.0/16 → 10.0.0.0/16”.

Paket boyutu: tünelin gizli maliyeti

Tunnel modunda ESP, orijinal paketin önüne yeni bir IP başlığı, ESP başlığı ve sonuna dolgu ile bütünlük alanı ekler. Kullanılan algoritmaya göre değişen bu ek yük, tünelden geçebilecek en büyük kullanıcı paketini küçültür.

Belirtisi tanıdıktır: ping çalışır, küçük web sayfaları açılır, ama dosya kopyalama ya da büyük bir sayfa takılır. Path MTU Discovery’nin dayandığı ICMP mesajları arada bir yerde engelleniyorsa sorun daha da belirginleşir. Çözüm, tünelde TCP MSS değerini ek yükü karşılayacak kadar düşürmek ve gerekiyorsa tünel arayüzünün MTU’sunu ayarlamaktır. Doğru değer kullanılan algoritmaya ve WAN bağlantısına (örneğin PPPoE) göre değişir; büyük paketlerle test ederek belirleyin.

Konfigürasyon

Aşağıda merkez tarafının route-based site-to-site tüneli üç üreticide gösteriliyor; şube tarafı aynı yapının aynasıdır (adresler ve ağlar yer değiştirir). Ardından şube tarafı için MikroTik ve Teltonika örnekleri geliyor. Örnekler yazının başında belirtilen sürümlerin resmî dokümantasyonundaki yapıya göre hazırlandı ve laboratuvarda test edilmedi. Önerileri iki uçta birebir aynı tutun; anahtarları örnekteki gibi bırakmayın.

Merkez örneklerinin önerileri birbirinden farklıdır (AES-128 / AES-256, PFS). Farklı üreticiler arasında kurulacak bir tünelde faz 1 ve faz 2 önerilerini ve PFS ayarını iki uçta eşleyin: örneğin FortiGate faz 2’de PFS varsayılan olarak açıktır, Cisco IPsec profilinde ise set pfs yazılmadıkça kapalıdır.

Cisco IOS XE

Route-based tünel IKEv2 ve VTI ile kurulur: IKEv2 önerisi ve politikası, anahtarlık, IKEv2 profili, IPsec transform set ve profil, son olarak profili koruma olarak kullanan tünel arayüzü.

crypto ikev2 proposal IKEV2-PROP
 encryption aes-cbc-256
 integrity sha256
 group 14
!
crypto ikev2 policy IKEV2-POL
 proposal IKEV2-PROP
!
crypto ikev2 keyring KR-SUBE
 peer SUBE
  address 198.51.100.2
  pre-shared-key <guclu-anahtar>
!
crypto ikev2 profile PROF-SUBE
 match identity remote address 198.51.100.2 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local KR-SUBE
!
crypto ipsec transform-set TS-SUBE esp-aes 256 esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile IPSEC-SUBE
 set transform-set TS-SUBE
 set ikev2-profile PROF-SUBE
!
interface Tunnel1
 ip address 169.254.10.1 255.255.255.252
 tunnel source GigabitEthernet0/0/0
 tunnel mode ipsec ipv4
 tunnel destination 198.51.100.2
 tunnel protection ipsec profile IPSEC-SUBE
!
ip route 10.2.0.0 255.255.0.0 Tunnel1

Aynı tünelin policy-based karşılığı, tünel arayüzü yerine WAN arayüzüne uygulanan bir crypto map’tir:

ip access-list extended VPN-SUBE
 permit ip 10.0.0.0 0.0.255.255 10.2.0.0 0.0.255.255
!
crypto map CMAP 10 ipsec-isakmp
 set peer 198.51.100.2
 set transform-set TS-SUBE
 set ikev2-profile PROF-SUBE
 match address VPN-SUBE
!
interface GigabitEthernet0/0/0
 crypto map CMAP

Burada şifrelenecek trafiği VPN-SUBE ACL’si belirler ve şubede bu ACL’nin aynası tanımlanmalıdır. Karşı uç policy-based kalacaksa ama merkezde VTI kullanmak isteniyorsa, Multi-SA VTI ile tünel arayüzüne tunnel protection ipsec policy ipv4 VPN-SUBE eklenerek seçiciler ACL’ye göre daraltılabilir.

Huawei NetEngine AR

Huawei AR yönlendiricilerinde route-based tünel, tunnel-protocol ipsec ile tanımlanan bir tunnel arayüzüne IPsec profili uygulanarak kurulur.

ike proposal 5
 encryption-algorithm aes-128
 authentication-algorithm sha2-256
 dh group14
#
ike peer SUBE
 pre-shared-key cipher <guclu-anahtar>
 undo version 1
 ike-proposal 5
#
ipsec proposal PROP-SUBE
 esp authentication-algorithm sha2-256
 esp encryption-algorithm aes-128
#
ipsec profile PROF-SUBE
 proposal PROP-SUBE
 ike-peer SUBE
#
interface Tunnel0/0/1
 ip address 169.254.10.1 255.255.255.252
 tunnel-protocol ipsec
 source GigabitEthernet0/0/0
 destination 198.51.100.2
 ipsec profile PROF-SUBE
#
ip route-static 10.2.0.0 255.255.0.0 Tunnel0/0/1

Örnek, NetEngine AR600/AR6000 serisi V300R019 dokümantasyonundaki yapıya göre yazıldı. IKE peer altındaki undo version 1, dokümandaki örnekte olduğu gibi IKEv1’i kapatır ve müzakereyi IKEv2’ye bırakır. Huawei’de policy-based karşılığı, şifrelenecek trafiği bir ACL ile seçen IPsec politikasının WAN arayüzüne uygulanmasıdır; bu yapının komutlarını kendi model ve sürümünüzün dokümantasyonundan alın.

FortiGate (FortiOS 7.4 / 7.6)

FortiGate’te IPsec tüneli varsayılan olarak route-based’dir: faz 1 ve faz 2 tanımı bir IPsec arayüzü oluşturur, trafiği bu arayüze bir route yönlendirir ve geçişe firewall politikaları izin verir. Politikalardaki MERKEZ-AGLARI ve SUBE-AGLARI adres nesneleri önceden tanımlanmalıdır.

config vpn ipsec phase1-interface
    edit "to-sube"
        set interface "wan1"
        set ike-version 2
        set proposal aes256-sha256
        set dhgrp 14
        set remote-gw 198.51.100.2
        set psksecret <guclu-anahtar>
    next
end
config vpn ipsec phase2-interface
    edit "to-sube-p2"
        set phase1name "to-sube"
        set proposal aes256-sha256
        set dhgrp 14
        set src-subnet 10.0.0.0 255.255.0.0
        set dst-subnet 10.2.0.0 255.255.0.0
    next
end
config router static
    edit 0
        set dst 10.2.0.0 255.255.0.0
        set device "to-sube"
    next
end
config firewall policy
    edit 0
        set name "merkez-to-sube"
        set srcintf "internal"
        set dstintf "to-sube"
        set srcaddr "MERKEZ-AGLARI"
        set dstaddr "SUBE-AGLARI"
        set action accept
        set schedule "always"
        set service "ALL"
    next
    edit 0
        set name "sube-to-merkez"
        set srcintf "to-sube"
        set dstintf "internal"
        set srcaddr "SUBE-AGLARI"
        set dstaddr "MERKEZ-AGLARI"
        set action accept
        set schedule "always"
        set service "ALL"
    next
end

Faz 2’deki kaynak ve hedef alt ağlar, trafik seçicileridir. Karşı uç da route-based ise bunlar geniş bırakılabilir; karşı uç policy-based ise onun tanımıyla birebir aynı olmalıdır. Policy-based tünel FortiGate’te hâlâ kurulabilir (firewall politikasında action ipsec), ama önce config system settings altında set gui-policy-based-ipsec enable ile özelliğin açılması gerekir. Fortinet bu yöntemi yalnızca route-based tünel kuramayan karşı uçlar için önerir.

Uzaktan erişim için: FortiOS 7.6.3 ve sonrasında SSL VPN tünel modu yoktur. Evden çalışanlar için dial-up IPsec VPN kullanılır; tarayıcı tabanlı erişim gerekiyorsa ve model destekliyorsa Agentless VPN ayrıca açılır.

Şube tarafı: MikroTik ve Teltonika

Şube ve saha bağlantılarında sık karşılaşılan iki platform MikroTik ve Teltonika. Aşağıdaki örnekler, merkezdeki FortiGate örneğinin karşısındaki şube tarafını gösterir. İki örnek de seçicilerle çalışan (policy-based) bir tünel kurar. Seçiciler FortiGate faz 2’deki alt ağların aynasıdır (yerel 10.2.0.0/16, uzak 10.0.0.0/16); öneriler de FortiGate örneğiyle eşleşir: AES-256, SHA-256, DH grup 14 (MODP2048) ve PFS açık. Merkezde Cisco VTI kullanılıyorsa seçicileri Multi-SA VTI ile daraltmak gerekir.

MikroTik RouterOS 7

/ip ipsec profile
add name=merkez dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256
/ip ipsec proposal
add name=merkez auth-algorithms=sha256 enc-algorithms=aes-256-cbc pfs-group=modp2048
/ip ipsec peer
add name=merkez address=203.0.113.1/32 exchange-mode=ike2 profile=merkez
/ip ipsec identity
add peer=merkez secret=<guclu-anahtar>
/ip ipsec policy
add src-address=10.2.0.0/16 dst-address=10.0.0.0/16 tunnel=yes action=encrypt proposal=merkez peer=merkez
/ip firewall nat
add chain=srcnat action=accept place-before=0 src-address=10.2.0.0/16 dst-address=10.0.0.0/16

RouterOS’ta IPsec policy-based’dir: hangi trafiğin şifreleneceğini /ip ipsec policy belirler. NAT satırı, tünele girecek trafiği masquerade kuralından önce NAT’tan muaf tutar; yoksa kaynak adres değişir ve politika eşleşmez. RouterOS dokümantasyonu ayrıca FastTrack açıksa paketlerin IPsec politikasını atlayabileceği konusunda uyarır; IPsec trafiğini FastTrack’ten de muaf tutun. Route-based bir yapı gerekiyorsa GRE over IPsec kullanılır: GRE arayüzündeki IPsec secret alanı IPsec yapılandırmasını kendisi oluşturur, trafik GRE arayüzüne route ile yönlendirilir. Bu durumda karşı uçta da GRE gerekir.

Teltonika RutOS

Teltonika’da IPsec, WebUI’de Services → VPN → IPsec altında yapılandırılır:

Bazı alanlar yalnızca gelişmiş WebUI modunda görünür. Route-based bir yapı için Teltonika’nın kendi örneği de GRE over IPsec kullanır: GRE tüneli ayrıca tanımlanır, IPsec örneğinde Type Transport seçilir, Bind to alanında GRE arayüzü gösterilir ve izin verilen protokol gre yapılır.

Doğrulama ve sorun giderme

Doğrulama komutları

Cisco IOS XE:

show crypto ikev2 sa
show crypto ipsec sa
show crypto session interface Tunnel1
show ip route 10.2.0.0
debug crypto ikev2
debug crypto ipsec

Huawei:

display ike sa
display ipsec profile
display ipsec proposal
display ip routing-table 10.2.0.0

FortiGate:

get vpn ipsec tunnel summary
diagnose vpn ike gateway list name to-sube
diagnose vpn tunnel list name to-sube
get vpn ipsec tunnel details
get router info routing-table details 10.2.10.20
diagnose vpn ike log filter rem-addr4 198.51.100.2
diagnose debug application ike -1
diagnose debug enable

FortiGate’te diagnose vpn ike gateway list çıktısındaki durum “established” ise faz 1 kuruludur. diagnose vpn tunnel list çıktısında sa=0, Fortinet’e göre seçicilerin uyuşmadığını ya da tünele trafik başlatılmadığını gösterir; sa=1 SA’nın eşleştiğini, sa=2 ise yalnızca yeniden anahtarlama sırasında görülür. Fortinet’e göre faz 2 şifreleme ve bütünlük algoritmalarının uyuşmaması da kontrol edilmelidir; seçiciler get vpn ipsec tunnel details ile görülebilir. IKE log filtresi 7.4.0 öncesinde dst-addr4 ile yazılır. Debug’ı işiniz bitince diagnose debug disable ve diagnose debug reset ile kapatın.

MikroTik:

/ip ipsec active-peers print
/ip ipsec installed-sa print
/ip ipsec policy print

Tünel kurulduğunda installed-sa iki yönde birer SA gösterir.

Teltonika:

ipsec status
ipsec statusall

Komutlar RutOS CLI’da çalışır; statusall ayrıntılı çıktı verir.

Sorun giderme sırası

Sorunu katman katman ilerleyerek daraltın:

1. Faz 1 kurulmuyor. İki ağ geçidi birbirine UDP 500 ve 4500 üzerinden ulaşabiliyor mu? Aradaki bir firewall bu portları ya da ESP’yi engelliyor olabilir. Ardından IKE sürümü, öneri (şifreleme, bütünlük, DH grubu), PSK ve kimlik eşleşmesini kontrol edin. “No proposal chosen” türü mesajlar öneri uyuşmazlığını gösterir.
2. Faz 1 kurulu, faz 2 kurulmuyor. En sık neden trafik seçicilerinin uyuşmamasıdır; özellikle bir uç route-based, diğeri policy-based ise. Sonra faz 2 önerisi ve PFS ayarını karşılaştırın; bir uçta PFS açık, diğerinde kapalıysa faz 2 kurulmaz.
3. Tünel kurulu, trafik geçmiyor. Route-based’de trafik tünel arayüzüne yönlendiriliyor mu? Yönlendirme tablosunda hedef ağ tünel arayüzünü göstermelidir. FortiGate’te iki yönde de firewall politikası var mı? Policy-based’de trafik şifrelenmeden önce NAT’a uğrayıp politikadan çıkıyor mu? Dönüş yolu aynı tünelden mi geliyor?
4. Küçük paketler geçiyor, büyükler takılıyor. MTU/MSS sorunudur. Tünelde MSS değerini düşürün ve farklı boyutlarda, parçalanmaya izin vermeyen pinglerle test edin.
5. Tünel belirli aralıklarla kopuyor. SA yenileme (rekey) sırasında iki ucun ömür süreleri ve PFS ayarı uyuşuyor mu? Dead peer detection ayarlarını ve WAN bağlantısının kararlılığını kontrol edin.

Sahada sık görülen hatalar

• Seçicileri tek uçta değiştirmek: Policy-based bir tünele yeni ağ eklenip karşı uç unutulunca yalnızca yeni ağ çifti için faz 2 kurulmaz; mevcut trafik çalıştığı için sorun geç fark edilir.
• Firewall politikasını unutmak: FortiGate’te tünel kurulur ama politika yoksa tek paket geçmez.
• NAT muafiyetini atlamak: Crypto map kullanılan Cisco arayüzünde VPN trafiği önce NAT’a uğrar ve şifrelenmez.
• MSS ayarını yapmamak: Tünel çalışıyor görünür ama uygulamalar rastgele takılır.
• Eski önerilerle devam etmek: 3DES, SHA-1 ve DH grup 2/5 gibi zayıf algoritmalar karşı uçla uyumluluk adına bırakılır ve unutulur.
• MikroTik’te NAT ve FastTrack muafiyetini atlamak: Tünel kurulur ama trafik masquerade’e ya da FastTrack’e takılıp IPsec politikasını atlar.
• SSL VPN tünel modunu planlamaya devam etmek: FortiOS 7.6.3 ve sonrasında bu mod yok; yükseltme öncesinde IPsec’e geçiş planlanmalıdır.

Üretici yaklaşımları

Şube tarafı:

Sonuç

IPsec’in şifreleme tarafı çoğu zaman sorun çıkarmaz; sorunların büyük kısmı hangi trafiğin tünele gireceğinin nasıl tanımlandığından doğar. Policy-based modelde bu kararı iki uçta birebir aynı tutulması gereken politikalar verir; route-based modelde yönlendirme tablosu verir ve tünel, üzerinde politika, NAT ve yönlendirme protokolü çalıştırılabilen bir arayüz hâline gelir.

Karşı uç destekliyorsa route-based tasarımı tercih edin; policy-based bir uçla konuşmanız gerekiyorsa seçicileri iki uçta aynaya çevirin. Sorun giderirken de aynı sırayı izleyin: önce faz 1, sonra faz 2, sonra yönlendirme ve politika, en son paket boyutu.

Tünelin iki ucundaki ağların nasıl bölümlendiğini ve aralarındaki trafiğin nerede denetlendiğini ağ segmentasyonu ve DMZ yazısında, tünelden gelen trafiğe uygulanacak politikaların mantığını da stateful firewall yazısında anlattık.

Kaynaklar

• Cisco: Configure a Multi-SA Virtual Tunnel Interface on a Cisco IOS XE Router
• Cisco: Configuring Internet Key Exchange Version 2 (IKEv2) and FlexVPN Site-to-Site
• Cisco: IKEv2 route-based site-to-site VPN on Cisco routers (IOS XE 17.3, İtalyanca)
• Cisco Community: Implementing IKEv2 VRF-aware Crypto Map VPN
• Huawei: NetEngine AR600/AR6000 V300R019, Example for Configuring a Tunnel Template Interface for IPsec Tunnel Setup
• Fortinet: FortiOS 7.6.5, SSL VPN tunnel mode to IPsec VPN migration
• Fortinet Community: Changes on SSL VPN modes starting from v7.6.3
• Fortinet Community: IPsec traffic flow and use cases with policy-based vs route-based tunnels
• Fortinet Community: Enable “Policy-Based IPsec VPN” configuration
• Fortinet Community: Troubleshooting Tip, IPsec VPN tunnels
• Fortinet: FortiOS CLI Reference, config vpn ipsec phase1-interface
• MikroTik: RouterOS IPsec
• MikroTik: RouterOS Virtual Private Networks
• MikroTik: CLI reference, /ip ipsec profile
• MikroTik: CLI reference, /ip ipsec proposal
• Teltonika: IPsec RutOS configuration example
• Teltonika: IPsec site to site configuration between Teltonika and Fortinet devices
• Teltonika: Setting up a GRE over IPsec tunnel between RUTOS and MikroTik device
• Teltonika: How to choose the best VPN protocol on Teltonika routers