IPsec VPN Ayakta Ama Trafik Geçmiyor: Sayaçlarla Teşhis

VPN yazısındaki sorun giderme sırasının üçüncü adımı tek bir cümleyle özetlenebilir: “Tünel kurulu, trafik geçmiyor.” Bu yazı o adımı açıyor. Amaç, iki uçtaki IPsec SA sayaçlarını, kontrollü bir test trafiğini ve paket yakalamayı birlikte okuyarak arızanın hangi yönde ve hangi bölümde olduğunu daraltmak.

Faz 1 ve faz 2’nin kurulamaması, MTU/MSS, sertifikalar ve SD-WAN tasarımı burada ele alınmıyor; bunların bir kısmı VPN yazısında var. Komutlar resmî belgelerden alındı, laboratuvarda denenmedi. Çıktılar temsilîdir; anahtar materyali içermez.

Senaryo ve test trafiği

Topoloji VPN yazısındakiyle aynı: Merkez 10.0.0.0/16, WAN adresi 203.0.113.1. Şube 10.2.0.0/16, WAN adresi 198.51.100.2. Merkezde VPN yazısındaki Cisco, Huawei ya da FortiGate örneklerinden biri çalışıyor olabilir; şube cihazı da kendi SA çıktısında aynı bilgiyi gösterir.

Test için kullanılan hostlar:

Host	Adres
Merkez istemcisi	10.0.20.15 (VLAN 20)
Merkez web sunucusu	10.0.30.10 (VLAN 30)
Şube istemcisi	10.2.10.20
Şube uygulama sunucusu	10.2.10.50

Belirti: IKE SA ve IPsec SA’lar kurulu görünüyor, ama merkezden şubeye ping ve uygulama trafiği geçmiyor.

“Tünel ayakta” ne anlama gelir?

IKE SA, iki ağ geçidinin birbirini doğruladığı ve anahtarları ürettiği kontrol kanalıdır. Kullanıcı trafiğini IKE SA üzerinden kurulan IPsec SA’lar taşır; IKEv2 bunlara CHILD SA der. RFC 4301’e göre bir IPsec SA tek yönlüdür; iki yönlü iletişim için her yönde bir tane olmak üzere bir SA çifti gerekir ve IKE SA’ları çift olarak kurar. Her SA çiftinin bir trafik seçicisi vardır: hangi kaynak ve hedef ağları kapsadığı. İki ayrı gerçek bu yüzden karıştırılmamalıdır:

IKE SA kurulu: Kontrol trafiği iki uç arasında geçiyor.
Doğru CHILD SA çifti kurulu ve kullanılıyor: Test edilen akış bu çiftin seçicileriyle eşleşiyor; paketler giden SA ile şifreleniyor, karşı uçta gelen SA ile çözülüyor.

Policy-based bir tünelde birden çok seçici çifti olabilir. VPN yazısındaki örnekte merkezdeki üç VLAN için üç ayrı çift vardı. İnceleme, test akışını kapsayan SA çiftinin sayaçlarıyla yapılmalıdır. Route-based tünelde genellikle tek ve geniş seçicili bir SA çifti vardır; o zaman pakete tünelin yolunu rota belirler.

Sayaçları doğru okumak

Her uçta iki SA görülür: giden SA’da şifrelenen (encrypt ya da encaps), gelen SA’da çözülen (decrypt ya da decaps) paketler sayılır. Bir uçtaki giden SA ile karşı uçtaki gelen SA aynı SA’dır ve aynı SPI’yi taşır. Yeniden anahtarlama sonrasında yeni SA’lar ve yeni SPI’ler oluşur; iki ucun aynı SA’lara baktığından emin olmak için SPI’ler karşılaştırılır.

Ölçüm kuralı basittir: İki uçta da testten hemen önce ve hemen sonra sayaç okunur, farka bakılır. Mutlak değerler başka trafiği de içerir; sayaçları sıfırlamak da başka akışları etkileyebileceği için tercih edilmez.

