Linux NTP Sunucusu Kurulumu: chrony ile İç Saat Kaynağı

NTP sunucusu kurulumu, kurum içine tek bir saat dağıtım noktası koyup bütün cihazları oradan beslemek demektir. Kurduğunuz şey yeni bir saat değildir: dışarıdaki ulusal saatin kurum içindeki dağıtım noktasıdır ve o nokta da dışarıdan beslenmeye devam eder. Bu rehber kurulumun kendisinden önce kararla başlar, çünkü gereksiz kurulan bir NTP sunucusu hiç kurulmamış olmasından daha risklidir.

Okulda zil sistemi vardı. Kırk sınıfın kırk ayrı duvar saati vardı ve hiçbiri diğeriyle aynı değildi; kimse de bunu tartışmazdı, çünkü dersin bittiğine duvar saatleri karar vermiyordu. Zil karar veriyordu. İdari kattaki tek bir panelden çalıyor, bütün sınıflara aynı anda ulaşıyordu. Panelin kendi saatini nereden aldığını ise okulda tek bir kişi biliyordu ve o kişi izne çıktığında kimse bilmiyordu.

Kurumsal ağda kuracağınız şey tam olarak o paneldir ve bu rehber boyunca aynı okula geri döneceğiz. Aşağıda önce iç sunucunun gerçekten gerekli olup olmadığını, sonra platform sorusunun cevabının marka değil tavan olduğunu göreceğiz. Ardından Ubuntu üzerinde chrony ile kurulumu ve kurulumun çalıştığının nasıl doğrulandığını ele alacağız. En sonda da çoğu rehberin hiç girmediği yere gireceğiz: kurduğunuz sunucu sessizce kapandığında bunu nasıl haber alacaksınız. Kararı çoktan vermiş ve doğrudan komutlara geçmek istiyorsanız chrony kurulum bölümüne atlayabilirsiniz.

NTP’nin ne olduğu, saatin neden kendi kendine kaydığı, stratum hiyerarşisinin nasıl kurulduğu ve saat ayrıştığında ortaya çıkan arızalar bu rehberin kapsamı dışında kalıyor; onları NTP ve saat senkronizasyonu rehberimizde ele alıyoruz. Burada tek bir soruya cevap veriyoruz: o sunucu nasıl kurulur, nasıl doğrulanır ve nasıl ayakta tutulur. Rehber BT sistem yönetimi hizmetimizin zaman katmanına aittir.

İç NTP Sunucusu Ne Zaman Gerekir, Ne Zaman Gereksiz?

İç NTP sunucusu her kurumda gerekmez. Az sayıda cihazı olan ve hepsi internete çıkabilen bir ofiste doğru karar hiçbir şey kurmamak, cihazları doğrudan time.ume.tubitak.gov.tr gibi bir dış kaynağa yönlendirmektir. Kurulum kararı cihaz sayısıyla değil, cihazların dışarıya ulaşıp ulaşamadığıyla verilir.

Üç derslikli bir köy okulunda zil tesisatı kurulmaz. Öğretmen elindeki çanı çalar, üç sınıf da duyar; kimse kablo çekmeyi düşünmez bile. Panel, çan sesinin artık her sınıfa yetişmediği büyüklükte anlam kazanır.

İç Sunucuyu Zorunlu Kılan Üç Durum

İç NTP sunucusu şu üç durumda gerçekten gerekir ve üçü de “cihaz dış kaynağa ulaşamıyor” cümlesinin farklı halleridir.

Cihazların bir kısmı alan adı çözemiyorsa. Eski kayıt cihazları, bazı switch’ler ve endüstriyel donanım NTP ayarına yalnızca IP adresi kabul eder. Havuz adresinin IP karşılığını cihaza yazmak kalıcı bir çözüm değildir, çünkü havuzdaki sunucular değişir ve havuzun kendi kullanım politikası IP sabitlemeyi yasaklar. Sabit bir iç IP adresi bu cihazların kabul edebileceği tek doğru cevaptır.

Cihazlar internete doğrudan çıkmıyorsa. Üretim ağı, kamera ağı, yönetim VLAN’ı ve DMZ arkasındaki segmentlerde 123 numaralı UDP portunu dışarıya açmak çoğu zaman istenmez. İç sunucu bu tercihi bozmadan saati içeri taşır: dışarıya yalnız o sunucu çıkar.

Onlarca cihazın tek tek dışarı çıkması istenmiyorsa. Bu bir zorunluluk değil, mimari tercihidir ve doğru olanıdır. Her cihazın ayrı ayrı ücretsiz bir kamu sunucusuna yüklenmesi hem gereksizdir hem de saat kaynağının kim olduğunu takip edilemez hale getirir.

Domain Varsa Muhtemelen Zaten Bir Sunucunuz Var

