FortiGate Firewall Sorun Giderme: Debug Flow ve Sniffer

FortiGate Firewall sorun giderme, çalışmayan bir bağlantıda paketin izini sürmektir. Fortinet’in tarif ettiği sırada önce normal durumun kaydına ve son değişikliğe bakılır.

Sonra üç soru sırayla sorulur: paket FortiGate’e geldi mi, FortiGate ona ne karar verdi ve cevabı geri geldi mi? Bu üç sorunun aracı paket yakalama (sniffer), debug flow ve oturum tablosudur. Log bu sırada yardımcıdır ama tanık değildir.

Bu yazı FortiGate Firewall yapılandırma rehberimizin 17. adımıdır. Arayüzden teşhis sırasını (önce log, sonra Policy Lookup) FortiGate kullanım rehberimizde anlattık; burada arayüzün cevap veremediği yerde komut satırına iniyorum.

Lab’da üç şey beklenenden farklı çıktı. Kurala varmadan düşen pingler logda tek satır bırakmadı, oysa aynı cihaz kural reddini logluyordu. Hiç cevap gelmeyen bağlantı logda yeşil onay işaretiyle duruyordu. Logda “0 kayıt bulundu” diyen arama da kayıtların yalnız %22,8’ini taramıştı.

Örnekteki sınır kapısında kulübenin tutanağı yalnız kulübeye varan tırı yazar. Kapıya varmadan yol kenarındaki kontrol taşında durdurulan tır tutanakta hiç görünmez; onu bulmak için yola çıkıp tırın kendisine bakmak gerekir. FortiGate’te tutanak trafik logudur, yola çıkıp tıra bakmak da sniffer ve debug flow.

Bu yazı, Kurumsal Network Kurulumu hizmetimizde yönettiğimiz firewall’larda bir bağlantı çalışmadığında izlediğimiz sırayı anlatır.

FortiGate’te Sorun Giderme Nasıl Olmalı?

Teşhis arızadan önce başlar: cihazın normal günü kaydedilir. Arıza gelince önce ne değiştiğine bakılır, sonra paketin izi sürülür. Canlı cihazda izleme araçları dar bir filtreyle, belli bir paket sayısıyla ve iş bitince kapatılarak çalıştırılır. Yakalanan trafik kullanıcıların verisini taşıdığı için iş bitince silinir.

Bu düzeni iki kaynak birlikte tarif ediyor:

1. Fortinet FortiOS 7.0 Administration Guide, Troubleshooting methodologies: en iyi uygulama, normal çalışma durumunu belirleyip kayda geçirmektir. Arıza tanımlanırken ilk sorulardan biri “Ne değişti?” sorusudur. Cevap için FortiGate’in olay logundan olası yapılandırma değişikliklerine bakılır, değişiklik varsa geri alınır ve etkisi değerlendirilir. Sayfa izleme araçlarını da tek tek sayar: paket yakalayıcı, sistem debug’ı, oturum tablosu ve log dosyaları.
2. Fortinet FortiOS 7.0 Administration Guide, Debugging the packet flow ve Performing a sniffer trace: paket akışının izlenmesi yalnız komut satırından yapılabilir. Komut gereğinden uzun çalıştırılmamalıdır, çünkü çok büyük miktarda veri üretir. Sniffer sayfası, çıktı ekrandan kayıp gitmesin diye yakalamaya başlamadan önce çıktının bir dosyaya kaydedilmesini ister.

Arızada sorulacak sorular ve araçları:

Temel Çizgi: Arızadan Önce Normal Günü Kaydedin

Fortinet’in yöntem sayfası normal durumu kaydetmek için birkaç komut sayıyor. Lab cihazında ikisinin çıktısı:

gmfw01 # CPU states: 0% user 0% system 0% nice 100% idle 0% iowait 0% irq 0% softirq
...
Memory: 2055880k total, 915808k used (44.5%), 902616k free (43.9%), 237456k freeable (11.6%)
Average network usage: 4 / 10 kbps in 1 minute, 12 / 14 kbps in 10 minutes, 6 / 8 kbps in 30 minutes
...
Average sessions: 10 sessions in 1 minute, 10 sessions in 10 minutes, 12 sessions in 30 minutes
...
gmfw01 # The total number of IPv4 sessions for the current VDOM: 10

İlk komut get system performance status, ikincisi get system session status. Lab cihazı neredeyse boşta, bu yüzden sayılar küçük.