Örnek test: Merkez istemcisinden şube istemcisine 20 ping, 10.0.20.15 → 10.2.10.20. Beklenen sonuç, her iki uçta da yaklaşık 20 paketlik bir farktır: merkezde 20 şifreleme ve 20 çözme, şubede 20 çözme ve 20 şifreleme. Temsilî bir okuma:

Sayaç (test sırasındaki fark)	Merkez	Şube
Şifrelenen (giden SA)	+20	0
Çözülen (gelen SA)	0	0

Bu tablo, aşağıdaki ikinci senaryoya karşılık gelir: Merkez şifreliyor, şube çözmüyor.

Sayaçlar bölgeyi daraltır, nedeni kanıtlamaz. Aynı sayaç tablosu birden çok nedenle oluşabilir. Her sonuç WAN yakalaması, SPI ve seçici bilgisi, düşürme sayaçları ve session tablosuyla doğrulanmalıdır.

Her dal bir sonraki doğrulama adımına yönlendirir. Sayaç tablosu nerede bakılacağını söyler, neden olduğunu değil.

Üç senaryo

1. Yerel uç şifrelemiyor

Merkezdeki giden SA’nın sayacı test sırasında artmıyorsa paket bu SA ile şifrelenmemiştir. Bu, arızanın kesinlikle merkez VPN cihazının içinde olduğunu kanıtlamaz: Test paketi cihaza hiç ulaşmamış olabilir. Önce paketin cihazın LAN tarafına geldiği akış izleme ya da yakalamayla doğrulanır. Geliyorsa bakılacak yerler:

Rota: Route-based tünelde hedefe giden rota tünel arayüzünü göstermelidir. Daha özgül bir rota trafiği başka yere götürebilir. Örneğin unutulmuş bir 10.2.10.0/24 statik rotası, tünele giden 10.2.0.0/16 rotasından uzun önek eşleşmesiyle kazanır. Belirti: 10.2.10.20 için rota sorgusu tünel dışında bir next-hop gösterir. En uzun önek eşleşmesi routing tablosu yazısında anlatıldı.
Seçici: Policy-based tünelde test akışı bir seçici çiftine uymalıdır. Seçiciler tek uçta değiştirildiyse yalnızca bazı ağ çiftleri çalışır.
NAT ve politika: Policy-based tünelde paket şifrelenmeden önce NAT’a uğrayıp seçiciden çıkıyor olabilir; NAT muafiyeti VPN yazısında anlatıldı. Firewall politikası bu akışı reddediyorsa paket hiç tünele gelmez.

Bu senaryoda WAN yakalaması gerekmez; doğrulama cihazın kendi akış izleme aracıyla yapılır.

2. Yerel uç şifreliyor, karşı uç çözmüyor

Merkezde şifreleme artıyor, şubede çözme artmıyorsa paketler ya yolda kalıyordur ya da şubeye ulaşıp çözülmeden düşüyordur. Sorumluyu hemen servis sağlayıcıda aramak yerine şu sırayla ilerlenir:

Doğru SA çifti mi? Merkezin giden SPI’si şubenin gelen SPI’siyle aynı mı? İki uç aynı peer adreslerini mi kullanıyor?
Paket merkezden çıkıyor mu? Merkez WAN arayüzünde 198.51.100.2’ye giden ESP ya da UDP 4500 paketleri görülüyor mu?
Paket şubeye ulaşıyor mu? Şube WAN’ında aynı paketler görülüyor mu? Merkezden çıkıp şubeye ulaşmayan paketler için yol üzerindeki cihazlar incelenir: şubenin önündeki bir firewall ya da NAT cihazı.
Ulaşıyor ama çözülmüyor mu? Şubede geçersiz SPI, anti-replay ve doğrulama hatası sayaçları incelenir.