Active Directory kullanan bir kurumda büyük ihtimalle yeni bir sunucu kurmanız gerekmez, çünkü Windows Time servisi bir Domain Controller’da NTP sunucusu olarak çalışır. Bu, domain hiyerarşisinin işlemesi için zaten açıktır. Switch’lerinizi, access point’lerinizi ve kameralarınızı bir Domain Controller’ın IP adresine yönlendirmek çoğu kurumda yeterli ve en ucuz cevaptır.

Aynı şey ağın kenarındaki firewall için de geçerlidir. Kurumsal firewall’ların neredeyse tamamı hem NTP istemcisi hem NTP sunucusu olarak çalışabilir ve dışarı zaten o cihaz çıkar. Firewall kurulumu ve yönetimi rehberimizde ele aldığımız cihaz sınıfında bu, arayüzde tek bir sekmelik iştir.

Yani sorulacak ilk soru “kurmalı mıyım” değil, “zaten var mı” olmalı. Sıfırdan bir sunucu kurmak üç durumda anlamlı hale gelir: elinizde domain yoksa, Domain Controller’ınızın domain dışı yüzlerce cihazla konuşmasını istemiyorsanız, ya da bir sonraki bölümde göreceğimiz doğruluk tavanına takılıyorsanız.

Sunucu Nereye Kurulur: Sanal mı, Fiziksel mi?

NTP sunucusu için sanal sunucu fazlasıyla yeterlidir ve bu, kaynak tüketiminin düşük olmasından çok işin doğasıyla ilgilidir: sunucu saniyede birkaç küçük UDP paketi cevaplar. 1 vCPU ve 512 MB bellek yüzlerce istemciyi taşır.

Sanal sunucuda tek bir şart var ve atlandığında bütün kurulumu boşa çıkarır: hypervisor’ün konuk makineye saat basan entegrasyon servisi kapatılmalıdır. Aksi halde sunucunun saatini iki taraf birden ayarlar ve saat sürekli ileri geri oynar. Bu tuzağın ayrıntısı ve VMware ile Hyper-V tarafındaki karşılıkları NTP rehberimizin çifte senkronizasyon bölümünde duruyor; platform tercihinin diğer sonuçlarını ise hypervisor ve sanallaştırma makalemizde ele alıyoruz.

Fiziksel makine yalnızca tek bir senaryoda zorunludur: kendi Stratum 1 kaynağınızı kuruyorsanız. GPS alıcısının saniyede bir ürettiği darbe sinyali sanallaştırma katmanından geçmez. Bu senaryoyu rehberin sonunda ele alıyoruz.

Hangi Platform: NTP Sunucusu için chrony mı, Windows Time mı?

Linux mu Windows mu sorusunun cevabı tercih değil, ihtiyacınız olan doğruluk tavanıdır. İki platform aynı işi yapmaz ve aradaki fark bir alışkanlık meselesi değil, ölçülmüş bir sınırdır.

Zil paneli benzetmesi burada da işe yarıyor. İki panel de zili aynı anda bütün sınıflara ulaştırır; fark, panelin kendi saatini ne kadar hassas tutabildiğidir. Ders zili için bu farkın hiçbir önemi yoktur. Bir yarışın startını veriyorsanız vardır.

Windows Time’ın İki Sert Sınırı

Windows Time servisi NTP sunucusu olarak çalışır, ama iki yapısal tavana takılır ve ikisi de belgelidir.

Birincisi doğruluk tabanıdır. NTP projesinin kendi ölçümüne göre Windows Time sunucuları hassasiyetlerini -6 olarak bildirir ve tick’ler arasında interpolasyon yapmadıkları için mutlak doğrulukları ±116 milisaniyenin altına inemez. İkincisi stratum tavanıdır: Windows Time yalnızca Stratum 2 ve altı olarak hizmet verebilir, Stratum 1 olamaz.

İkisi birleşince ortaya şu çıkıyor: Microsoft’un yüksek doğruluk dokümanı desteklediği bütün hedefleri (1 saniye, 50 milisaniye, 1 milisaniye) “doğru ve kararlı bir Stratum 1 kök kaynak” şartına bağlıyor, oysa zincirin kendi tavanı o hedeflerin en gevşeğinin bile altında kalıyor. Kerberos’un beş dakikalık toleransı için bu fazlasıyla yeterlidir. Delil değeri ve denetim kanıtı için değildir.

chrony Nereye Kadar İner?

chrony, aynı işi belirgin biçimde daha aşağıda yapar ve rakamlar projenin kendi ölçümlerinden geliyor. İnternet üzerinden dış sunuculardan beslenen bir chrony istemcisinde sapma tipik olarak birkaç milisaniye seviyesindedir; projenin yayınladığı test verisinde saat zamanın çoğunda 2-3 milisaniye, en kötü anlarda 8 milisaniye sapmayla çalışıyor.