Değerli olan sayıların kendisi değil, karşılaştırmadır: “kullanıcılar yavaş diyor” dendiğinde oturum sayısının normal bir günde 10 mu 10.000 mi olduğunu bilmek teşhisi kısaltır. Fortinet bu komutların düzenli çalıştırılıp çıktının saklanmasını istiyor, bir sıklık vermiyor. Pratik karşılığı: her büyük değişiklikten sonra ve ayda bir, tarihli bir dosyaya. Dosya BT dokümantasyonu yazımızda anlattığımız ağ belgesinin yanında durur.

Ne Değişti? Olay Logundaki Eski ve Yeni Değer

“Dün çalışıyordu” cümlesinin cevabı çoğu zaman bir değişikliktir. FortiGate her yapılandırma değişikliğini olay loguna, eski ve yeni değeriyle yazıyor. Lab’da son değişikliklere baktım (execute log filter category 1, execute log filter field logid 0100044547, execute log display):

1: date=2026-10-02 time=00:40:07 ... logdesc="Object attribute configured" user="ilker.pehlivan" ui="ssh(192.168.10.225)" action="Edit" ... cfgpath="system.interface" cfgobj="depo" cfgattr="description[Depo VLAN 90->Depo VLAN 90 gecici]" ...

Satır kimin (user), nereden (ui), hangi nesnede (cfgobj) neyi değiştirdiğini ve değerin eski ile yeni hâlini (cfgattr) gösteriyor. Arızanın başladığı saatle bu satırların saati yan yana konur. Fortinet’in önerisi de budur: değişiklik bulunursa önce o geri alınır ve etkisine bakılır.

Canlı Cihazda Debug ve Yakalama Nasıl Çalıştırılır?

Sniffer ve debug flow, cihazın işlemcisinde çalışır ve dolu bir cihazda saniyede binlerce satır üretebilir. Canlı cihazda üç kural uygulanır:

1. Dar filtre: adres ve port vermeden başlatılmaz. Lab’da her komut tek bir hedef adrese ve porta bakıyor.
2. Paket sayısı: sniffer’ın sonuna sayı (... 4 6 l), debug flow’a trace start 3 verilir; sayı dolunca çıktı kendiliğinden durur.
3. Kapatma: iş bitince diagnose debug disable ve diagnose debug reset. Fortinet’in sayfası, cihaz FortiAnalyzer ya da FortiCloud’a bağlıysa debug flow çıktısının olay logu olarak oraya da gönderildiğini yazıyor; açık unutulan debug’ın çıktısı log sunucusuna da akar.

Debug çıktısı yalnız diagnose debug enable komutunu veren oturumda görünüyor. Lab’da debug sürerken açtığım ikinci SSH oturumuna tek satır düşmedi. Çıktıyı başkasıyla paylaşacaksanız onu kendi ekranınızdan bir dosyaya kaydedersiniz.

Donanım FortiGate’lerde bir uyarı daha var. Fortinet’in sayfaları, trafiği ağ işlemcisine (NP) devreden arayüzlerde sniffer ve debug flow çıktısının değiştiğini, teşhisten önce bu devrin kapatılmasını yazıyor. Lab’daki sanal makinede ağ işlemcisi yok; çıktılardaki Trying to offloading session satırları bu yüzden sonuçsuz kalıyor.

Yakalama araçlarını kimin kullanabildiği de bir karardır. Fabrika ayarında salt okunur bir yönetici profili bile sniffer çalıştırabiliyor; bunu yönetici hesabı yazımızın salt okunur profil bölümünde ölçtük ve profilde system-diagnostics seçeneğini kapattık. Yeni lab’da aynı denemeyi tekrarladım: seçenek kapalıyken sniffer, debug flow ve oturum listesi Unknown action 0 ile reddedildi, log okuma çalışmaya devam etti.

FortiGate’in İçinde Paketin Yolu: Hangi Tanık Neyi Görür?

Bir binaya kimin girdiğini üç ayrı tanık anlatabilir: kapıdaki kamera, danışmadaki ziyaretçi defteri ve içeride sizi odaya kadar götüren görevli. Kamera kapıdan gireni ve çıkanı görür, içeride ne olduğunu bilmez. Defter yalnız danışmaya uğrayanı yazar. Görevli her adımı anlatır, ama yalnız ona soran duyar.

Bu sahneyi sınır kapısının dört parçası taşıyor:

1. Sniffer kapının giriş ve çıkış kameralarıdır: tırın kapıya girdiğini ve kapıdan çıktığını gösterir.
2. Debug flow görevlilerin telsiz kaydıdır: yol boyunca her durak tırla ne yaptığını telsize söyler, ama kaydı yalnız telsizi açan duyar.
3. Oturum tablosu dönüş listesidir: geçen her tır listeye yazılır ve dönüşte yeniden sorgulanmadan geçirilir.
4. Trafik logu kulübenin tutanağıdır: yalnız kulübeye varan tırı ve ancak görevliye yaz denmişse yazar.