ESP mi, UDP 4500 mü? Düz ESP, IP protokol 50 olarak taşınır. RFC 7296’ya göre arada NAT tespit edilirse sonraki bütün trafik UDP 4500’den gönderilir ve ESP de UDP içinde taşınır (RFC 3948). NAT olmaması düz ESP kullanılacağını garanti etmez: Başlatan taraf baştan 4500’ü kullanabilir ve uygulamalar NAT tespit edilmese bile UDP’ye sarılmış ESP’yi işlemek zorundadır; bazı yapılandırmalar NAT-T’yi zorlar. Aynı RFC, firewall’ların UDP’ye sarılmış IPsec trafiğini geçirip düz ESP’yi geçirmeyecek ya da tam tersi biçimde yapılandırılabileceğini açıkça belirtir. Bu yüzden IKE’nin çalışması veri trafiğinin geçeceğini kanıtlamaz: UDP 500’deki IKE geçerken protokol 50 bir ara cihazda düşüyor olabilir. Hangi kapsüllemenin kullanıldığı SA çıktısında görülür; yakalama da buna göre filtrelenir.

Anti-replay. RFC 4303’e göre alıcı, sıra numarası daha önce görülmüş ya da pencerenin gerisinde kalmış paketleri atar. Yolda paketlerin sırası ciddi biçimde bozulursa geçerli paketler de bu yüzden düşebilir. Belirti, çözme sayacının beklenenden az artması ve replay hatası sayacının artmasıdır.

3. Karşı uç çözüyor, yanıt geri dönmüyor

Şubede çözme artıyor, ama şubenin giden SA’sında şifreleme artmıyorsa paket şube cihazında çözülmüştür. Bu, isteğin uygulama sunucusuna ulaştığını kanıtlamaz: Paket çözüldükten sonra seçici kontrolünde, politikada, yönlendirmede ya da hostta düşebilir. Önce hostta ya da şube LAN’ında yakalamayla isteğin ulaşıp ulaşmadığı doğrulanır. Olasılıklar ve test edilebilir belirtileri:

İç seçici kontrolü: RFC 4301’e göre çözülen paketin adresleri SA’nın seçicileriyle uyuşmuyorsa paket atılır. Bu durumda çözme sayacı artsa bile paket hosta ulaşmaz; hostta yakalama yapılırsa paket görülmez.
Dönüş rotası: Şubede 10.0.20.15 için rota sorgusu tüneli değil, ikinci bir ISP’yi ya da başka bir default route’u gösteriyorsa yanıt şifrelenmeden başka bir çıkıştan gider. Belirti: Şubenin öteki WAN’ında, kaynağı 10.2.10.20 olan şifrelenmemiş yanıtlar.
Hostun gateway’i: Yanıt veren hostun default gateway’i VPN cihazı değilse yanıt başka bir router’a gider. Bu da asimetrik bir yoldur.
Çakışan adres alanı: Şubede de 10.0.20.0/24 kullanılan bir ağ varsa, yanıt şubenin kendi bağlı ağına teslim edilir. Belirti: Rota sorgusu 10.0.20.15 için bağlı bir ağ gösterir. Çözüm adres planı ya da NAT’tır; rota yazmak tek başına çözmez.
uRPF ya da anti-spoofing: Yanıt yanlış arayüzden geliyorsa sıkı ters yol kontrolü (RFC 3704) paketi atabilir. Bu kontrol yalnızca simetrik yönlendirmenin olduğu yerlerde güvenle kullanılabilir.

Şubede şifreleme artıyor ama merkezde çözme artmıyorsa, ikinci senaryo bu kez ters yönde uygulanır.

Stateful firewall ve dönüş trafiği. Bir bağlantının yanıtları için ikinci, ters yönlü bir izin kuralı her zaman gerekmez. Stateful firewall ilk paketle bir session kaydı açar ve yanıtlar bu kayıtla eşleşip geçer; ters yönde kural yalnızca karşı taraftan yeni bağlantı başlatılacaksa gerekir. VPN yazısındaki FortiGate örneğinde iki yönde politika vardı, çünkü iki taraf da bağlantı başlatabiliyordu. Yanıt, session’ı beklenen arayüzden değil de başka bir yoldan dönerse düşer. Bunun nedeni kural eksikliği değil asimetridir; ayrıntısı stateful firewall yazısında.