Asıl fark donanım referansı devreye girdiğinde ortaya çıkıyor. Seri porta bağlı bir GPS alıcısı ve saniyede bir darbe (PPS, Pulse Per Second) sinyaliyle beslenen bir chrony sunucusunda projenin ölçtüğü sapma yaklaşık 20 mikrosaniyedir. Windows Time’ın tabanıyla arasında dört kat büyüklük mertebesi var.

Karar: Çoğu Kurumda Windows Yeter

Tablodaki farkın pratik karşılığı sandığınızdan dardır ve bunu net söylemek gerekiyor: kurumların büyük çoğunluğunda Windows Time yeterlidir. Kerberos beş dakikayla, olay korelasyonu saniyeyle, 5651 kapsamındaki kayıtlar saniyeyle ilgilenir. Bu üçünün hiçbiri milisaniye sormaz.

chrony’ye üç durumda geçilir: kurumda domain yoksa, dağıtım noktasının Domain Controller olmasını istemiyorsanız, ya da gerçekten yüz milisaniyenin altına inmeniz gerekiyorsa. Bu rehberin geri kalanı Linux tarafını, yani chrony ile kurulumu anlatıyor.

Windows Tarafında Kısa Cevap

Windows’ta kurulacak bir rol yoktur, çünkü Windows Time servisi zaten bir NTP sunucusu sağlayıcısı taşır; iş onu açmaktır. Karar üç cümlede özetlenir.

Domain’iniz varsa muhtemelen hiçbir şey yapmanız gerekmez. Bir Domain Controller’da NTP sunucusu varsayılan olarak açıktır, çünkü domain hiyerarşisinin işlemesi buna bağlıdır. Ağdaki domain dışı cihazları bir DC’nin adresine yönlendirmek çoğu kurumda yeterli ve en ucuz cevaptır. Elle yapılandırılması gereken tek makine orman kök domain’indeki PDC Emulator’dür ve o adım, komutları ve grup ilkesiyle dağıtımı Active Directory kurulum rehberimizin promotion sonrası bölümünde ele alınıyor.

Domain yoksa üç kayıt defteri değeriyle açılır: TimeProviders\NtpServer altındaki Enabled değeri 1, Parameters altındaki Type değeri NTP, Config altındaki AnnounceFlags değeri 5. Sihirbaz yoktur, üçü de elle yazılır.

Ama CIS Benchmark bunu üye sunucularda kapalı ister. Gerekçesi teknolojiye değil rolün yayılmasına itirazdır: üye sunucular ve iş istasyonları normalde başkalarına saat kaynağı olmamalıdır, aksi halde hangi cihazın kimden beslendiği takip edilemez hale gelir. Doğru okuma şu: bu ayar bir sunucuda bilinçli olarak açılır, geri kalan hepsinde kapalı kalır.

Üç değerin ayrıntısı, Type alanı NT5DS kaldığında NtpServer adresinin neden tamamen yok sayıldığı ve AnnounceFlags için 5 yerine 10 gerektiren iki durum ayrı bir Windows rehberinin konusudur.

Ubuntu Üzerinde chrony ile NTP Sunucusu Kurulumu

Ubuntu üzerinde NTP sunucusu kurulumu tek paketle başlar ve dört adımda biter: paketi kurmak, yukarı kaynağı tanımlamak, aşağıya kimin erişebileceğini yazmak, güvenlik duvarında 123 numaralı UDP portunu açmak. Adımların üçü kolaydır; üçüncüsü atlandığında sunucu kurulu görünür ama kimseye cevap vermez ve sahada en sık yaşanan arıza da tam olarak budur.

Bu bölüm, kurulu ve ağdan erişilebilir bir Ubuntu sunucuyu varsayar. Sunucuyu henüz ayağa kaldırmadıysanız, kurulum medyasının başlatılmasından statik IP ve disk düzenine kadar bütün adımlar ekran görüntüleriyle Ubuntu Server kurulumu rehberinde anlatılıyor. Dağıtım seçimi, LTS destek takvimi ve sıkılaştırma gibi kurulum dışındaki katmanlar ise Ubuntu Server rehberimizde duruyor.

Kurulum: Bir Servisi Kurarken Diğerini Kaldırmak

Ubuntu ve Debian ailesinde paketin adı chrony ve kurulum tek satırdır:

sudo apt update
sudo apt install chrony

Burada arka planda dikkate değer bir şey olur. Ubuntu’da saat senkronizasyonunu varsayılan olarak systemd-timesyncd yapar ve bu iki paket aynı anda kurulu kalamaz: ikisi de time-daemon sanal paketini sağlar ve ikisi de onunla çakışır, dolayısıyla apt chrony’yi kurarken systemd-timesyncd’yi kaldırır.

Bunu kurulum çıktısında açıkça görürsünüz:

The following packages will be REMOVED:
  systemd-timesyncd
The following NEW packages will be installed:
  chrony tzdata-legacy

