FortiGate Firewall NTP Ayarı: Saat Dilimi ve Zaman Sunucusu

FortiGate Firewall NTP ayarı, cihazın saatini kurumun zaman sunucularına bağlar ve saat dilimini seçer. NSA’nın ağ cihazları için yayımladığı rehbere göre her cihaz saatini en az iki güvenilir iç sunucudan alır ve sunucunun cevabını bir anahtarla doğrular. Ayar System → Settings ekranının System Time bölümünde başlar; ikinci sunucu ve anahtar CLI’dan verilir. Bu yazı FortiGate Firewall yapılandırma rehberimizin 4. adımıdır. Lab cihazımda iki sunucuyu, anahtarlı doğrulamayı, 3 saatlik bir saat düzeltmesini ve sunucuların susmasını ölçtüm.

Örnekteki sınır kapısında kulübenin duvar saati kendi başına bırakılmaz; ana binadaki saat kulesine bir hatla bağlanır. Hat kopabileceği için kulübe ikinci bir binanın saatine de bağlıdır. Kapıdan geçen her aracın tutanağına o saat yazılır ve bütün kulübeler aynı saati yazdığı için tutanaklar yan yana konduğunda sıra tutar. FortiGate’te hat NTP’dir, saat kulesi kurumun NTP sunucusudur, tutanak da log satırıdır.

Bu yazı, Kurumsal Network Kurulumu hizmetimizde devraldığımız her FortiGate’te loglara bakmadan önce sorduğumuz soruyu anlatır: cihazın saati kime bakıyor?

FortiGate’in Saati Nereden Gelir? Fabrika Ayarında Eşitleme Kapalı

Fabrika ayarında FortiGate saatini kendi iç saatinden alır ve kimseye sormaz. NTP ayarı yapılandırmada yazılıdır, ama eşitleme kapalıdır. Lab cihazımın fabrika yapılandırması şuydu:

config system ntp
    set ntpsync disable
    set type fortiguard
    set syncinterval 60
    set source-ip 0.0.0.0
    set source-ip6 ::
    set server-mode enable
    set authentication disable
    set interface "fortilink"
end

Bu bloğun üç satırı yazının geri kalanını belirler:

1. ntpsync disable: eşitleme kapalı. Sunucu türü yazılı olsa da cihaz hiçbir sunucuya saat sormuyor.
2. type fortiguard: sunucu olarak Fortinet’in kendi sunucuları seçili. Bu sunucular adla yazıldığı için cihazın DNS ile ad çözebilmesi ve internete çıkabilmesi gerekir.
3. server-mode enable ve interface "fortilink": cihaz fabrikadan kendisi de bir NTP sunucusu ve fortilink arayüzünü dinliyor. Buna aşağıda ayrı bir bölümde döneceğiz.

Durumu diagnose sys ntp status komutu söyler. Lab cihazımda cevap buydu:

synchronized: no, ntpsync: disabled, server-mode: enabled
ipv4 server(ntp2.fortiguard.com) unresolved -- unreachable(0xff) S:0 T:0 
	 no data
ipv4 server(ntp1.fortiguard.com) unresolved -- unreachable(0xff) S:0 T:0 
	 no data

unresolved, cihazın sunucu adlarını IP adresine çeviremediğini söylüyor. Lab cihazımın internete çıkışı yok; fabrika DNS sunucularına (96.45.45.45, 96.45.46.46) ulaşamadığı için adlar çözülmedi. FortiGate’e iç DNS sunucusu yazmayı DNS ayarı yazımızda anlattık.

Eşitleme kapalıyken saat, iç saatin gösterdiği yerde kalır. Lab cihazım bir sanal makine: VMware sanal donanım saatini bilgisayarın yerel saatiyle başlatıyor, FortiOS ise onu UTC sayıyor. Sonuçta cihaz ilk açılışta gerçek saatten 3 saat ileride çalıştı ve o saatle yazılan her log satırı 3 saat ileriyi gösterdi. Fiziksel bir cihazda kaymanın sebebi başka olabilir; eşitleme kapalı kaldıkça saati düzelten bir şey yoktur.

Örnekteki sınır kapısında bu, hattı bağlanmamış bir duvar saatidir: işler, ama doğru saati gösterip göstermediğini kimse bilmez.

FortiGate’in Saati Nasıl Olmalı?

FortiGate saatini kurumun içindeki en az iki NTP sunucusundan alır; o sunucular da saatini dışarıdaki güvenilir kaynaklardan. Sunucunun cevabı, sunucu destekliyorsa paylaşılan bir anahtarla doğrulanır. Kurumda başka bir saat sunucusu varsa FortiGate saat dağıtmaz, yalnız alır.

Bu düzeni dört kaynak birlikte tarif ediyor:

1. NSA, Network Infrastructure Security Guidance rehberinde (Mart 2022, sürüm 1.0) her cihazın en az iki güvenilir saat kaynağıyla eşitlenmesini istiyor. Birincil kaynak kurumun iç sunucularıdır, onlar da saatini dışarıdaki yetkili kaynaklardan alır. NTP doğrulaması bütün cihazlarda açılır, her cihaz ile kaynağı arasında güçlü ve benzersiz bir anahtar kullanılır; ayardan sonra eşitlemenin gerçekten olduğu kontrol edilir (bölüm 6.4).
2. NIST, SP 800-53 kontrol kataloğunda sistem saatlerinin eşitlenmesini ayrı bir kontrol olarak yazıyor (SC-45) ve birinciden farklı bir coğrafi bölgede ikincil bir yetkili kaynak tanımlanmasını öneriyor (SC-45(2)). Log zaman damgası ya UTC’dir ya da UTC’ye göre farkını taşır (AU-8).
3. RFC 8633, NTP’nin en iyi uygulama belgesi (Temmuz 2019), sayının nedenini açıklıyor: tek kaynağın hatası olduğu gibi istemciye geçer, iki kaynak birbirini tutmazsa hangisinin doğru olduğu protokolün içinden bilinemez; doğru saati önemseyen kurum en az dört bağımsız kaynak kullanır (bölüm 3.2). Anahtar her bağlantıya ayrı olur ve MD5 artık zayıf sayılır (bölüm 4.1). Yalnız saat alan bir cihaz, tanıdığı sunucuların cevapları dışındaki NTP paketlerini düşürür (bölüm 5.1).
4. Fortinet ve Microsoft iki ürünün sınırını yazıyor. FortiOS 7.0, NTPv4 için SHA-1 doğrulaması yapar, ama yalnız saat alırken; saat dağıtırken yapmaz (yönetim kılavuzu). Windows’un saat servisi doğrulamayı yalnız domain üyesi bilgisayarlarla, Kerberos oturum anahtarıyla yapar; elle tanımlanan kaynaklarla giden paketler doğrulanmaz (Microsoft).

Lab cihazımın fabrika ayarlarını bu önerilerle yan yana koydum:

Tablonun ikinci satırı FortiGuard’ın neden ilk seçim olmadığını da söylüyor: FortiGuard sunucuları adla yazılı, cihazın internete çıkmasını ister ve firewall’u kurumdaki öbür cihazlardan ayrı bir saat kaynağına bağlar. Lab’daki iç sunucular ntp01 (192.168.1.15, chrony çalışan bir Ubuntu) ve dc01.ad.sistemkusu.com (domain controller). NTP’nin saati nasıl zincir halinde dağıttığını NTP nedir yazımızda, Linux’ta bir NTP sunucusunun nasıl kurulduğunu NTP sunucusu kurulum rehberimizde anlattık.

FortiGate’e Kaç NTP Sunucusu Yazılmalı?

Duvarda tek saat varsa o ne gösterirse saat odur; saat geri kalmışsa bunu fark eden olmaz. İki saat farklı gösterirse birinin yanlış olduğunu anlarsınız, ama hangisi olduğunu bilemezsiniz. Üç saatten ikisi aynı saati gösteriyorsa yanlış olanı bulursunuz; dördüncü saat, biri bozulduğunda bu çoğunluğu korur. RFC 8633’ün dört kaynak demesi bundandır.

NTP’de bu saatler zincir halinde durur:

1. Basamak 1, ulusal saat: atom saatine doğrudan bağlı sunucu. Lab’da TÜBİTAK UME’nin sunucusu.
2. Basamak 2, saat kulesi: kurumun iç NTP sunucusu, saatini birinci basamaktan alır. Lab’da ntp01 ve dc01.
3. Basamak 3, kulübenin duvar saati: FortiGate, saatini iç sunuculardan alır.

Basamağa NTP’de stratum denir ve saat zincirde her halkada bir basamak aşağı iner. Örnekteki sınır kapısında kulübe iki binanın saatine bağlıdır. Binalardan biri susarsa kulübe öbürüne bakmaya devam eder; ikisi farklı saat gösterirse kulübe hangisinin doğru olduğunu kendi başına çözemez. Çoğunluk oyu, binalar kendi saatlerini kurarken verilir.

Bu yüzden iki sayıyı farklı halkalarda uyguluyoruz:

1. FortiGate’e iki iç sunucu. Biri susunca öbürü devralır; aşağıda ölçtüm.
2. Her iç sunucuya en az dört dış kaynak. Doğruluğun oyu orada verilir. ntp01’in kaynak listesi (chronyc sources):

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 194.27.222.5                  1   8   377   246  +4188us[+4378us] +/- 9572us
^+ 162.159.200.123               3   8   377   247  -4048us[-3859us] +/-   23ms
^+ 162.159.200.1                 3   8   377   248  -3668us[-3479us] +/-   23ms
^+ 93.115.79.15                  3   9   377   116  -3638us[-3638us] +/-   20ms