Gidiş, karşı uç ve dönüşte bakılacak yerler. Vurgulu kutular sayaçların okunduğu noktalardır; geri kalanlar sayacın neden artmadığını açıklar.

Üç üreticide kanıt

Sayaç adları ve paket işleme davranışları üreticiler arasında eşdeğer değildir. Aşağıda her biri kendi belgesine göre ele alınıyor.

Cisco IOS XE: show crypto ipsec sa her SA için yerel ve uzak seçiciyi (local ident, remote ident), karşı ucu (current_peer) ve sayaçları gösterir. Cisco’nun tanımına göre #pkts encaps IPsec ile başarıyla kapsüllenen, #pkts decaps başarıyla çözülen paket sayısıdır. Gelen ve giden ESP SA’larının SPI’leri de aynı çıktıdadır. detail seçeneği #pkts no sa (send), #pkts invalid sa (rcv) ve #pkts replay failed (rcv) gibi hata sayaçlarını ekler.

show crypto ipsec sa peer 198.51.100.2
show crypto ipsec sa peer 198.51.100.2 detail

Temsilî bir parça, merkezde testten sonra. VPN yazısındaki VTI örneğinde olduğu gibi route-based tünelde seçiciler geniştir:

   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 198.51.100.2 port 500
    #pkts encaps: 1240, #pkts encrypt: 1240, #pkts digest: 1240
    #pkts decaps: 1180, #pkts decrypt: 1180, #pkts verify: 1180

Cisco’nun komut başvurusu önemli bir istisna da belirtir: C8200, C8300 ve C8500L platformlarında çözülen bir paket ardından anti-replay işleminde düşürülebilir ve bu durumda #recv errors sıfır kalabilir, çünkü paket çözülmüş olarak sayılmıştır.

Huawei NetEngine AR (AR5700, AR6700, AR8000; V600R025C00): display ipsec sa, her SA için Flow source ve Flow destination seçicilerini gösterir. [Outbound ESP SAs] altında SA encrypted packets, [Inbound ESP SAs] altında SA decrypted packets sayaçları, SPI’ler, sıra numaraları ve UDP encapsulation used for NAT traversal alanı bulunur. display ipsec statistics IPsec paket istatistiklerini verir; politika ya da profil bazında istatistik için önce ipsec policy-statistics enable gerekir. VPN yazısındaki Huawei örneği AR600/AR6000 V300R019 içindi; komut ve alanlar seriye göre doğrulanmalıdır.

display ipsec sa remote 198.51.100.2
display ipsec statistics

FortiOS (7.6): diagnose vpn tunnel list her tünel için toplam sayaçları (stat: rxp= txp=), NAT-T durumunu (natt: mode=) ve her seçici için ayrı bir SA bölümü gösterir. Bu bölümde src ve dst seçicileri, dec:pkts/bytes ve enc:pkts/bytes sayaçları ve SPI’ler bulunur. Fortinet’in örnek çıktısında bu bölüm anahtar değerlerini de içerir; çıktı paylaşılmadan önce bu alanlar silinmelidir.

diagnose vpn tunnel list name to-sube
diagnose sys session filter dst 10.2.10.20
diagnose sys session list
diagnose debug flow filter addr 10.2.10.20
diagnose debug flow trace start 20
diagnose debug enable
diagnose sniffer packet wan1 'host 198.51.100.2' 4 20 l
diagnose debug flow trace stop
diagnose debug disable

Debug yalnızca kontrollü test süresince açık kalmalı ve test biter bitmez son iki komutla kapatılmalıdır; Fortinet de komutun gereğinden uzun çalıştırılmamasını ister.

Temsilî bir parça, anahtar alanları çıkarılmış hâliyle:

name=to-sube 203.0.113.1:0->198.51.100.2:0
stat: rxp=0 txp=20 rxb=0 txb=1680
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=to-sube-p2 proto=0 sa=1 ref=2 serial=1
  src: 0:0.0.0.0/0.0.0.0:0
  dst: 0:0.0.0.0/0.0.0.0:0
  dec:pkts/bytes=0/0, enc:pkts/bytes=20/1680