Bu davranış bir kazadan çok koruma. Aynı saati iki servisin birden ayarlaması, hypervisor ile konuk makinenin birbirinin düzeltmesini bozmasıyla aynı arızayı üretirdi. Paket yöneticisi bu tuzağı sizin yerinize kapatıyor. Yine de kurulumdan sonra Linux tarafında bir kez doğrulayın, çünkü elle systemd-timesyncd etkinleştirilmiş sistemlerde bu koruma delinebilir:

systemctl is-active chrony
systemctl is-enabled chrony
systemctl is-active systemd-timesyncd   # "inactive" görmeniz gerekir

chrony.conf: Panelin Yukarısı ve Aşağısı

chrony’nin bütün yapılandırması tek dosyadadır ve Ubuntu’da bu dosyanın yolu /etc/chrony/chrony.conf’tur. Bu ayrıntıyı özellikle vurguluyoruz: Türkçe kaynakların önemli bir kısmı CentOS üzerinden yazıldığı için /etc/chrony.conf yolunu verir ve o yol Ubuntu’da yoktur. Dosyayı bulamamanızın sebebi genellikle budur.

Dosyayı iki yarım olarak okuyun: yukarısı panelin saatini nereden aldığını, aşağısı zil hattının hangi sınıflara çekildiğini anlatır. Kurumsal bir iç sunucu için /etc/chrony/chrony.conf içine gereken asgari yapılandırma şudur:

# YUKARISI: sunucu saatini nereden alıyor
server time.ume.tubitak.gov.tr iburst
pool tr.pool.ntp.org iburst maxsources 3

# AŞAĞISI: sunucu kime saat dağıtıyor
allow 192.168.1.0/24
allow 192.168.20.0/24

# Yukarısı tamamen kesildiğinde ne yapsın
local stratum 10

driftfile /var/lib/chrony/chrony.drift
makestep 1.0 3
rtcsync

Satırların üçü karar taşıyor. server tek bir sunucuyu sabitler ve ulusal saat kaynağınız için doğru olan budur; pool ise bir havuzdan birden fazla sunucu çeker ve maxsources 3 ile kaç tanesini kullanacağını sınırlarsınız. İkisini birlikte yazmak bilinçli bir tercihtir: ulusal kaynağı öncelersiniz, havuz da onun sessizce yanlış cevap vermesine karşı çapraz kontrol sağlar. iburst ise yalnızca ilk senkronizasyonu hızlandırır, açılışta dakikalar yerine saniyeler içinde senkron olunur.

makestep 1.0 3 satırı da göründüğünden önemli: sunucu açıldıktan sonraki ilk üç güncellemede fark 1 saniyeyi aşarsa saati yavaşça kaydırmak yerine tek adımda düzeltir. Sonrasında bu davranış kapanır, yani üretimdeki bir sunucunun saati bir daha aniden zıplamaz.

allow Yazılmadan Sunucu Kimseye Cevap Vermez

chrony varsayılan olarak hiçbir istemciye saat dağıtmaz. Projenin kendi dokümantasyonu bunu açıkça söylüyor: erişime izin verilen istemci yoktur, yani chronyd saf bir NTP istemcisi olarak çalışır. Sunucu haline gelmesi için en az bir allow satırı gerekir.

Bu, kurulumun en sık yanlış anlaşılan yeridir. Paketi kurarsınız, servis çalışır, chronyc tracking sunucunun kendi saatinin senkron olduğunu gösterir, her şey yolunda görünür. İstemciler ise cevap alamaz.

Durumun ne kadar sessiz olduğunu tek komut gösterir. allow satırı yokken sunucu 123 numaralı portu hiç açmaz:

ss -lun | grep ':123'
# (cikti yok)

allow eklenip servis yeniden başlatıldıktan sonra aynı komut soketi gösterir:

UNCONN 0      0      0.0.0.0:123       0.0.0.0:*

Yani sorun “sunucu cevap vermiyor” değil, ortada dinleyen bir servis olmamasıdır. Dışarıdan bakan istemci bunu ayırt edemez; yalnızca zaman aşımı alır.

Zil paneli kurulmuş, elektriği gelmiş, panelin kendi saati doğru. Sınıflara hat çekilmemiş. Panelin önünde durup bakan kişi hiçbir sorun göremez.

allow satırını yazarken kapsamı olabildiğince dar tutun. Bütün ağa açmak yerine besleyeceğiniz alt ağları tek tek yazmak, hem gereksiz bir hizmeti dışarıya sunmanızı engeller hem de ileride “bu sunucudan kimler besleniyor” sorusunun cevabını yapılandırma dosyasında tutar:

allow 192.168.1.0/24      # ofis
allow 192.168.20.0/24     # kamera ağı

Güvenlik Duvarında UDP 123

