FortiGate Troubleshooting: Trafik Gerçekten Nerede Kesiliyor?

İlgili yazılar

FortiGate NAT Troubleshooting: Policy Doğru Ama Trafik Neden Çıkmıyor?

1 hafta önce

FortiGate BGP Troubleshooting: Neighbor UP Ama Route Gelmiyor

2 hafta önce

FortiGate IPsec VPN Troubleshooting: Tünel UP Ama Trafik Neden Geçmiyor?

3 hafta önce

FortiGate üzerinde bir bağlantı problemi yaşandığında tahmin yürütmek yerine paketin firewall üzerindeki yolculuğunu adım adım takip etmek çok daha doğru bir yöntemdir.

Benim temel troubleshooting sıram:

Packet Capture → Debug Flow → Session Table → Routing/NAT doğrulaması

Asıl soru:

“Trafik neden çalışmıyor?” değil, “paket tam olarak hangi aşamada kesiliyor?”

1. Packet Capture: Paket Geliyor mu, Çıkıyor mu?

İlk olarak trafiğin FortiGate’e ulaşıp ulaşmadığını kontrol edin.

Örneğin:

diagnose sniffer packet any 'host 10.10.10.25' 4 0 l

Daha spesifik filtre:

diagnose sniffer packet any 'host 10.10.10.25 and port 443' 4 0 l

any kullanıldığında paketin hangi interface’ten girip hangisinden çıktığını görebilirsiniz. FortiGate sniffer; interface, BPF benzeri filtre, verbosity, packet count ve timestamp seçeneklerini destekler. Fortinet Dokümanlar

Burada temel sorular:

Paket FortiGate’e geliyor mu? → Hangi interface’ten geliyor? → Beklenen interface’ten çıkıyor mu? → Return trafik geri geliyor mu?

Fortinet de sniffer trace’i trafik giriş/çıkışı, next-hop ve dönüş trafiğini doğrulamak için temel troubleshooting araçlarından biri olarak öneriyor. Fortinet Dokümanlar

2. Debug Flow: FortiGate Paketle Ne Yapıyor?

Packet capture bize paketin hareketini gösterir. Debug Flow ise FortiGate’in o paket hakkında verdiği kararları anlamamızı sağlar.

Örnek:

diagnose debug reset
diagnose debug flow filter addr 10.10.10.25
diagnose debug flow show function-name enable
diagnose debug enable
diagnose debug flow trace start 100

Debug Flow çıktısında:

hangi policy’nin eşleştiği, route lookup sonucu, session oluşturulması, NAT işlemi ve olası drop nedeni

görülebilir. Fortinet’in kendi örneklerinde de debug flow çıktısı session allocation, next-hop lookup ve source NAT gibi işlem aşamalarını gösterir. Fortinet Dokümanlar

İşlem bittikten sonra debug’ı kapatın:

diagnose debug flow trace stop
diagnose debug disable
diagnose debug reset

Production ortamında mutlaka source/destination/port filtreleriyle çalışmak gerekir; filtresiz debug gereksiz miktarda çıktı oluşturabilir.

3. Session Table: Gerçekte Hangi Path Kullanılıyor?

Trafik için session oluşmuşsa:

diagnose sys session filter src 10.10.10.25
diagnose sys session list

ile ilgili session incelenebilir.

Burada özellikle:

Source/Destination → Policy ID → NAT → Incoming/Outgoing Interface → Session State → Packet Counters

kontrol edilmelidir.

FortiGate stateful çalıştığı için session table, aktif bağlantının firewall üzerinde gerçekte nasıl işlendiğini anlamak açısından oldukça değerlidir. diagnose sys session list güncel Fortinet troubleshooting dokümantasyonunda da temel session inceleme komutlarından biridir. Fortinet Dokümanlar

Hangi Durumlarda Özellikle Kullanışlı?

Bu üçlü özellikle şu senaryolarda hızlı sonuç verir:

Policy doğru ama trafik yok → Debug Flow
Routing şüpheli → Sniffer + Routing Table
NAT beklenenden farklı → Debug Flow + Session Table
IPSec VPN UP ama trafik yok → Sniffer + Session
Firewall drop ediyor → Debug Flow

Örneğin Debug Flow:

Denied by forward policy check

gösteriyorsa routing araştırmak yerine policy tarafına odaklanmak gerekir.

Route bulunuyor ama sniffer’da dönüş paketi görünmüyorsa problem FortiGate’in ötesinde veya return path tarafında olabilir.

Hardware Offload Detayını Unutmayın

Bazı FortiGate modellerinde trafik NPU tarafından hardware offload edildiğinde troubleshooting araçlarında beklediğiniz tüm paketleri veya flow detaylarını göremeyebilirsiniz.

Fortinet de bazı NP tabanlı platformlarda packet trace sırasında offloading’in sonucu etkileyebileceğini belirtiyor. Fortinet Dokümanlar

Bu nedenle capture/debug sonuçları trafik davranışıyla uyuşmuyorsa NPU offload faktörü de değerlendirilmelidir. Production ortamında offload ayarlarını değiştirmek ise etki analizi yapılmadan uygulanmamalıdır.

En Pratik Troubleshooting Akışı

Packet Capture → Debug Flow → Session Table → Route → NAT → Return Path

Bu yöntemle:

“Firewall’da bir sorun var.”

gibi genel bir varsayım yerine:

“Paket port2’den geliyor, policy 12’ye eşleşiyor, SNAT uygulanıyor, port1’den çıkıyor ancak return packet gelmiyor.”

gibi net bir teşhise ulaşabilirsiniz.

FortiGate troubleshooting’de en değerli bilgi tam olarak budur:

Trafiğin çalışmadığını değil, nerede kesildiğini bulmak.