Örnekteki sınır kapısında yol kenarındaki kontrol taşı kulübeden öncedir. Orada durdurulan tır kameranın giriş kaydında ve telsiz kaydında vardır, tutanakta yoktur. FortiGate’te bir paketin sırası şöyle işliyor:

1. Giriş arayüzü: paket gelir. Sniffer burada in yazar.
2. Oturum araması: paket bilinen bir bağlantıya aitse kural aranmaz, paket oturumun kaydıyla geçer. Değilse yeni bir oturum açılır.
3. Rota ve dönüş yolu denetimi: hedefin rotası bulunur ve kaynağa dönüş yolunun paketin geldiği arayüzden geçip geçmediğine bakılır. Geçmiyorsa paket burada düşer.
4. Kural: paket kurallarla karşılaştırılır; izin ya da ret burada verilir. Trafik logu bu noktadan sonra yazılır.
5. NAT: kaynak adres gerekiyorsa çevrilir.
6. Çıkış arayüzü: paket çıkar. Sniffer burada out yazar.

Bu sıranın kazancı, bir arızada hangi tanığa bakılacağını söylemesidir:

1. Paket girişte yoksa sorun FortiGate’ten öncedir: kablo, switch, istemcinin kendisi.
2. Girip çıkmıyorsa sebebi debug flow’un düştüğü satırda yazar.
3. Çıkıyor ama cevap gelmiyorsa sorun karşı taraftadır; oturum tablosunun cevap sayacı bunu sayıyla söyler.

Bedeli de aynı sıradan geliyor: log, sıranın ortasında duran tek tanıktır. Kurala varmayan paketi de, log ayarı kapalı kuraldan geçen paketi de yazmaz.

FortiGate Sniffer: Paket Geldi mi, Çıktı mı?

FortiGate’in paket yakalayıcısının iki yüzü var: arayüzdeki Packet Capture ve komut satırındaki diagnose sniffer packet. İkisi aynı soruyu cevaplıyor, ama farklı şeyler kaydediyor.

Arayüzden: Packet Capture

Menü yolu: Network → Packet Capture → Create New. Formun alanları:

1. Interface: dinlenecek arayüz. Tek bir arayüz seçilir; listede “hepsi” seçeneği yok. Lab’da muhasebe.
2. Maximum Captured Packets: fabrika ayarında 4000. Lab’da 20; sayı dolunca yakalama kendiliğinden durur.
3. Filters: açılınca Host(s), Port(s), VLAN(s) ve Protocol alanları gelir. Lab’da hedef 198.18.0.1, port 80, protokol 6 (TCP).

Kaydedilen filtre kendiliğinden başlamıyor; listede Not Running yazıyor. Filtreyi açıp Capturing Progress satırındaki başlatma düğmesine bastım ve muhasebedeki makineden sunucuya iki istek gönderdim. İki istek 20 paketi doldurdu, yakalama durdu ve indirme düğmesi açıldı:

İnen muhasebe.root.1.pcap dosyasını Wireshark’ın komut satırı aracı tshark ile açtım:

    1 2026-10-02 01:06:06,109408  10.34.70.10 → 198.18.0.1   TCP 74 44160 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=1044564020 TSecr=0 WS=128
    2 2026-10-02 01:06:06,109989   198.18.0.1 → 10.34.70.10  TCP 74 80 → 44160 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=1903138291 TSecr=1044564020 WS=128
    3 2026-10-02 01:06:06,110212  10.34.70.10 → 198.18.0.1   TCP 66 44160 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=1044564021 TSecr=1903138291
    4 2026-10-02 01:06:06,110296  10.34.70.10 → 198.18.0.1   HTTP 139 GET / HTTP/1.1 
...
    7 2026-10-02 01:06:06,112155   198.18.0.1 → 10.34.70.10  HTTP 86 HTTP/1.0 200 OK  (text/html)

Dosya iki şeyi açıkça gösteriyor:

1. Yalnız iç taraf var. Bütün paketlerde istemcinin kendi adresi 10.34.70.10 duruyor. Yakalama tek arayüzü dinlediği için paketin NAT’tan sonra port3’ten hangi adresle çıktığı dosyada yok.
2. İçerik de var. 7 numaralı paketin gövdesinde sunucunun sayfasının metni (dis-ag web sunucusu) duruyordu. Arayüzden alınan yakalama, kullanıcıların trafiğinin içeriğini taşıyan bir dosyadır; iş bitince filtreyle birlikte cihazdan da bilgisayardan da silinir.