NTP 123 numaralı UDP portunu kullanır ve bu port sunucuya gelen yönde açık olmalıdır. Ubuntu’da ufw kullanıyorsanız tek satır yeter:

sudo ufw allow 123/udp
sudo ufw status

Portun TCP değil UDP olması pratikte kritik bir sonuç doğurur: erişimi TCP tabanlı araçlarla test edemezsiniz. Test-NetConnection ntp01 -Port 123 ya da telnet denemesi, port açıkken ve sunucu sağlıklı çalışırken bile başarısız döner. Bu, boş yere firewall kuralı açtıran klasik yanlış teşhistir. Doğru araçları bir sonraki doğrulama bölümünde ele alıyoruz.

Kaynak Kesildiğinde: local Direktifi ve Yalan Söyleyen Sunucu

local stratum 10 satırı, sunucunun yukarı kaynağını tamamen kaybettiğinde ne yapacağını belirler ve bu, yapılandırmadaki en çok düşünülmesi gereken karardır.

Bu satır olmadan: chronyd uzun süre senkron olamadığında kendini senkronize saymaz ve istemciler onu geçersiz kaynak olarak eler. Zil susar, herkes anlar.

Bu satırla birlikte: sunucu yukarısını kaybetse bile senkronize görünmeye devam eder ve kendi kayan saatini dağıtır. Panel elektriği olan ama saatini yıllardır kimsenin ayarlamadığı bir panele döner. Zil çalmaya devam eder, sadece yanlış anda çalar.

İkisi de doğru olabilir ve karar ortamınıza bağlı:

• İnternete hiç çıkmayan kapalı ağda local gereklidir. Dışarıda bir referans yoktur; önemli olan bütün cihazların birbiriyle aynı olmasıdır, mutlak doğruluk değil.
• İnternete çıkan normal bir kurumda local bir arızayı gizler. Yukarı kaynak koptuğunda sunucu bunu kimseye söylemeden kendi kendine saymaya başlar.

İkinci durumda local satırını yine de yazabilirsiniz, ama bir şartla: sunucunun kaynağını ne zaman kaybettiğini izliyor olmanız gerekir. Burada bir incelik var ve izleme bölümünde ona döneceğiz: sunucunun bu moda düştüğünü gösteren bir alan gerçekten var, ama o alan arızadan çok sonra değişir. Erken haber veren şey başka.

Doğrulama: İstemci Gerçekten Saat Alıyor mu?

Kurulumun doğrulaması, sunucunun ayakta olduğunu görmekle bitmez; bir istemcinin gerçekten o sunucudan saat aldığını görmekle biter. Bu iki şey aynı değildir ve aradaki boşluk, allow satırı unutulmuş kurulumların aylarca fark edilmemesinin sebebidir.

Panelin ışığı yanıyor diye zil çaldığı sonucuna varamazsınız. Bir sınıfa girip duymanız gerekir.

Sunucu Tarafı: Kim Geldi?

Linux sunucuda üç komut çalıştırın. Sırası önemli, çünkü her biri bir öncekini varsayar:

chronyc tracking          # sunucunun kendi saati senkron mu
chronyc sources -v        # yukarıdaki kaynaklar kim, hangisi seçilmiş
sudo chronyc clients      # aşağıdan gerçekten gelen var mı

chronyc tracking çıktısında iki satır kararı verir: Reference ID gerçek bir kaynağı gösteriyor mu, ve Stratum beklediğiniz değerde mi? Ulusal saat kaynağından beslenen bir sunucuda tablo şöyle görünür:

Reference ID    : C21BDE05 (time.ume.tubitak.gov.tr)
Stratum         : 2
System time     : 0.000000791 seconds slow of NTP time
Last offset     : +0.000898762 seconds
Leap status     : Normal

Stratum 2 beklenen değerdir: TÜBİTAK UME Stratum 1, ondan beslenen sunucunuz bir alt basamak. Leap status satırının Normal olması da sunucunun gerçekten senkron olduğunu söyler.

chronyc sources çıktısında ise satır başındaki işaretler seçim durumunu gösterir: ^* seçilmiş ve kullanılan kaynak, ^+ birleştirmeye dahil edilen kaynak, ^- kullanılabilir ama seçilmemiş, ^x diğerleriyle çelişen ve elenen kaynaktır. En az bir satırda ^* görmelisiniz:

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* time.ume.tubitak.gov.tr       1   6    17    42    +38us[ +937us] +/- 5577us
^- ntp.linuxevi.org              2   6    17    42   +551us[ +551us] +/-   17ms
^- time100.stupi.se              1   6    17    41  -4949us[-4949us] +/-   34ms

İlk satırdaki ^* ve Stratum 1, sunucunun ulusal kaynağı seçtiğini gösteriyor. Havuzdan gelen diğer adaylar ^- ile bekliyor; onlar yedek değil, çapraz kontrol. Ölçülen sapmanın mikrosaniye mertebesinde olması da yerel ağdan ulusal kaynağa çıkışın ne kadar kısa olduğunu gösteriyor.

