FortiGate Debug Flow ile Trafik Sorunu Nasıl Analiz Edilir?

Güvenlik duvarı sorunlarında en pahalı yöntem, her tahmin için bir kural değiştirmektir. Kaynak sistem firewall’ı suçlar, ağ ekibi rotayı, güvenlik ekibi uygulamayı işaret eder; paket ise bu katmanlardan yalnızca birinde belirli bir nedenle duruyordur. FortiGate debug flow doğru sınırlarla kullanıldığında cihazın paket için verdiği kararları sıralı biçimde gösterir ve tartışmayı kanıta çevirir.

21 Temmuz 2026 tarihinde kaynak, hedef ve servis bilgisi bilinen fakat erişim sonucu açıklanamayan bir vakayı bu yöntemle ele aldık. Debug’ı genel olarak açmadık. Önce tek test oturumu, bakım zamanı ve dar filtre tanımladık; timestamp ve function-name görünürlüğünü etkinleştirdik. Yeterli paket sayısından sonra tanıyı durdurup filtreyi temizledik. Bu disiplin, aracın kendisinin operasyonel probleme dönüşmesini önledi.

Sorunun ortaya çıkışı

Bir iç uygulamadan dış hizmete belirli TCP bağlantısı zaman aşımına uğruyordu. Policy loglarında aynı hedefe ait izin ve ret kayıtları farklı zamanlarda görülüyor, standart trafik günlüğü paketin hangi route ve kural değerlendirmesinden geçtiğini yeterince açıklamıyordu. Uygulama tekrar denemeleri de çok sayıda benzer oturum üretiyordu. Tek bir kontrollü akışı izole etmek gerekiyordu.

Başlamadan önce saatler eşitlendi ve uygulama sahibinden test anı alındı. Kaynakta ad çözümleme sonucu, gerçek hedef adres ve port doğrulandı. NAT öncesi ve sonrası adresin nerede görüleceği belirlendi. Debug flow’un şifreli uygulama içeriğini çözmek için değil, FortiOS’un akış kararlarını görmek için kullanılacağı ekiplerle netleştirildi.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış yaklaşım hiçbir filtre koymadan debug başlatmaktı. Yoğun cihazda bu, konsolu okunamaz hale getirir, CPU ve yönetim oturumu üzerinde ek yük oluşturur. İkinci varsayım “received a packet” satırının paketin başarıyla iletildiği anlamına geldiğiydi. Bu yalnızca paketin bir arayüze ulaştığını gösterir; route, policy, NAT ve güvenlik profili kararları henüz verilmemiş olabilir.

Tek bir drop satırını bağlamdan koparmak da yanıltıcıdır. Aynı hedef için health check, kullanıcı testi ve yeniden iletimler farklı oturumlar olabilir. Offload edilmiş mevcut oturumların tüm paketleri CPU akışında görünmeyebilir. Debug çıkmaması paketin kesinlikle cihaza gelmediğini düşündürür, ancak yanlış VDOM, yanlış filtre, IPv6 akışı veya mevcut hızlandırılmış oturum önce elenmelidir.

Teknik analiz

Filtre kaynak ve hedef adres, gerekiyorsa port ve protokolle daraltıldı. CLI bağlamının doğru VDOM’da olduğu doğrulandı. Timestamp farklı sistem günlüklarını eşleştirmeyi, function-name ise route lookup, policy check, session ve NAT adımlarını okumayı kolaylaştırdı. Trace sayısı birkaç test bağlantısını görecek kadar sınırlandı. Test bitince önce trace durduruldu, sonra debug kapatıldı ve filtre sıfırlandı.

Çıktı kronolojik okundu: giriş arayüzü ve orijinal beşli, mevcut session eşleşmesi, route sonucu, politika kimliği, NAT dönüşümü ve drop gerekçesi. “No matching policy” ile “reverse path check fail” aynı çözümü gerektirmez; birincisi politika bağlamına, ikincisi rota simetrisine yönlendirir. UTM veya SSL inceleme sonucu görüldüğünde ilgili profil günlüklarıyla korelasyon yapıldı.

# Üretici dokümantasyonuna göre uyarlayın; örnekler placeholder'dır
diagnose debug reset
diagnose debug flow filter addr 192.0.2.40
diagnose debug flow show function-name enable
diagnose debug flow show console enable
# Kısa, onaylı trace sonrasında mutlaka durdurun
diagnose debug disable
diagnose debug reset

Uygulanan çözüm veya önerilen mimari

Dar trace, paketin beklenen politikaya ulaştığını ancak dönüş yolu kontrolünde asimetri bulunduğunu gösterdi. İkinci WAN üzerindeki daha özel rota geri dönüşü farklı arayüze yönlendiriyordu. Rota tasarımı ağ ekibiyle doğrulandı ve yalnızca ilgili hedef için istenen simetri sağlandı. Güvenlik kontrolünü global olarak gevşetmek yerine yönlendirme niyeti düzeltildi. Yeni oturumla test başarıyla tekrarlandı.

Kalıcı sorun giderme prosedürüne bir debug çalışma kartı eklendi: talep numarası, onaylayan kişi, VDOM, filtre, başlangıç-bitiş süresi ve kapatma kontrolü. Hazır komutlar gerçek adres içermeyen şablon olarak tutuldu. Standard trafik logları yeterliyse debug kullanılmıyor; yalnızca karar zinciri açıklanamadığında ve yetkili yönetici gözetiminde devreye alınıyor.

Alternatifler ve karar gerekçesi

Packet sniffer arayüz seviyesinde paketin gelip gittiğini gösterir ve debug flow’dan daha düşük karar ayrıntısına sahiptir; ikisi farklı soruları cevaplar. Trafik logları geçmiş analizi için değerlidir ancak her dahili değerlendirme adımını içermez. Policy lookup belirli bir akışın kural eşleşmesini hızlı sınar, gerçek oturumun route ve session davranışını bütünüyle göstermeyebilir.

Her sorunda debug flow kullanmak doğru değildir. Performans sorunu için arayüz sayaçları ve kapasite metrikleri, uygulama katmanı hatası için sunucu günlüğü daha uygun olabilir. Bu vakada paket FortiGate’e ulaşıyor ve karar noktası belirsiz olduğu için debug flow seçildi. Araç seçimi alışkanlığa değil, doğrulanmak istenen hipoteze bağlandı.

Güvenlik ve operasyonel riskler

Debug çıktısı ağ topolojisi, adresler, portlar, politika adları ve NAT ilişkileri içerir. Ham çıktı genel destek kanalına yüklenmemeli; erişimi sınırlı olay kaydında saklanıp paylaşım öncesi anonimleştirilmelidir. CLI yönetici yetkisi kişisel hesapla ve MFA korumalı yönetim yolundan kullanılmalıdır. Komut geçmişine parola veya gizli anahtar yazılmamalıdır.

Sınırsız trace yüksek trafikte yönetim düzlemini etkileyebilir ve kritik satırların kaçmasına yol açar. Kapatma komutu çalışma planının parçası olmalı, oturum koparsa ikinci yönetici kontrol etmelidir. Session temizlemek aktif kullanıcıları kesebileceğinden otomatik adım yapılmamalıdır. Tanı sonunda geçici filtre, policy ve rota değişikliklerinin kalmadığı bağımsız olarak doğrulanmalıdır.

Çıkarılan Dersler

Kontrol Listesi