Fortinet’in sayfası paket yakalama için cihazın bir diski olması gerektiğini yazıyor; diski olmayan bir modelde bu ekranı kullanmadan önce kendi cihazınızda doğrulayın. Formun karşılığı config firewall sniffer altında duruyor:

config firewall sniffer
    edit 1
        set interface "muhasebe"
        set host "198.18.0.1"
        set port "80"
        set protocol "6"
        set max-packet-count 20
    next
end

Komut Satırından: diagnose sniffer packet

Aynı bağlantıyı komut satırından diagnose sniffer packet any 'host 198.18.0.1 and tcp port 80' 4 6 l ile izledim. Komutun parçaları:

1. any: bütün arayüzleri aynı anda dinle. Arayüzdeki yakalamanın yapamadığı şey budur.
2. Tırnak içindeki filtre: hangi paketlerin gösterileceği, tcpdump’la aynı sözdizimiyle.
3. 4: ayrıntı düzeyi. Fortinet’in sayfasına göre 4, paket başlığını arayüz adıyla yazar; teşhiste işe yarayan düzey budur.
4. 6: altı paketten sonra dur. Sayı verilmezse yakalama siz durdurana kadar sürer.
5. l: zaman damgasını yerel saatle yaz.

Muhasebedeki makineden bağlantıyı açtım, sayfa 200 ile geldi:

2026-10-02 00:56:18.759958 muhasebe in 10.34.70.10.36582 -> 198.18.0.1.80: syn 3449905119 
2026-10-02 00:56:18.760027 port3 out 203.0.113.1.36582 -> 198.18.0.1.80: syn 3449905119 
2026-10-02 00:56:18.760352 port3 in 198.18.0.1.80 -> 203.0.113.1.36582: syn 1924297162 ack 3449905120 
2026-10-02 00:56:18.760377 muhasebe out 198.18.0.1.80 -> 10.34.70.10.36582: syn 1924297162 ack 3449905120 
2026-10-02 00:56:18.760379 port2 out 198.18.0.1.80 -> 10.34.70.10.36582: syn 1924297162 ack 3449905120 
2026-10-02 00:56:18.760717 muhasebe in 10.34.70.10.36582 -> 198.18.0.1.80: ack 1924297163 

Satırlar sırayla şunu söylüyor:

1. İstek muhasebe’den girdi ve port3’ten çıktı. Çıkarken kaynak adres 10.34.70.10’dan 203.0.113.1’e döndü; bu, FortiGate Firewall NAT ayarı yazımızda anlattığımız çeviri.
2. Cevap port3’ten girdi ve makineye geri döndü.
3. Cevap iki kez görünüyor, çünkü muhasebe bir VLAN arayüzü ve fiziksel olarak port2’nin üstünde duruyor; any aynı paketi ikisinde de yakalıyor.

Komut satırı sniffer’ı bu düzeyde paketin içeriğini yazmıyor ve çıktıyı yalnız ekrana veriyor. Fortinet bu yüzden çıktının SSH istemcisinde bir dosyaya kaydedilmesini öneriyor.

Sniffer’da İstek Çıkıyor, Cevap Gelmiyor

İstek çıkıyor ama bağlantı kurulmuyorsa sniffer iki farklı tablo gösterir. Önce sunucunun dinlemediği bir porta, 443’e bağlandım. Makine Couldn't connect to server dedi:

2026-10-02 00:56:30.773538 muhasebe in 10.34.70.10.51692 -> 198.18.0.1.443: syn 1852993447 
2026-10-02 00:56:30.773633 port3 out 203.0.113.1.51692 -> 198.18.0.1.443: syn 1852993447 
2026-10-02 00:56:30.773939 port3 in 198.18.0.1.443 -> 203.0.113.1.51692: rst 0 ack 1852993448 
2026-10-02 00:56:30.773961 muhasebe out 198.18.0.1.443 -> 10.34.70.10.51692: rst 0 ack 1852993448 

İstek çıktı, sunucu rst ile cevap verdi ve FortiGate cevabı makineye taşıdı. Sunucu ayakta, yalnız o portta dinleyen bir şey yok.

Sonra sunucunun kendi güvenlik duvarına 80’e gelen paketleri sessizce düşüren bir kural ekledim (iptables -I INPUT -d 198.18.0.1 -p tcp --dport 80 -j DROP) ve yeniden bağlandım. Makine 8 saniye sonra Connection timed out dedi:

2026-10-02 00:56:43.380175 muhasebe in 10.34.70.10.58936 -> 198.18.0.1.80: syn 663123792 
2026-10-02 00:56:43.380232 port3 out 203.0.113.1.58936 -> 198.18.0.1.80: syn 663123792 
2026-10-02 00:56:44.388661 muhasebe in 10.34.70.10.58936 -> 198.18.0.1.80: syn 663123792 
2026-10-02 00:56:44.388700 port3 out 203.0.113.1.58936 -> 198.18.0.1.80: syn 663123792 
2026-10-02 00:56:45.412536 muhasebe in 10.34.70.10.58936 -> 198.18.0.1.80: syn 663123792 
2026-10-02 00:56:45.412566 port3 out 203.0.113.1.58936 -> 198.18.0.1.80: syn 663123792 

Makine isteğini saniyede bir tekrarladı, FortiGate her birini port3’ten çıkardı, geri hiçbir şey gelmedi. İki durumda da FortiGate işini yaptı; sorun port3’ün ötesinde. Cevabın rst ile gelmesiyle hiç gelmemesi arasındaki fark port nedir yazımızda ayrıntılı ölçüldü.

FortiGate Oturum Tablosu: Bağlantı Ne Durumda?

Sniffer anlık bakar; oturum tablosu ise FortiGate’in o bağlantı için tuttuğu kaydı gösterir. Firewall nedir yazımızda anlattığımız durumlu firewall’un hafızası bu tablodur.

Arayüzden: FortiView Sessions

Menü yolu: Dashboard → FortiView Sessions. Fabrika ayarındaki sütunlar kaynak, hedef ve bayt gösteriyor; teşhis için başlığa sağ tıklayıp Select Columns listesinden Policy, Source NAT Address ve Expires sütunlarını ekledim. Muhasebedeki makine sunucudan büyük bir dosya indirirken tablo şöyleydi:

Bağlantıyı kural 5 açmış, kaynak 203.0.113.1’e çevrilmiş ve kaydın bir saatlik ömrü yeni başlamış. Aynı tabloya sessiz sunucu denemesi sürerken baktım:

Arayüzde cevabın gelmediğini söyleyen iki ipucu var: Bytes birkaç yüz baytta kalıyor ve Expires bir saat yerine saniyeleri gösteriyor. Bytes iki yönün toplamı olduğu için cevabın sıfır olduğunu tek başına söylemiyor; bunu komut satırı söylüyor.

Komut Satırından: diagnose sys session list

Sessiz sunucu denemesini komut satırından da izledim; tabloya dört komutla baktım:

1. diagnose sys session filter clear: önceki filtreyi temizle.
2. diagnose sys session filter dst 198.18.0.1: yalnız bu hedefe giden oturumlar.
3. diagnose sys session filter dport 80: yalnız bu porta gidenler.
4. diagnose sys session list: süzülen oturumları yaz.

session info: proto=6 proto_state=02 duration=2 expire=9 timeout=3600 flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
...
statistic(bytes/packets/allow_err): org=180/3/1 reply=0/0/0 tuples=2
...
hook=post dir=org act=snat 10.34.70.10:58936->198.18.0.1:80(203.0.113.1:58936)
...
misc=0 policy_id=5 pol_uuid_idx=14743 auth_info=0 chk_client_info=0 vd=0
...
total session 1

Teşhiste okunacak dört yer var:

1. policy_id=5: bağlantıyı açan kural. Beklediğiniz kural değilse sorun kural sırasındadır.
2. act=snat: çıkışta kaynağın çevrildiği adres.
3. reply=0/0/0: karşıdan gelen bayt ve paket sayısı. Makineden üç paket gitti (org=180/3/1), geri tek paket gelmedi.
4. proto_state=02: bağlantının TCP durumu; 02 isteğin gittiğini, cevabın gelmediğini söylüyor. expire=9 da kaydın dokuz saniye sonra silineceğini gösteriyor.

Karşılaştırmak için süren indirmenin kaydına baktım:

session info: proto=6 proto_state=01 duration=4 expire=3599 timeout=3600 flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
statistic(bytes/packets/allow_err): org=2386/43/1 reply=347625/249/1 tuples=2

Kurulmuş bağlantıda durum 01, cevap sayacı dolu ve kaydın ömrü bir saat. Bir kullanıcı “bağlanamıyorum” dediğinde tabloda reply=0/0/0 görmek tartışmayı kısaltır: FortiGate paketi geçirmiş, cevap karşıdan gelmiyor. Filtresiz list cihazdaki bütün oturumları döker; canlı bir cihazda filtre vermeden çalıştırılmaz.

FortiGate Debug Flow: Paket İçeride Neye Takıldı?