^* işaretli satır seçilen kaynaktır: TÜBİTAK UME, stratum 1. ^+ işaretli üç kaynak Türkiye havuzundan geliyor ve seçilen kaynağı doğruluyor.

Diyagramdaki iki hattın biri anahtarlı, öbürü anahtarsız. Lab’daki ikinci sunucu bir Windows domain controller ve Windows’un saat servisi FortiGate’le anahtar paylaşamıyor; bunun bedelini aşağıda ölçtüm. İki iç sunucunun ikisi de anahtar destekliyorsa düzen daha sağlamdır.

FortiGate’te Saat Dilimi ve NTP Sunucusu Ayarı

Ayardan önce üç şey hazır olur:

1. İç NTP sunucuları: lab’da ntp01 (192.168.1.15) ve dc01.ad.sistemkusu.com. Sunucular sunucu ağında, FortiGate’in yönetim portu yönetim ağında; FortiGate’ten sunucu ağına bir statik rota gidiyor. Arada bir firewall kuralı olsaydı, açılacak yol hedef portu UDP 123 olan trafik olurdu.
2. Ad yazılacaksa iç DNS: dc01 adla yazıldığı için FortiGate’in adı iç DNS’e sorması gerekir. İç DNS rehberin 5. adımında kurulur; adla yazılan sunucu o adımdan sonra çalışır, adresle yazılan ntp01 beklemez.
3. Sunucuda izin ve anahtar: chrony’ye FortiGate’in ağına saat vermesi söylenir (allow 192.168.10.0/24) ve FortiGate’le paylaşılacak anahtar anahtar dosyasına yazılır.

ntp01’de anahtarı şu iki komutla ekledim:

echo '1 SHA1 ASCII:<anahtar>' | sudo tee -a /etc/chrony/chrony.keys
sudo chronyc rekey

Satırın parçaları:

1. 1: anahtarın numarası. FortiGate’te key-id olarak yazılır.
2. SHA1: algoritma. FortiOS 7.0, NTPv4 için SHA-1 kullanıyor.
3. ASCII:<anahtar>: anahtarın düz metin yazıldığını söyler. FortiGate anahtarı metin olarak aldığı için iki taraf aynı diziyi görür. Lab’da parola yöneticisinin ürettiği 32 karakterlik rastgele bir dizi kullandım; dizi yalnız bu iki cihazda duruyor.

chronyc rekey, chrony’nin anahtar dosyasını yeniden okumasını sağlar.

Sunucular hazır olunca ayar System → Settings ekranının System Time bölümünde başlar:

1. Time zone: (GMT+3:00) Istanbul.
2. Set Time: NTP. Yanındaki Manual settings saati elle kurar ve elle kurulan saat zamanla kayar.
3. Select server: FortiGuard ya da Custom.
4. Sync interval: cihazın sunucuya kaç dakikada bir soracağını belirler. Fabrika değeri 60, aralık 1 ile 1440 dakika arası.

FortiOS 7.0.10’da 3. adımda bir engel var: Custom seçeneği gri gelir ve tıklanmaz. Yanındaki bilgi simgesinin üstüne gelince nedeni yazıyor:

Sunucular bu yüzden CLI’dan yazılır. Arayüzün sağ üstündeki CLI simgesinden ya da SSH’tan şu satırlar girilir:

config system ntp
    set ntpsync enable
    set type custom
    config ntpserver
        edit 1
            set server "192.168.1.15"
            set authentication enable
            set key <ntp01 ile paylaşılan anahtar>
            set key-id 1
        next
        edit 2
            set server "dc01.ad.sistemkusu.com"
        next
    end
    set server-mode disable
end

Satırların işi sırasıyla:

1. ntpsync enable: eşitlemeyi açar.
2. type custom: saat kaynağını kurumun sunucularına çevirir.
3. edit 1 ve edit 2: iki iç sunucu. İkincisi adla yazıldı; FortiGate adı iç DNS’ten çözüyor.
4. authentication, key, key-id: 1 numaralı sunucuyla paylaşılan anahtar ve numarası. Anahtar ve numara sunucudakiyle birebir aynıdır.
5. server-mode disable: FortiGate’in kendisinin saat dağıtmasını kapatır. Neden kapattığımı aşağıda ayrı bir bölümde ölçtüm.

Kaydettikten sonra cihazın kendi show system ntp çıktısı anahtarı şifreli saklıyor:

config system ntp
    set ntpsync enable
    set type custom
    config ntpserver
        edit 1
            set server "192.168.1.15"
            set authentication enable
            set key ENC ...
            set key-id 1
        next
        edit 2
            set server "dc01.ad.sistemkusu.com"
        next
    end