FortiOS’ta donanım hızlandırma. NP işlemcili FortiGate’lerde hızlandırılan (offload edilen) trafik standart sniffer’da görünmez; diagnose debug flow de NP6 ya da NP7’ye aktarılmış oturumlarda çalışmaz. Fortinet ICMP trafiğinin offload edilmediğini belirtir; bu yüzden ping ile yapılan test akış izlemede görülür, ama aynı akışın TCP uygulama trafiği görülmeyebilir. NP7’de trafiği offload’u kapatmadan izlemek için ayrı bir NP7 sniffer’ı vardır. Offload politika bazında geçici olarak kapatılabilir; ancak bu, trafiği donanım yerine işlemciye taşır. Üretim cihazında varsayılan bir adım değildir; gerekiyorsa kısa bir bakım penceresinde ve kapsamı dar tutularak yapılmalıdır. Bir oturumun offload edilip edilmediği diagnose sys session list çıktısındaki npu info alanından anlaşılır.

Kendinizi deneyin

Alıştırma 1: Merkezden şubeye 20 ping gönderiliyor. Merkezde giden SA’nın şifreleme sayacı 20 artıyor, şubede gelen SA’nın çözme sayacı hiç artmıyor. IKE SA kurulu ve DPD mesajları iki yönde geçiyor. Hangi kontrolleri hangi sırayla yaparsınız?

Cevap ve açıklama

1. Aynı SA’ya mı bakılıyor? Merkezin giden SPI’si şubenin gelen SPI’siyle karşılaştırılır. Farklıysa iki uç farklı SA’lara bakıyordur; örneğin yeniden anahtarlama sonrası biri eski SA’yı gösteriyordur. Peer adreslerinin de beklenen 203.0.113.1 ve 198.51.100.2 olduğu doğrulanır.
2. Hangi kapsülleme kullanılıyor? SA çıktısında NAT-T kullanılıyor mu? Kullanılmıyorsa veri trafiği IP protokol 50’dir. IKE’nin ve DPD’nin geçmesi yalnızca UDP 500 ya da 4500’ün geçtiğini gösterir; ESP için bir kanıt değildir.
3. Paket merkezden çıkıyor mu? Merkez WAN’ında 198.51.100.2’ye giden ESP ya da UDP 4500 paketleri yakalanır. FortiGate’te trafik offload ediliyorsa standart sniffer’ın bunları göstermeyebileceği hesaba katılır.
4. Paket şubeye ulaşıyor mu? Şube WAN’ında aynı yakalama yapılır. Merkezde görülüp şubede görülmüyorsa sorun yoldadır. Şubenin önündeki firewall ya da NAT cihazının protokol 50’yi geçirip geçirmediği, ISP’den önce kontrol edilir.
5. Ulaşıyor ama çözülmüyor mu? Şubede geçersiz SPI, anti-replay ve doğrulama hatası sayaçlarına bakılır. Paket ulaşıyorsa sorun yolda değil, şube cihazındadır.
Neden ISP en sonda? İlk dört kontrol, sorunun iki uçtan birinde ya da şubenin kendi kenar cihazında olup olmadığını kanıtla ayırır. Servis sağlayıcıya ancak paketin merkezden çıktığı ve şubeye ulaşmadığı gösterildiğinde başvurulur.

Alıştırma 2: Merkez istemcisi 10.0.20.15, şubedeki uygulama sunucusuna (10.2.10.50, TCP 443) bağlanamıyor. Kanıtlar: (1) Şubede gelen SA’nın çözme sayacı artıyor, giden SA’nın şifreleme sayacı artmıyor. (2) Sunucuda yapılan yakalamada SYN paketleri geliyor ve sunucu SYN-ACK gönderiyor. (3) Şube cihazında 10.0.20.15 için rota sorgusu 0.0.0.0/0 üzerinden ikinci ISP’yi gösteriyor. (4) Şubede 10.0.20.0/24 kullanılan bir ağ yok. İkinci ISP ve dönüş rotası, stateful session ve çakışan adres alanı ihtimallerinden hangisi kanıtlarla destekleniyor?