Sniffer paketin girip çıktığını, oturum tablosu bağlantının durumunu gösterir. Paket girip hiç çıkmıyorsa aradaki kararı diagnose debug flow yazar. Fortinet’in 7.0 kılavuzuna göre bu araç yalnız komut satırında var. Komutları FortiGate VLAN yazımızda satır satır açtık. Bu denemede verdiğim sıra:

1. diagnose debug reset: önceki ayarları temizle.
2. diagnose debug flow filter addr 198.18.0.1 ve diagnose debug flow filter port 80: izlenecek paketleri seç.
3. diagnose debug flow show function-name enable ve diagnose debug console timestamp enable: her satıra kararı veren işlevi ve saati ekle.
4. diagnose debug flow trace start 3: izlenecek paket sayısını ver.
5. diagnose debug enable: çıktıyı ekrana aç.
6. İş bitince diagnose debug disable ve diagnose debug reset.

trace start 3 sayesinde üç paketten sonra çıktı kendiliğinden durdu. Başarılı bağlantının ilk iki paketi:

2026-10-02 00:58:30 id=20085 trace_id=1 func=print_pkt_detail line=5845 msg="vd-root:0 received a packet(proto=6, 10.34.70.10:54078->198.18.0.1:80) tun_id=0.0.0.0 from muhasebe. flag [S], seq 452386580, ack 0, win 64240"
2026-10-02 00:58:30 id=20085 trace_id=1 func=init_ip_session_common line=6024 msg="allocate a new session-0000020c, tun_id=0.0.0.0"
2026-10-02 00:58:30 id=20085 trace_id=1 func=vf_ip_route_input_common line=2605 msg="find a route: flag=04000000 gw-203.0.113.80 via port3"
2026-10-02 00:58:30 id=20085 trace_id=1 func=get_new_addr line=1221 msg="find SNAT: IP-203.0.113.1(from IPPOOL), port-54078"
2026-10-02 00:58:30 id=20085 trace_id=1 func=fw_forward_handler line=881 msg="Allowed by Policy-5: SNAT"
2026-10-02 00:58:30 id=20085 trace_id=1 func=__ip_session_run_tuple line=3471 msg="SNAT 10.34.70.10->203.0.113.1:54078"
2026-10-02 00:58:30 id=20085 trace_id=2 func=print_pkt_detail line=5845 msg="vd-root:0 received a packet(proto=6, 198.18.0.1:80->203.0.113.1:54078) tun_id=0.0.0.0 from port3. flag [S.], seq 1742808845, ack 452386581, win 65160"
2026-10-02 00:58:30 id=20085 trace_id=2 func=resolve_ip_tuple_fast line=5931 msg="Find an existing session, id-0000020c, reply direction"
...

İlk paket, yukarıdaki sıranın duraklarından şöyle geçti:

1. Geldi: muhasebe arayüzünden.
2. Oturum açıldı: allocate a new session.
3. Rota bulundu: port3 üzerinden 203.0.113.80’e.
4. Kural verdi: Allowed by Policy-5.
5. Adres çevrildi: kaynak 203.0.113.1 oldu.

Cevap paketinde (trace_id=2) kural hiç aranmadı; FortiGate Find an existing session diyerek paketi oturum tablosundaki kayda bağladı. Kural yalnız bağlantının ilk paketinde aranıyor.

Kurala Takılan Paket: policy 0

Aynı sunucuya bu kez 8080’den bağlandım. Muhasebenin internet kuralı yalnız web ve ping’e izin veriyor; 8080’e uyan bir kural yok. Debug flow:

2026-10-02 00:58:56 id=20085 trace_id=4 func=print_pkt_detail line=5845 msg="vd-root:0 received a packet(proto=6, 10.34.70.10:32856->198.18.0.1:8080) tun_id=0.0.0.0 from muhasebe. flag [S], seq 4283112668, ack 0, win 64240"
2026-10-02 00:58:56 id=20085 trace_id=4 func=init_ip_session_common line=6024 msg="allocate a new session-00000219, tun_id=0.0.0.0"
2026-10-02 00:58:56 id=20085 trace_id=4 func=vf_ip_route_input_common line=2605 msg="find a route: flag=04000000 gw-203.0.113.80 via port3"
2026-10-02 00:58:56 id=20085 trace_id=4 func=fw_forward_handler line=719 msg="Denied by forward policy check (policy 0)"

Paket rotayı buldu ve dördüncü durakta, kuralda düştü. policy 0, hiçbir kurala uymayan paketi düşüren örtük ret. Bu reddin trafik logundaki karşılığı:

1: date=2026-10-02 time=00:58:59 ... type="traffic" subtype="forward" ... srcip=10.34.70.10 srcport=32856 srcintf="muhasebe" ... dstip=198.18.0.1 dstport=8080 dstintf="port3" ... action="deny" policyid=0 ... service="tcp/8080" ...