end

Arayüz artık Custom’ı seçili gösteriyor, ama yalnız ilk sunucuyu:

İkinci sunucu ekranda hiç yok. Arayüzden yapılan bir değişikliğin onu silip silmediğini denedim: önce Sync interval’ı, sonra sunucu alanını arayüzden değiştirip kaydettim. İki seferde de yalnız 1 numaralı kayıt değişti; ikinci sunucu ve anahtar yerinde kaldı. Yine de sunucu listesine CLI’dan bakılır, çünkü arayüze bakan biri cihazın tek bir sunucuya bağlı olduğunu sanır.

FortiGate NTP Ayarını Doğrulamak: diagnose sys ntp status

Ayardan sonra ilk bakılacak yer yine diagnose sys ntp status komutudur. Lab cihazımda iki sunucuyla cevap buydu:

synchronized: yes, ntpsync: enabled, server-mode: disabled
ipv4 server(192.168.1.15) 192.168.1.15 -- reachable(0xff) S:1 T:711 selected 
	server-version=4, stratum=2
	reference time is ee6884c3.1d2ad40b -- UTC Thu Oct  1 07:05:39 2026
	clock offset is -0.007237 sec, root delay is 0.016495 sec
	root dispersion is 0.001785 sec, peer dispersion is 3 msec
ipv6 server(dc01.ad.sistemkusu.com) unresolved -- unreachable(0xff) S:0 T:1 
	 no data
ipv4 server(dc01.ad.sistemkusu.com) 192.168.1.10 -- reachable(0xff) S:1 T:711 
	server-version=3, stratum=2
	...

Çıktıda altı şey okunur:

1. synchronized: yes: cihaz saatini artık bu sunuculara göre tutuyor.
2. reachable(0xff): sunucunun son sekiz soruya verdiği cevaplar. Her bit bir sorudur; 0xff sekizinin de cevap aldığını söyler. Sunucu susunca bu değer bit bit düşer, aşağıdaki ölçümde görünüyor.
3. selected: saatin alındığı sunucu. Lab’da ntp01.
4. stratum=2: iki sunucu da saat zincirinin 2. basamağında; FortiGate 3. basamakta durur. dc01 sürüm 3 ile cevap veriyor (server-version=3), çünkü Windows’un saat servisi NTP’nin 3. sürümünü konuşuyor.
5. T:711: lab’da bu sayı her saniye bir azaldı; bir sonraki soruya kalan süreyi gösteriyor. 60 dakikalık aralıkta cihaz sunucuya on dakikadan uzun aralıklarla soruyor.
6. ipv6 server(...) unresolved: adla yazılan sunucu için FortiGate bir de IPv6 adresi arıyor. dc01’in IPv6 kaydı olmadığı için bu satır unresolved kalıyor; IPv4 satırı çalıştığı sürece zararsızdır.

Sunucu tarafında chrony’nin istemci listesi (chronyc clients) FortiGate’i yönetim ağındaki adresiyle gösteriyor. 70 istek, susma ölçümü için aralığı 1 dakikaya indirdiğim süreden kaldı:

Hostname                      NTP   Drop Int IntL Last     Cmd   Drop Int  Last
===============================================================================
192.168.10.1                   70      0   4   -    24       0      0   -     -
...

NTP Cevabını Anahtarla Doğrulamak

Anahtarsız NTP’de cevabın gerçekten o sunucudan gelip gelmediğine kimse bakmaz. Aradaki biri paketi değiştirebilir ya da sahte bir saat gönderebilir (RFC 8633 bölüm 4). Anahtarlı doğrulamada iki tarafın elinde aynı anahtar vardır ve iş üç adımda yürür:

1. FortiGate soruyu gönderirken sorunun içeriğini anahtarla birlikte SHA-1’den geçirir ve çıkan hash’i sorunun sonuna ekler.
2. Sunucu aynı hesabı kendi anahtarıyla yapar. Özet tutarsa cevap verir ve cevabına kendi özetini ekler; tutmazsa hiç cevap vermez.
3. FortiGate cevabın özetini kontrol eder ve tutmayan cevabı kullanmaz.

Örnekteki sınır kapısında bu, iki binanın elindeki aynı damgadır. Ana bina her saat bildirimini o damgayla basar, kulübe gelen damgayı kendi damgasıyla karşılaştırır. Damgası tutmayan bildirim, ne gösterirse göstersin, duvardaki saate yansımaz.

ntp01’de paketleri yakaladım (tcpdump -vv). FortiGate’in sorusu ve ntp01’in cevabı ikisi de anahtar numarasını ve özeti taşıyor:

07:24:47.107316 IP (tos 0x0, ttl 64, id 50458, offset 0, flags [none], proto UDP (17), length 100)
    192.168.10.1.123 > 192.168.1.15.123: NTPv4, Client, length 72
	...
	Key id: 1
	Authentication: 2b132f90ae35132f037d8fc60d30fe2eb9371ea6
07:24:47.107561 IP (tos 0x0, ttl 64, id 39858, offset 0, flags [DF], proto UDP (17), length 100)
    192.168.1.15.123 > 192.168.10.1.123: NTPv4, Server, length 72
	Leap indicator:  (0), Stratum 2 (secondary reference), poll 4 (16s), precision -25
	...
	Key id: 1
	Authentication: cb99c5c040f0aa3ae47eb829c65cdae5f8de2731

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

1. length 72: anahtarsız bir NTP paketi 48 bayttır; dc01’e giden paketler lab’da 48 bayttı. Fark 24 bayt: 4 baytlık anahtar numarası ve 20 baytlık SHA-1 hash’i.
2. Key id: 1: iki taraf da 1 numaralı anahtarı kullanıyor.
3. Authentication: paketin özeti. Soru ile cevabın özetleri farklıdır, çünkü her biri kendi paketinin içeriğinden hesaplanır.

Anahtar Yanlışsa Sunucu Susmuş Gibi Görünür

Anahtarı yanlış yazınca ne olduğunu da ölçtüm. FortiGate’teki anahtarı rastgele başka bir diziyle değiştirdim:

1. ntp01 FortiGate’in sorularını aldı ama hiçbirine cevap vermedi; paket kaydında yalnız FortiGate’in Key id: 1 taşıyan soruları var.
2. FortiGate bunu bir anahtar hatası olarak yazmadı. ntp01’in ulaşılabilirlik değeri 0xfc’ye düştü ve FortiGate saati anahtarsız dc01’den almaya başladı.

Yanlış anahtar, susmuş bir sunucuyla aynı görünür; durum çıktısında da olay kaydında da kimlik doğrulamadan söz edilmez. Bu belirtiyi görünce sırayla şunlara bakılır:

1. Sunucuya ping gidiyor mu? Gidiyorsa yol açıktır.
2. Sunucuda paket yakalamada FortiGate’in soruları görünüyor mu? Görünüyor ve cevap çıkmıyorsa sorun anahtardadır.
3. İki taraftaki anahtar aynı mı? FortiGate’teki key-id anahtar dosyasındaki satırın ilk sayısıyla, anahtarın kendisi de dosyadaki diziyle karşılaştırılır.

dc01’e de bir anahtar yazıp aynı denemeyi yaptım. Windows’un saat servisi anahtarlı soruya hiç cevap vermedi. Microsoft’un belgesi bunun nedenini söylüyor: servis paketleri yalnız domain üyesi bilgisayarların Kerberos oturum anahtarıyla doğruluyor ve FortiGate domain üyesi değil. dc01 bu yüzden anahtarsız kaldı.

Anahtarlı ntp01 susunca FortiGate’in anahtarsız dc01’e geçmesi bu düzenin bedelidir: anahtarlı hattı kesebilen biri FortiGate’i anahtarsız hatta düşürebilir. İki iç sunucunun ikisi de anahtar destekliyorsa bu açık kapanır.

Saat Düzelirken FortiGate Logu Ne Gösterir?

Lab cihazım ilk açılışta gerçek saatten 3 saat ileride çalışmıştı. Aynı durumu yeni ağda kurmak için NTP kapalıyken saati Manual settings ile 3 saat ileri aldım, cihaza birkaç kez SSH ile bağlandım ve NTP’yi yukarıdaki ayarla açtım. FortiGate 3 saati yavaş yavaş kapatmadı; ayarı kaydettikten 14 saniye sonra saati tek adımda geri aldı ve Log & Report → Events altındaki sistem olaylarına yazdı:

date=2026-10-01 time=12:47:25 eventtime=1790837243516939315 tz="+0300" logid="0100032141" type="event" subtype="system" level="notice" vd="root" logdesc="Global time setting changed by NTP" user="ntp_daemon" ui="NONE" field="date-time" msg="The ntp daemon step adjusted time from Thu Oct  1 12:47:26 2026 to Thu Oct  1 09:47:23 2026 (sync source: 192.168.1.15)"

Durum çıktısı adımın büyüklüğünü de gösterdi: clock offset is -10802.520508 sec, yani 3 saat 2,5 saniye. NTP’nin standardı RFC 5905, 1000 saniyeden büyük farkta NTP programının durup sistem loguna bir uyarı yazmasını öneriyor; RFC 8633 bölüm 5.2 bu kuralı aktarıyor. FortiGate bu sınırı uygulamadı ve 10.802 saniyelik farkı tek adımda kabul etti.

Kurulum günü bu işinizi kolaylaştırır. Çalışan bir cihazda ise yanlış bir saat kaynağı cihazın saatini saatlerce oynatabilir; anahtarlı doğrulamanın değeri burada ortaya çıkıyor.

Adımın bedeli log sırasında görünür. FortiGate olayları yeniden eskiye numaralayarak listeliyor. SSH oturumları adımın iki yanına düşmüştü:

25: date=2026-10-01 time=09:47:26 eventtime=1790837246201759879 tz="+0300" ... logdesc="Admin logout successful" ...
26: date=2026-10-01 time=09:47:26 eventtime=1790837246048658363 tz="+0300" ... logdesc="Admin login successful" ...
27: date=2026-10-01 time=12:47:25 eventtime=1790837243516939315 tz="+0300" ... logdesc="Global time setting changed by NTP" ...
28: date=2026-10-01 time=12:47:25 eventtime=1790848045211233022 tz="+0300" ... logdesc="Admin logout successful" ...
29: date=2026-10-01 time=12:47:25 eventtime=1790848045051422237 tz="+0300" ... logdesc="Admin login successful" ...

Bu beş satır üç şey söylüyor:

1. 28 ve 29 numaralı satırlar adımdan önce yazıldı, saatleri 12:47. Adımdan sonra yazılan 25 ve 26 ise 09:47. Logu saate göre sıralayan biri, önce olan oturumu üç saat sonra görür.
2. Aynı üç saat bu cihazda iki kez yaşanıyor. Saat yeniden 12:47’ye gelene kadar yazılan her satır, adımdan önce yazılmış satırlarla aynı saatleri paylaşacak.
3. Adım satırının kendisi iki saati birden taşıyor. 27 numaralı satırın time alanı adımdan önceki saati (12:47:25), eventtime alanı ise adımdan sonraki anı yazıyor: UTC 06:47:23, yani İstanbul saatiyle 09:47:23.

Rehberde saatin logdan önce gelmesinin sebebi budur. NTP’den önce yazılan satırlar yanlış saatte kalır ve düzeltme anında iki satır arasında zaman geriye akar. Örnekteki sınır kapısında hattı sonradan bağlanan kulübenin eski tutanakları eski saatle kalır; düzeltme o tutanakları geri almaz.

Saat Dilimi Log Satırına Nasıl Yazılır?

Yukarıdaki satırlarda iki alan saat dilimiyle ilgilidir. tz="+0300" cihazın saat dilimidir. eventtime ise 1970’ten beri geçen nanosaniye sayısıdır ve dilimden bağımsızdır: 26 numaralı satırdaki 1790837246048658363, UTC 06:47:26’ya, yani İstanbul saatiyle 09:47:26’ya karşılık gelir. NIST, log zaman damgasının ya UTC olmasını ya da UTC’ye göre farkını taşımasını istiyor (AU-8); FortiGate satıra ikisini birden yazıyor.

Log sunucusu satırı hangi dilimde okursa okusun, bu iki alan satırın yazıldığı anı verir. Adımdan önce yazılan 28 ve 29 numaralı satırlarda ise iki alan da yanlış saati taşıyor: dilim bilgisi saati doğru dilime çevirir, yanlış saati düzeltmez.

Switch NTP yazımızda switch log satırına yerel saatini dilim bilgisi olmadan yazdığı için log sunucusunda üç saat ileri damgalı kayıtlar görmüştük. FortiGate’in kendi logunda dilim bilgisi satırın içinde duruyor.

FortiGate Saatini Elle Geri Almak: Lisans Neden Kilitlendi?

NTP’nin attığı adımlar lab cihazımda zararsız geçti. Saat bir kez de elle, üç saat geri alındı ve sonucu başka bir yerde çıktı.

Cihaz 3 saat ileride çalışırken sanal FortiGate’in değerlendirme lisansı oluşturuldu ve lisansın başlangıç anı o ileri saatle damgalandı. Ekran görüntülerinden önce saati Manual settings ile gerçek saate çektiğimde cihazın saati lisansın başlangıç anının gerisine düştü. İki şey birden oldu:

1. Lisans durumu Expired oldu ve bitiş tarihi 1970 göründü.
2. Arayüz yalnız lisans yükleme sayfasını açtı.

Hiçbir şey yapmadım. Gerçek saat lisansın damgalandığı anı geçtiğinde lisans kendiliğinden Valid’e döndü ve bitiş tarihi değişmedi. O gün execute time ve execute date komutları da değer almamıştı; bunu kilide bağlamıştım, ama lisans geçerliyken de execute time değer almıyor. Bu cihazda saati elle kurmanın yolu arayüzdeki Manual settings.

Değerlendirme lisansı sanal FortiGate’e özgüdür, ama gösterdiği şey geneldir: saate bağlı her karar cihazın saatine güvenir. Lisansın başlangıç anı, sertifikaların geçerlilik aralığı ve zamanlanmış kurallar aynı saate bakar. Saati düzeltmenin güvenli anı, cihaz canlıya alınmadan, NTP’nin ilk gün açıldığı andır.

FortiGate’i Yerel NTP Sunucusu Yapmak

FortiGate saat almakla kalmaz, başkasına da verebilir. Setup device as local NTP server (cihazı yerel NTP sunucusu yap) seçeneği fabrika ayarında açık ve yalnız fortilink arayüzünü dinliyor. FortiLink, FortiGate’in yönettiği FortiSwitch’lere bağlandığı arayüzdür. Fabrika ayarında yönetim bilgisayarımdan (192.168.10.225) FortiGate’in yönetim adresine saat sordum:

w32tm /stripchart /computer:192.168.10.1 /samples:2 /dataonly

Tracking 192.168.10.1 [192.168.10.1:123].
Collecting 2 samples.
The current time is 1.10.2026 10:06:36.
10:06:36, error: 0x800705B4
10:06:39, error: 0x800705B4

0x800705B4 zaman aşımıdır: soru gitti, cevap gelmedi. Kurumda ayrı bir NTP sunucusu yoksa FortiGate iç ağa saat verebilir; switch’ler, kameralar ve bilgisayarlar saati ondan alır. Dinlenecek arayüz Listen on Interfaces alanındaki + ile seçilir ve seçim listesinde portlar takma adlarıyla görünür:

yonetim (port1)’i ekleyip aynı soruyu tekrarladım ve bu kez cevap geldi. Paketi FortiGate’in kendi yakalama komutuyla (diagnose sniffer packet) aldım, Wireshark’ın komut satırı aracı tshark ile çözdüm:

Network Time Protocol (NTP Version 1, server)
    Flags: 0x0c, Leap Indicator: no warning, Version number: NTP Version 1, Mode: server
    ...
    Peer Clock Stratum: secondary reference (3)
    ...
    Reference ID: 192.168.1.15
    ...
    Origin Timestamp: Oct  1, 2026 07:08:17.902388199 UTC
    Receive Timestamp: Oct  1, 2026 07:08:17.790488999 UTC
    Transmit Timestamp: Oct  1, 2026 07:08:17.790498999 UTC

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

1. Mode: server: FortiGate sunucu olarak cevap verdi. Sürüm 1 görünüyor, çünkü Windows’un w32tm aracı soruyu NTP’nin 1. sürümüyle sordu ve FortiGate aynı sürümle cevap verdi.
2. Stratum (3): FortiGate kendini saatini aldığı sunucunun bir basamak altında tanıtıyor.
3. Reference ID: 192.168.1.15: FortiGate saatini nereden aldığını da söylüyor: ntp01.
4. Zaman damgaları: Origin bilgisayarın soruyu gönderdiği andır, Receive FortiGate’in aldığı andır. Bilgisayarın saati FortiGate’ten 0,11 saniye ileride. Aynı bilgisayar dc01’e karşı da aynı yönde 0,08 saniye ölçtü; fark FortiGate’te değil, saat servisi kapalı olan yönetim bilgisayarımda.

Bu ölçümden sonra seçeneği kapattım, çünkü lab’da saat dağıtan bir sunucu zaten var. İki gerekçem var:

1. RFC 8633 yalnız saat alan bir cihazın gelen NTP sorularını düşürmesini öneriyor (bölüm 5.1). Soruya cevap veren cihaz, yukarıdaki Reference ID alanında olduğu gibi saatini nereden aldığını sorana söyler.
2. Fortinet’e göre SHA-1 doğrulaması yalnız FortiGate saat alırken var. FortiGate saat dağıtırken istemcileri onun cevabını doğrulayamaz.

config system ntp
    set server-mode disable
end

Kapattıktan sonra yönetim bilgisayarının sorusu yine zaman aşımına düştü. FortiGate’in saat dağıtması gerekiyorsa yalnız istemcilerin bulunduğu iç arayüzü dinler. İnternete bakan arayüzü (lab’da dis-ag) bu listeye eklemek, cihazı dışarıya açık bir saat sunucusu yapar.

NTP Sunucusu Susarsa FortiGate Ne Gösterir?

Sunucular susarsa FortiGate’in ne yaptığını ölçmek için önce ntp01’in FortiGate’e cevap vermesini kestim (chronyc deny 192.168.10.1), sonra dc01’e giden NTP’yi de durdurdum. 60 dakikalık aralıkta FortiGate on dakikadan uzun aralıklarla soru soruyor; susmayı dakikalar içinde görebilmek için aralığı geçici olarak 1 dakikaya indirdim. Sonuç:

1. İlk cevapsız sorularda ulaşılabilirlik değeri düştü. reachable(0xff) önce 0xfe, sonra 0xfc oldu; her cevapsız soru sağdan bir sıfır ekliyor.
2. 38 saniye sonra FortiGate saati dc01’den almaya başladı. selected ikinci sunucuya geçti ve synchronized: yes hiç değişmedi.
3. 174 saniye sonra değer 0x0 oldu ve olay kaydına ntp01’in ulaşılamaz olduğu yazıldı.
4. dc01 de susunca senkron 28 saniyede düştü: durum synchronized: no oldu.
5. İkisine yeniden izin verdiğimde senkron 12 saniyede geri geldi. Olay kaydına iki sunucu için ayrı ayrı reachable satırı düştü.

Birinci sunucu sustuktan sonraki durum:

synchronized: yes, ntpsync: enabled, server-mode: enabled
...
ipv4 server(dc01.ad.sistemkusu.com) 192.168.1.10 -- reachable(0xff) S:3 T:10 selected 
...
ipv4 server(192.168.1.15) 192.168.1.15 -- unreachable(0x0) S:1 T:18 
...

Olay kaydındaki satır:

date=2026-10-01 time=10:02:12 eventtime=1790838132183651983 tz="+0300" logid="0100032108" type="event" subtype="system" level="notice" vd="root" logdesc="NTP server status changes to unreachable" user="ntp_daemon" ui="NONE" field="date-time" msg="The IPv4 ntp server, 192.168.1.15(192.168.1.15), is determined unreachable at Thu Oct  1 10:02:12 2026"

Senkron kaybolunca saat durmaz. 30 Eylül’deki ilk ölçümümde tek sunuculu düzende, senkron kaybolduktan üç buçuk dakika sonra iki saat hâlâ aynı saniyeyi gösteriyordu; cihaz son bildiği hızla işletmeye devam ediyor.

Arayüz ise susan sunucuyu göstermiyor. Aynı ölçümde, olay satırından üç dakika sonra panodaki System Information kutusunda saatin üstüne gelince yalnız Time Source: Custom NTP server yazıyordu; bildirim listesinde sunucuyla ilgili bir uyarı yoktu.

Susan sunucuyu söyleyen iki yer CLI’daki durum komutu ve olay kaydıdır. Olay kaydını bir log sunucusuna gönderen kurumda bu satır bir uyarıya bağlanabilir; logu bir log sunucusuna göndermeyi log ayarları yazımızda anlattık. Deneyden sonra aralığı fabrika değeri olan 60 dakikaya geri aldım.

Doğrulama: FortiGate’in Saati Gerçekten Kaynağına Bağlı mı?

Ayar bittiğinde altı şey kontrol edilir; her biri yukarıda lab’da ölçüldü:

1. diagnose sys ntp status synchronized: yes diyor, her sunucu reachable(0xff) ve biri selected.
2. Sunucunun istemci listesinde FortiGate’in adresi görünüyor (chronyc clients).
3. Anahtarlı sunucuda paket yakalamada hem soru hem cevap Key id taşıyor.
4. Olay kaydında ilk günün Global time setting changed by NTP satırı ve adımın büyüklüğü okunuyor; büyük bir adım, NTP’den önce yazılmış satırların yanlış saatte kaldığını söyler.
5. Yerel NTP sunucusu kapalıysa yönetim bilgisayarının FortiGate’e sorduğu saat sorusu zaman aşımına düşüyor.
6. Bir sunucu kapatılınca selected öbürüne geçiyor ve synchronized: yes kalıyor. Bu denemenin yeri bakım penceresidir.

Sonuç: FortiGate’in Saati Elle Değil, İki Kaynaktan NTP ile Kurulur

FortiGate’in saati, fabrika ayarında kimseye sormayan bir iç saatle gelir. Doğru düzende saat kurumun içindeki iki NTP sunucusundan alınır, sunucunun cevabı destekleniyorsa anahtarla doğrulanır ve kurumda bir saat sunucusu varsa FortiGate saat dağıtmaz. Lab’da dört şey beklenenden farklı çıktı:

1. Arayüz yalnız ilk sunucuyu gösteriyor. İkinci sunucu ve anahtar yalnız CLI’da görünüyor.
2. Yanlış anahtar bir hata mesajı üretmiyor. Sunucu susmuş gibi görünüyor ve FortiGate uyarı vermeden anahtarsız sunucuya geçiyor.
3. FortiGate 3 saatlik farkı tek adımda kapattı. NTP standardının 1000 saniyelik sınırını uygulamıyor.
4. execute time değer almıyor. Saat yalnız arayüzden elle kurulabiliyor.

Örnekteki sınır kapısında kulübe iki binanın saatine bağlı ve hatlardan yalnız biri damgalı. Damgalı hat koparsa kulübe damgasız hatta bakar ve bunu kimseye söylemez; iki hattın ikisi de damgalıysa bu boşluk kalmaz. Hattı ilk gün bağlanan kulübenin tutanakları ilk satırdan itibaren aynı sırayı tutar. 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