Asıl doğrulama üçüncü komutta. chronyc clients, sunucunun NTP portuna erişen istemcileri hostname, alınan paket sayısı, düşürülen paket sayısı ve son paketten bu yana geçen süreyle listeler. Buradaki en önemli ayrıntı ise şu: yalnızca erişim denetiminden geçen istemciler kayda girer. Yani allow kapsamı dışındaki bir cihaz bu listede hiç görünmez. Liste boşsa ya kimse sormuyordur ya da soranlar allow dışındadır ve ikisini ayırt etmenin yolu istemci tarafına bakmaktır.

Sağlıklı bir sunucuda çıktı şuna benzer; sütunlar sırasıyla istemci adı, alınan NTP paketi ve düşürülen paket sayısıdır:

Hostname                      NTP   Drop Int IntL Last     Cmd   Drop Int  Last
===============================================================================
pc01.lan                        4      0   1   -     0       0      0   -     -

Buradaki 4, o istemcinin gönderdiği sorgu sayısıdır. Sayının test sırasında çalıştırdığınız komutun ürettiği istek sayısıyla örtüşmesi, zincirin uçtan uca çalıştığının en somut kanıtıdır.

Toplam sayaçlar için sudo chronyc serverstats çıktısındaki NTP packets received satırı işinizi görür; iki ölçüm arasında artmıyorsa sunucuya hiç istek gelmiyor demektir.

İstemci Tarafı: Fark Kaç Saniye?

Linux istemcide sunucunun seçilmiş olduğunu görmek yeterlidir:

chronyc sources -v | grep ntp01
timedatectl                 # "System clock synchronized: yes"

Windows istemcide doğru araç w32tm /stripchart’tır ve UDP tabanlı testin tek pratik yolu da budur. Komut ayarı değiştirmez, yalnızca ölçer; hem hedefe ulaşılıp ulaşılmadığını hem de aradaki farkı tek çıktıda verir:

w32tm /stripchart /computer:ntp01 /samples:5 /dataonly
w32tm /query /source

Bu komutun iki farklı çıktısını tanımak, teşhis süresini doğrudan kısaltır. Sunucu erişilemezse ya da allow kapsamı dışındaysanız her satır aynı hatayı verir:

23:28:38, error: 0x800705B4
23:28:41, error: 0x800705B4

0x800705B4 zaman aşımıdır ve “port kapalı” ile “sunucu dinlemiyor” arasında ayrım yapmaz; ikisi de aynı görünür. Erişim kurulduğunda ise aynı komut fark ölçmeye başlar:

23:29:29, -00.1068490s
23:29:31, -00.1068225s
23:29:33, -00.1068336s

Sağdaki değer istemcinin sunucuya göre ne kadar geride olduğudur. Sayının her örnekte tutarlı çıkması bağlantının sağlıklı olduğunu, sürekli değişmesi ise ağ tarafında bir sorun olduğunu gösterir.

İkinci komut, istemcinin saatini nereden aldığını söyler ve elle yapılandırma hatalarını tek satırda ortaya çıkarır. Domain üyesi bir makinede burada ntp01 görüyorsanız o makine hiyerarşinin dışına çıkarılmış demektir; bu genellikle istenmez.

Domain Dışı Cihazlar: Kamera, Switch, NVR

Ağ cihazlarında ve kayıt cihazlarında komut satırı yoktur, yönetim arayüzüne bakarsınız ve markadan bağımsız olarak aynı iki alanı ararsınız: tanımlı NTP sunucusunun adresi ve son başarılı senkronizasyonun zamanı. İkincisi çoğu cihazda ya gösterilmez ya da kimse bakmaz; oysa arızanın saklandığı yer tam orasıdır.

Bu katmandaki bir vakayı, 13 lokasyonlu bir kurumda kayıt cihazlarının yıllar önce kapanmış bir iç NTP sunucusuna bağlı kalmasını kamera sistemi NTP ve KVKK uyum projemizde anlatıyoruz.

Yeni cihaz devreye alma prosedürünüze tek satırlık bir madde eklemek bu boşluğun tamamını kapatır: cihazın NTP ayarı yapıldı mı? Bir switch’i yapılandırırken bunu eklemek otuz saniye sürer.

İzleme: Sessizce Kapanan NTP Sunucusunu Haber Almak

İç NTP sunucusu kurmanın gerçek bedeli kurulum değil, izlemedir. NTP istemcileri kaynağa ulaşamadığında hata üretmez, uyarı vermez, log basmaz; sadece kendi saatlerini saymaya devam ederler. Kayma o günden itibaren yeniden başlar ve aylarca kimse fark etmez.