Makinenin dört denemesi logda dört satır bıraktı. Örtük reddin loglanması fabrika ayarında kapalıdır; açılışını log ayarları yazımızda anlattık, lab cihazında açık (fwpolicy-implicit-log enable).

FortiGate Logunda Görünmeyen Düşüş: Reverse Path Check

Sahneyi kurmak için muhasebedeki makineye misafir bölümünün bir adresini (10.34.60.50) ekledim. Bu, başka bir bölümden taşınıp adresi elle yazılmış bir cihazın durumu. Sonra bu adresten dışarıya üç ping attım; üçü de cevapsız kaldı. Sniffer pinglerin geldiğini, ama hiçbirinin çıkmadığını gösterdi:

2026-10-02 00:59:34.799915 muhasebe in 10.34.60.50 -> 198.18.0.1: icmp: echo request
2026-10-02 00:59:35.845176 muhasebe in 10.34.60.50 -> 198.18.0.1: icmp: echo request
2026-10-02 00:59:36.869207 muhasebe in 10.34.60.50 -> 198.18.0.1: icmp: echo request

Aynı denemeyi debug flow ile izledim. Her ping üçüncü durakta, kurala varmadan düştü:

2026-10-02 00:59:22 id=20085 trace_id=6 func=print_pkt_detail line=5845 msg="vd-root:0 received a packet(proto=1, 10.34.60.50:4538->198.18.0.1:2048) tun_id=0.0.0.0 from muhasebe. type=8, code=0, id=4538, seq=1."
2026-10-02 00:59:22 id=20085 trace_id=6 func=init_ip_session_common line=6024 msg="allocate a new session-00000229, tun_id=0.0.0.0"
2026-10-02 00:59:22 id=20085 trace_id=6 func=ip_route_input_slow line=2274 msg="reverse path check fail(by strict-src-check),drop"
2026-10-02 00:59:22 id=20085 trace_id=6 func=ip_session_handle_no_dst line=6110 msg="trace"

FortiGate kural aramadan önce bir soru soruyor: bu paketin kaynağına dönüş yolu, paketin geldiği arayüzden mi geçiyor? 10.34.60.0/24 ağının yolu misafir arayüzünden geçiyor, paket ise muhasebe’den geldi. Cevap hayır olunca paket düştü. Bu denetimin adı reverse path check; amacı sahte kaynak adresiyle gelen paketleri kapıda durdurmak.

Satırdaki (by strict-src-check), lab cihazında WAN ayarı yazımızda açtığımız strict RPF’ten (sıkı kip) geliyor. Cihaz fabrika ayarındaki feasible path (uygun yol) kipindeyken aynı deneme de düşmüştü ve satır yalnız reverse path check fail, drop idi. Feasible path, kaynağa giden herhangi bir rota paketin geldiği arayüzden geçiyorsa paketi kabul eder; 10.34.60.0/24’ün hiçbir rotası muhasebe’den geçmiyor.

Sonra trafik logunda bu adresi aradım (execute log filter category 0, execute log filter field srcip 10.34.60.50, execute log display):

0 logs found.
0 logs returned.
22.8% of logs has been searched.

Satırdaki yüzde, logun tamamının taranmadığını söylüyordu; komutu altı kez tekrarladım, oran 22.8%’de kaldı. Sıfırın gerçek olup olmadığını bilinen bir kayıtla sınadım: aynı filtreyle muhasebe makinesinin kendi adresini (10.34.70.10) aradım. Arama yine 22.8%’de durdu, 43 kayıt buldu ve en eskisi bir önceki günün 13:36’sındandı. Yani arama, pinglerin atıldığı 00:59’u fazlasıyla kapsıyordu; pingler logda gerçekten yok.

Örtük ret loglanan bir cihazda bile dönüş yolu denetimine takılan paket kurala hiç varmadığı için logda da yok. WAN yazısında internetten gelen sahte kaynaklı paket için aynı sessizliği ölçmüştük; içeriden gelen pakette de değişmiyor. Bu örnekte çözüm, cihazın adresini bulunduğu bölüme göre düzeltmekti; adres 10.34.70.x olunca aynı makinenin bağlantıları kural 5’ten geçti.

Log Aramasında Sıfır Sonuç: Önce Aramayı Sınayın

Komut satırındaki log araması, bulduğu kayıt sayısının altına taradığı oranı da yazıyor. Oran %100 değilse “0 logs found” yalnız taranan kısım için geçerli. Teşhis sırası şöyle:

1. Oranı okuyun: % of logs has been searched satırı %100 değilse sonuç eksik olabilir.
2. Bilinen bir kaydı arayın: aynı zaman aralığında mutlaka loglanmış bir trafiği, örneğin aynı makinenin başka bir bağlantısını, aynı filtreyle arayın.
3. Saatleri karşılaştırın: bilinen kaydın en eskisi aradığınız olaydan önceyse arama o saati kapsamıştır ve sıfır gerçektir.

Arayüzdeki log ekranı da aynı kayıtları gösteriyor ve sorun gidermede bir ipucu daha veriyor. Menü yolu: Log & Report → Forward Traffic:

Result sütunu gönderilen ve alınan baytı yan yana yazıyor. Sessiz sunucu denemesi 480 B / 0 B ile duruyor ve başında yeşil onay işareti var: kural bağlantıya izin verdi, ama karşıdan tek bayt gelmedi. Yeşil onayı “çalıştı” diye okumak yanıltır; ikinci sayı sıfırsa cevap hiç gelmemiştir.

İzinli Ama Logsuz Trafik

Logun sessizliği öbür yönde de yanıltıyor. Muhasebedeki makineden DMZ’deki web sunucusuna (10.34.80.10) üç istek gönderdim, üçü de 200 döndü. Debug flow bağlantının kural 6’dan geçtiğini gösterdi:

2026-10-02 01:00:45 id=20085 trace_id=8 func=fw_forward_handler line=881 msg="Allowed by Policy-6:"

Trafik logunda bu bağlantıların hiçbiri yoktu; aynı aramanın bulduğu dört kayıt önceki günün retleriydi. Kural 6’nın log ayarı fabrika ayarında kalmış (set logtraffic utm), yani yalnız güvenlik olaylarını yazıyor; farkı log ayarları yazımızda ölçtük. Logda satır olmaması ne trafiğin geçtiğini ne de durduğunu söylüyor; bunu yalnız paketin kendisi söylüyor.

Doğrulama: FortiGate Teşhisi Doğru Sırayla mı Yapıldı?

1. Normal günün kaydı var: get system performance status ve get system session status çıktıları tarihli bir dosyada.
2. Son değişiklik kontrol edildi: olay logunda arızanın başladığı saatten önceki Object attribute configured satırları okundu.
3. Paketin girişi ve çıkışı görüldü: sniffer’da in ve out satırları ya da arayüz yakalamasının pcap dosyası.
4. Karar okundu: paket çıkmıyorsa debug flow’un düştüğü satır.
5. Cevap sayıldı: oturum tablosunda reply= ya da logda Result’ın ikinci sayısı.
6. Log sıfırı sınandı: arama oranı okundu, bilinen bir kayıtla karşılaştırıldı.
7. İz temizlendi: debug kapatıldı (diagnose debug disable, diagnose debug reset), yakalama filtresi ve pcap dosyası silindi.

Sonuç: FortiGate’te Log Sustuğunda Paketin Kendisine Bakılır

FortiGate’te bir bağlantı çalışmadığında Fortinet’in sırası izlenir: normal günün kaydına ve son değişikliğe bakılır, sonra paketin izi sürülür. Sniffer paketin gelip çıktığını, debug flow içeride verilen kararı, oturum tablosu da cevabın gelip gelmediğini gösterir. Lab’da altı şey beklenenden farklı çıktı:

1. Dönüş yolu denetimine takılan pingler logda yoktu, oysa aynı cihaz kural reddini (policyid=0) logluyordu.
2. Cevap gelmeyen bağlantı logda yeşil onayla duruyordu; yalnız Result’taki 0 B cevabın gelmediğini söylüyordu.
3. Log araması “0 logs found” derken kayıtların %22,8’ini taramıştı; sıfırın gerçek olduğunu bilinen bir kayıtla sınamak gerekti.
4. Kural 6’nın izin verdiği DMZ trafiği logda hiç yoktu, çünkü kuralın log ayarı fabrika ayarında kalmıştı.
5. Arayüzdeki yakalama sayfanın içeriğini de kaydetti, ama tek arayüzü dinlediği için NAT’tan sonraki adresi göstermedi.
6. Debug çıktısı yalnız açan oturumda göründü; aynı anda açık ikinci SSH oturumuna tek satır düşmedi.

Örnekteki sınır kapısında tutanağın boş sayfası, kontrol taşında durdurulan tırı anlatmaz. O tır, yani dönüş yolu denetimine takılan paket, ancak kameranın giriş kaydında ve telsiz kaydında bulunur. Sıradaki adım rehberin 18. adımı, sıkılaştırma; açılış listesinin kalanı 20 adımlık kontrol listesinde duruyor.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn