TR / EN

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

Güvenlik duvarı günlüğünde “policy id 0” görüldüğünde bunu bozuk bir kural numarası sanmak kolaydır. Çoğu IPv4 politika akışında mesaj daha basittir: paket, yönetici tarafından tanımlanmış izin politikalarından hiçbirine uymamış ve kural tabanının sonundaki görünmez ret davranışına ulaşmıştır. Asıl soru cihazın neden engellediği değil, beklediğimiz kuralın hangi eşleşme koşulunda kaçırıldığıdır.

21 Temmuz 2026 tarihli vakada belirli bir kaynaktan HTTPS servisine erişim reddediliyordu. Yeni ve geniş bir allow kuralı açmadan önce paketin giriş arayüzünü, rota nedeniyle seçilen çıkış arayüzünü, kaynak ve hedef objelerini, servis tanımını, zamanlamayı ve politika sırasını inceledik. Bu disiplin, hem sorunu dar bir değişiklikle çözdü hem de implicit deny’nin güvenlik tasarımındaki değerini korudu.

Sorunun ortaya çıkışı

Bir uygulama sunucusundan dışarıdaki izinli bir HTTPS uç noktasına bağlantı kurulamadı. Trafik günlüğünde kaynak ve hedef beklenen değerlere benziyor, eylem deny ve policy ID 0 görünüyordu. Ekip mevcut izin kuralında aynı servis adını gördüğü için FortiGate’in kuralı yanlış değerlendirdiğini düşündü. Oysa politika eşleşmesi yalnızca port adına değil tüm bağlama dayanır.

Değişiklik talebindeki kaynak bilgisi ile cihazın gördüğü kaynak adresi arasında NAT veya farklı çıkış yolu olasılığı vardı. Hedef adı birden fazla adrese çözülebiliyor, rota paketi tahmin edilenden farklı WAN arayüzüne çıkarabiliyordu. Önce tek bir kontrollü bağlantı zamanını ve beşli akışı belirledik. Böylece geçmişteki ilgisiz deny kayıtlarının analizimizi yönlendirmesini engelledik.

İlk belirtiler ve yanlış varsayımlar

En yaygın varsayım, kaynak ve hedef obje içinde adres bulunduğunda eşleşmenin garanti olduğudur. Politikanın giriş ve çıkış arayüzü, servis, kullanıcı/kimlik koşulu, schedule ve adres ailesi de uygun olmalıdır. Bir obje güncellenmiş fakat politika farklı VDOM’da veya farklı obje ile çalışıyor olabilir. Politika adı benzerliği teknik eşleşme kanıtı değildir.

İkinci yanlış yaklaşım, kuralı listenin en üstüne taşıyıp source ve destination alanlarını all yapmaktır. Bu işlem sorunu maskeleyebilir ama gereksiz erişim oluşturur. Route olmadığı durumda yeni politika da çözüm sağlamaz; local-in trafik ile forward trafik karıştırılırsa yanlış kural tabanına bakılır. Policy ID 0 sonucunu tek başına NAT hatası olarak yorumlamak da doğru değildir.

Teknik analiz

Analiz paket yönüyle başladı. Kaynak arayüz, hedef için routing tablosunun seçtiği çıkış arayüzü ve varsa SD-WAN kararı doğrulandı. Sonra policy lookup ile kaynak, hedef, protokol ve portun hangi politikaya düşmesi gerektiği kontrol edildi. Adres gruplarının gerçek üyeleri, FQDN objesinin güncel çözümü ve özel servis nesnesinin TCP/UDP tanımı incelendi. IPv4 ve IPv6 akışları ayrıldı.

Kontrollü debug flow yalnızca belirtilen kaynak, hedef ve kısa zaman aralığı için kullanıldı. Çıktıda route seçimi, policy lookup ve drop nedeni arandı; üretim cihazında sınırsız debug bırakılmadı. Donanım hızlandırma bazı mevcut oturumların çıktıda görünmesini etkileyebileceği için test yeni ve tek oturumla yapıldı. Gerekli kanıt alınınca debug hemen kapatıldı ve filtreler temizlendi.

Uygulanan çözüm veya önerilen mimari

Vakadaki izin politikası doğru kaynak objesini içeriyor fakat çıkış arayüzü eski WAN yolunu gösteriyordu. Rota değişikliğinden sonra trafik başka arayüzden çıktığı için politika eşleşmiyordu. Mevcut kuralın kapsamı, değişiklik kaydı ve ağ tasarımı doğrultusunda yeni çıkış yolu için güncellendi; kaynak, hedef ve HTTPS servisi dar bırakıldı. Yeni geniş kural oluşturulmadı.

Politika açıklamasına iş sahibi, talep referansı ve erişim amacı eklendi. Route ve politika değişikliklerinin birlikte değerlendirilmesi için kontrol adımı oluşturuldu. Doğrulamada izinli kaynak başarılı olurken başka bir test kaynağının implicit deny ile kalması beklendi ve doğrulandı. Böylece çözüm yalnızca pozitif testi değil güvenlik sınırının korunmasını da kanıtladı.

Alternatifler ve karar gerekçesi

Yeni bir politika eklemek mevcut kuralı değiştirmeden hızlı olabilirdi; ancak aynı iş akışı için iki kural sahiplik ve sıra karmaşası yaratacaktı. Arayüz çifti gerçekten kalıcı olarak değiştiği için mevcut kontrollü politikanın güncellenmesi daha anlaşılırdı. Multiple-interface politika veya zone kullanımı daha büyük tasarım değişikliği gerektiriyordu ve ayrı çalışma olarak bırakıldı.

Hedefi FQDN objesiyle yönetmek dinamik servislerde yararlı olabilir, fakat DNS güncelliği ve çoklu adresler ayrıca izlenmelidir. Sabit adres objesi daha öngörülebilir olsa da hizmet sağlayıcı adres değiştiriyorsa kırılgandır. Seçim hizmet sahibinin yayınladığı entegrasyon modeline göre yapılmalı; geçici olarak all hedefi açmak kalıcı çözüm sayılmamalıdır.

Güvenlik ve operasyonel riskler

Implicit deny kaldırılması gereken bir engel değil, açıkça izin verilmeyen trafiği durduran temel kontroldür. Sorun giderirken oluşturulan geçici kural süreli, kayıtlı ve otomatik kapanışlı değilse unutulabilir. Debug çıktısı gerçek adres, port ve politika adlarını içerir; destek kaydına veya genel kanala ham kopyalanmamalıdır. Yönetim erişimi ve VDOM bağlamı doğrulanmalıdır.

Politika değişikliği mevcut oturumlarda hemen görünmeyebilir; session tablosuna müdahale üretim bağlantılarını kesebilir. Yalnızca onaylı test akışı hedeflenmeli ve iş sahibiyle pencere belirlenmelidir. Kural sırası, gölge politikalar, hit count ve son kullanım bilgisi periyodik gözden geçirilmelidir. Başarılı erişim kadar gereksiz kaynakların reddedildiği de regresyon testine eklenmelidir.

Çıkarılan Dersler

Kontrol Listesi