Zil çalmadığında hiçbir öğrenci müdür yardımcısına gidip haber vermez. Dersler biter, teneffüsler başlar, herkes kendi kolundaki saate bakar. Sistem çöktüğü gün değil, birinin yanlış saatte sınava girdiği gün fark edilir.

Bu yüzden izlemesiz kurulan bir iç NTP sunucusu ilk yıl çok işe yarar, ikinci yıl kurumun bilmediği bir riske dönüşür.

İzlenecek Üç Şey

Servisin ayakta olup olmadığını izlemek en zayıf sinyaldir, çünkü chronyd çalışırken de yanlış saat dağıtabilir. Ama asıl tuzak burada değil: chronyc tracking çıktısı, sunucu bütün kaynaklarını kaybettikten sonra bile uzun süre sağlıklı görünmeye devam eder.

Bunu ölçmek kolay. Bir sunucunun bütün yukarı kaynaklarını kestiğinizde, beş dakika sonra chronyc tracking hâlâ eski kaynağın adını gösterir ve Leap status hâlâ Normal der. Değişen tek şey Ref time satırının donmasıdır.

Sebebi mekaniktir. chronyd kendini “senkron değil” saymak için kök mesafesinin belirli bir eşiği aşmasını bekler ve o mesafe, kaynak koptuktan sonra yerel saatin hata payı kadar, yani saniyede birkaç mikrosaniye hızında büyür. Varsayılan eşik saniyeler mertebesinde olduğu için Leap status satırının Not synchronised’a dönmesi günler sürer. Aynı sebeple Reference ID alanının local modu gösteren 7F7F0101 değerine düşmesi de günler sonra olur. İkisi de gerçek göstergedir, ama ikisi de geç göstergedir; alarmı onlara kurarsanız arızayı bir hafta sonra öğrenirsiniz.

Erken haber veren iki ölçüm var ve ikisi de aynı anda tepki verir:

1. Kaynaklara ulaşılabiliyor mu? chronyc sources çıktısındaki Reach sütunu, son sekiz sorgunun kaçına cevap geldiğini sekizlik sayı olarak tutar. Sağlıklı durumda 17 gibi bir değer görürsünüz, kaynak koptuğunda anında 0’a düşer ve satır başındaki işaret ^*’dan ^?’ye döner:

^? time.ume.tubitak.gov.tr       1   6     0   310   -146us[ -191us] +/- 5403us
^? ntp.linuxevi.org              2   7     0   377   +826us[ +721us] +/-   17ms

2. Son güncellemenin üzerinden ne kadar geçti? chronyc tracking çıktısındaki Ref time donduğu an bunu size söyler. Değeri şimdiki zamanla karşılaştırmak tek satırlık iştir ve normal koşulda birkaç dakikayı geçmez. Windows tarafındaki karşılığı w32tm /query /status çıktısındaki Last Successful Sync Time satırıdır; iki platformda da izlenmesi gereken asıl metrik budur.

Üçüncü bir ölçüm de aşağı yönü kapatır:

3. İstemciler gerçekten geliyor mu? chronyc serverstats çıktısındaki NTP packets received sayacı artmıyorsa sunucu ayakta ama kimse ondan saat almıyordur. allow kapsamının daraldığı ya da bir güvenlik duvarı kuralının değiştiği durumlar buradan görünür.

# Linux sunucuda izleme sisteminin calistiracagi kontroller
chronyc sources | awk 'NR>3 && $4=="0"' | wc -l   # cevap vermeyen kaynak sayisi
chronyc tracking | sed -n 's/^Ref time (UTC) *: //p'  # yasi hesaplanacak
chronyc serverstats | grep "NTP packets received"

Alarmı Neye Kurmalı

Alarm eşiğini saat farkına değil, erişilebilirliğe kurun. Bunun sebebi arızanın davranış biçimidir: bir NTP sunucusu kaynağını kaybettiğinde saati bir anda bozulmaz, günde birkaç saniye kayar. Sapma üzerine kurulmuş bir alarm haftalar sonra, hasar çoktan oluştuktan sonra çalar.

Pratik eşik şudur: Ref time yaşı yoklama aralığının birkaç katını aşarsa uyar. Normal işleyişte bu değer dakikalar mertebesindedir; on beş dakikayı geçmesi kaynağın koptuğu anlamına gelir ve bu, kaymanın ölçülebilir hale gelmesinden çok önce gelir. Yanına Reach sütununun sıfırlanmasını da koyarsanız aynı arızayı iki bağımsız yerden yakalarsınız.

Leap status ve Reference ID kontrollerini de ekleyin, ama onları alarm değil teyit olarak kullanın: çaldıktan sonra “gerçekten kaynaksız mı kalmış” sorusunu onlar cevaplar.

İzleme altyapınız zaten varsa bu üç kontrolü mevcut sisteminize eklemek birkaç dakikalık iştir. Yoksa kurulum kararının kendisi ayrı bir konudur ve bunu çok lokasyonlu bir kurumda nasıl kurduğumuzu Cacti, Zabbix ve Grafana izleme projemizde anlatıyoruz.

Stratum 1: Kendi Referansınızı Kurmak

Stratum 1 sunucu, referans saate doğrudan bağlı olan sunucudur ve kurmak için bir GPS ya da radyo alıcısı gerekir. Kurumsal bir ağda buna ihtiyaç duyulması nadirdir; ama ihtiyaç duyulan senaryolarda başka hiçbir çözüm yerini tutmaz.

Okulun çatısına kendi anteni konulmuş gibi düşünün. Panel artık kimseye sormuyor, saati doğrudan kaynaktan alıyor. Çoğu okulda buna gerek yoktur; bir rasathanede vardır.

Ne Zaman Gerçekten Gerekir?

Üç durum var ve üçü de doğruluk hevesiyle değil, zorunlulukla ilgili.

Ağ internete hiç çıkmıyorsa. Hava boşluklu (air-gapped) üretim ağlarında, laboratuvarlarda ve bazı kamu ortamlarında dışarıya bir NTP paketi bile çıkamaz. Bu durumda referansı içeri getirmekten başka yol yoktur; local direktifiyle kayan bir saat dağıtmak da bir tercih, ama zamanla mutlak doğruluğu tamamen kaybedersiniz.

Onlarca milisaniyenin altında doğruluk isteniyorsa. Ölçüm sistemleri, finansal işlem kayıtları ve bazı endüstriyel senkronizasyon senaryoları bunu şart koşar. Bu eşiğin altında dış NTP kaynağının ağ gecikmesi başlı başına bir hata payıdır.

Siz saat dağıtan taraf konumundaysanız. Müşterilerine ya da alt kurumlarına zaman servisi veren bir yapıdaysanız zincirin kökünü kendinizde tutmak isteyebilirsiniz.

Bu üçü yoksa cevap nettir: TÜBİTAK UME’nin ulusal saat kaynağından beslenen bir Stratum 2 sunucu, kurumsal ihtiyaçların tamamını fazlasıyla karşılar.

chrony ile GPS ve PPS

chrony, donanım saat kaynaklarını refclock direktifiyle tanır ve tipik bir GPS kurulumunda iki ayrı kaynak birlikte kullanılır:

# Saniyenin tam sınırını veren darbe sinyali
refclock PPS /dev/pps0 refid PPS lock NMEA

# Hangi saniyede olduğumuzu söyleyen GPS verisi
refclock SHM 0 refid NMEA offset 0.0 delay 0.2

İkisinin ayrı olmasının sebebi işbölümüdür ve bu ayrım kurulumun tamamını açıklıyor. PPS sinyali saniyenin nerede başladığını mikrosaniye hassasiyetinde söyler ama hangi saniye olduğunu bilmez. GPS’in NMEA verisi ise tam tersini yapar: hangi saniyede olduğunuzu söyler, ama seri port üzerinden geldiği için milisaniye mertebesinde belirsizlik taşır. lock NMEA satırı ikisini birbirine bağlar; kaba saati NMEA verir, ince ayarı PPS yapar.

Sonuç, projenin kendi ölçümünde yaklaşık 20 mikrosaniyelik bir sapmadır ve sapmanın kaynağı da artık GPS değil, seri portun kesme sinyalini damgalama gecikmesidir.

Sonraki Adımlar

Sunucu ayakta ve izleniyorsa sıradaki iş istemcileri ona yönlendirmektir. Windows sunucularında zaman kaynağının kurulum sonrası nasıl doğrulandığını Windows Server kurulum rehberimizde, switch ve router tarafındaki NTP tanımının cihaz devreye alma sırasının neresine girdiğini ise switch ve router kurulumu rehberimizde ele alıyoruz.

Sonuç: Kurulan Değil, İzlenen Sunucu

Bu rehberde iç NTP sunucusunun ne zaman gerçekten gerektiğini, platform sorusunun cevabının marka değil tavan olduğunu, chrony ile Ubuntu üzerinde kurulumu, Windows tarafında zaten var olanın nasıl açıldığını, doğrulamanın neden sunucuda değil istemcide bittiğini ve izlemenin neden kurulumun kendisinden önemli olduğunu ele aldık.

Akılda tutulacak iki cümle var. Birincisi: allow satırı yazılmadan kurulan bir sunucu çalışıyor görünür ve kimseye cevap vermez. İkincisi: izlenmeyen bir NTP sunucusu, kurulduğu gün çözdüğü problemi iki yıl sonra daha büyük halde geri getirir.

Zil paneli de öyleydi. Kurulduğu gün okulun bütün saat tartışmasını bitirdi. Kimse bir daha ona bakmadı, çünkü çalıştığı sürece görünmez olmak zaten onun işiydi.

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üren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.