Makale içeriği

Hayal edin: dün proxy üzerinden çalışan parser'ınız kusursuz çalışıyordu, loglar temiz, metrikler yeşil. Bu sabah panoyu açıyorsunuz ve bir hata duvarıyla karşılaşıyorsunuz: certificate is not yet valid, token expired, signature does not match. Bir mühendisin ilk düşüncesi tahmin edilebilir: proxy bozuldu, sağlayıcı bir şeyler yaptı, havuzu değiştirmem lazım. Ağ teşhisine saatler harcıyorsunuz, uç noktaları değiştiriyorsunuz, desteğe yazıyorsunuz. Ama asıl sebep bunca zamandır tam burnunuzun dibinde oturuyordu ve yanlış tikliyordu. Bu, sistem saati.

Saat senkronizasyonu sorunu, proxy üzerinden çalışan altyapılarda en hafife alınan arıza kaynaklarından biridir. Sinsi tarafı, kendini ağ ve sertifika sorunları gibi gizlemesidir. Hata mesajında certificate kelimesini görürsünüz ve refleks olarak TLS ile uğraşmaya gidersiniz, oysa sertifika tamamen canlı ve geçerlidir. Sadece makineniz şu anın başka bir gün olduğunu düşünüyordur.

Bu rehberde konuyu A'dan Z'ye ele alacağız. Zamanın kriptografiye ve protokollere tam olarak nerede gömülü olduğunu, curl, Python ve Node'da belirli hataların nasıl göründüğünü, sanal makinelerde ve konteynerlerde saatin neden kaydığını, bir dakikada nasıl teşhis koyacağınızı ve senkronizasyonu gerçekten çalışacak şekilde nasıl yapılandıracağınızı öğreneceksiniz - sadece kurulu görünmesini değil. Bu içerik Proxeon mühendisleri tarafından gerçek olay incelemelerine dayanarak yazılmıştır. Özellikle belirtelim: konu sertifika düzenleme veya sertifikaların yapısı değil - yalnızca arıza nedeni olarak zaman.

Temeller: zaman neden sadece ekrandaki bir sayı değil, protokolün bir parçasıdır

Temelden başlayalım. Çoğu kişi sistem saatini tamamen insani bir alışkanlık olarak algılar: şu an 14:30 olduğunu bilmek işe yarar. Ama ağ protokolleri dünyasında zaman, güvenlik kontrollerinin aktif bir katılımcısıdır. Doğrulama mantığına birkaç katmanda birden işlenmiştir.

İki düğüm güvenli bir bağlantı kurduğunda veya imzalı mesajlar alışverişinde bulunduğunda, taze verileri eskimiş verilerden ayırt edebilmeleri gerekir. Zaman kavramı olmadan basit sorulara cevap vermek imkânsızdır: bu sertifikanın süresi dolmuş mu? bu token'ın süresi dolmuş mu? bir saldırgan eski ele geçirilmiş bir isteği tekrarlıyor mu? İşte bu yüzden protokollere zaman damgaları ve geçerlilik pencereleri gömülmüştür.

Sistem saati nedir ve nereden gelir

Her işletim sisteminde birbiriyle ilişkili iki kavram vardır. Birincisi donanım saati (RTC, real-time clock), kendi pille beslenen ve bilgisayar kapalıyken bile tikleyen bir yongadır. İkincisi, çekirdeğin RAM'de tuttuğu, açılışta RTC değerinden başlayan ve çalışma boyunca ayarlanan sistem saatidir.

Sorun şu ki herhangi bir donanımdaki kuvars osilatör mükemmel değildir. Günde saniyenin kesirleri kadar ileri veya geri gider. Buna saat kayması denir. Düzeltme olmadan bir haftada belirgin saniyeler, bazı sanal ortamlarda ise tam dakikalar birikir. Kaymayla mücadele için ağ zaman senkronizasyon protokolü icat edildi. Senkronizasyon arka plan programı periyodik olarak referans sunuculardan doğru zamanı sorar ve yerel saati yumuşakça hizalar.

UTC, saat dilimleri ve bunun proxy için önemi

Yeni başlayanlar için kilit içgörü: tüm ciddi ağ kriptografisi UTC - Eşgüdümlü Evrensel Zaman - ile çalışır, saat dilimlerine bağlı değildir. Sertifikalar, JWT'ler, istek imzaları - hepsi UTC cinsinden zaman anlarıyla çalışır. Saat dilimi, insana gösterim için kozmetiktir.

Bu şu anlama gelir: saat dilimini yanlış ayarladıysanız ama mutlak zaman (UTC'de) doğruysa, kriptografi zarar görmez. Ama mutlak zaman bozuksa - her şey dağılır. Sık karışıklık: mühendis loglarda garip yerel saat görür, saat dilimini düzeltmeye gider, oysa sorunun kökü başkadır. Ayrımı unutmayın: saat dilimi gösterimi etkiler, UTC'deki mutlak zaman kontrolleri etkiler.

Proxy bu tabloya nasıl girer

Proxy üzerinden çalıştığınızda, istek yolunda ek bir düğüm ortaya çıkar. Ama şunu anlamak önemlidir: proxy çoğu senaryoda kriptografik kontrollerinizdeki zamanı değiştirmez veya ikame etmez. Hedef sunucuyla TLS el sıkışması, sertifika süresi doğrulaması, token doğrulaması - hepsi sizin tarafınızda veya son sunucu tarafında gerçekleşir. Proxy yalnızca baytları iletir.

Buradan bir paradoks çıkar: proxy üzerinden çalışmak zaman sorununu yaratmaz, ama belirtilerini daha karmaşık hale getirir. Mühendis istemci - proxy - sunucu zincirini görür ve doğal olarak aradaki halkadan şüphelenir. Oysa suçlu, saatin yanlış gittiği yerel makinedir. Buna kaydırılmış şüphe etkisi diyoruz: zincir ne kadar uzunsa, ortasını o kadar isteyerek suçlarız, uçlarını değil.

Derinlemesine bakış: zaman tam olarak nerede kritiktir

Şimdi daha derine inip yanlış zamanın arızaya dönüştüğü somut noktaları inceleyelim. Dört tanedir ve her biri ayrı ilgiyi hak eder.

TLS'te sertifika geçerlilik süresi kontrolü

Her TLS sertifikası iki alan içerir: notBefore (bu tarihten önce geçerli değil) ve notAfter (bu tarihten sonra geçerli değil). Bunlar geçerlilik penceresinin sınırlarıdır. İstemciniz güvenli bir bağlantı kurduğunda sunucunun sertifikasını alır ve kontrol eder: geçerli zaman bu pencereye düşüyor mu?

İşte kilit nokta: geçerli zaman derken makinenizdeki zaman anlaşılır. Saatiniz geri kalıyorsa ve notBefore'dan önceki bir tarihi gösteriyorsa, istemci sertifikanın henüz başlamadığına karar verir. certificate is not yet valid hatası. Saatiniz ileri gidip notAfter'ı geçtiyse - sizin için sertifika çoktan dolmuş, oysa dünyanın geri kalanı için taze. certificate has expired hatası.

Özellikle kısa ömürlü sertifikalar sinsidir. Modern uygulama 90 gün ve daha kısa ömürlü sertifikalara doğru gidiyor, 2026'ya doğru endüstri 45 gün ve altına indirmeyi tartışıyor. Geçerlilik penceresi ne kadar kısaysa, bozuk saatlere karşı güvenlik marjı o kadar azalır. Eskiden bir saatlik senkronizasyon kaybı yıllık sertifikada neredeyse görünmezdi. Şimdi dar pencere, güncelleme sınırında birkaç saatlik kaymanın bile bağlantıyı düşürebileceği anlamına gelir.

JWT: exp, nbf ve iat alanları

JSON Web Token, popüler bir yetkilendirme token formatıdır. İçinde her kullanımda kontrol edilen zaman alanları vardır:

  • exp (expiration time) - token'ın süresinin dolduğu an.
  • nbf (not before) - token'ın henüz geçerli olmadığı an.
  • iat (issued at) - token'ın verildiği zaman.

Üçü de Unix zaman damgasıdır, yani epoch'tan itibaren saniye cinsinden UTC mutlak zamanı. Sunucu token'ı aldığında bu alanları kendi saatleriyle karşılaştırır. İstemciniz token'ı yenilemesi gerekip gerekmediğine karar verirken exp'ye kendi saatine göre bakar.

Arıza senaryosu zararlılığındaki zarafetle dikkat çeker. Diyelim ki istemci saatiniz on dakika ileri gitti. Sunucu beş dakikalık ömürlü token verdi. İstemciniz ileri giden saate bakarak taze token'ı anında süresi dolmuş sayar ve ya göndermez ya da sonsuz bir yenileme döngüsü başlatır. Ters durum: nbf sizin saatinize göre bozuksa, token used before issued veya token not yet valid alırsınız.

Zaman damgalı istek imzaları

Birçok API her isteğin imzalanmasını ve imzaya bir zaman damgasının dahil edilmesini gerektirir. Klasik örnek HMAC imzası şemalarıdır: istemci metot, yol, gövde ve geçerli zaman damgasından bir dizi oluşturur ve gizli anahtarla imzalar. Sunucu hesaplamayı tekrarlar ve imzaları karşılaştırır.

Burada zaman iki rol oynar. Birincisi, zaman damgası imzalanan dizinin bir parçasıdır, dolayısıyla sunucu istemcinin gönderdiği tam aynı zaman damgasını kullanmalıdır - değeri başlıktan alır. İkincisi, sunucu bu zaman damgasının kendi zamanına çok uzak olmadığını kontrol eder. Genellikle birkaç dakikalık pencereye izin verilir - eski isteklerin yeniden oynatılmasına karşı koruma.

İstemci saati bu pencerenin dışına çıktıysa, sunucu isteği çok eski veya gelecekten gelmiş diye reddeder. request timestamp too skewed, signature expired veya genel signature does not match gibi hatalar. Üstelik sırf zaman yüzünden sıkça imza hatası görürsünüz, zaman hatası değil - sunucu her zaman işin saatle ilgili olduğunu dürüstçe söylemez.

Tek kullanımlık kodlar ve zamana dayalı şifreler

Ayrı bir kategori de yönetim panellerine ve API konsollarına erişimde iki faktörlü kimlik doğrulamada kullanılan zamana dayalı tek kullanımlık kodlardır (TOTP). Böyle bir kod, ortak gizli anahtar ve genellikle 30 saniyelik aralıklara bölünmüş geçerli zamandan hesaplanır. Her iki taraf kodu bağımsız hesaplar ve karşılaştırır.

İstemci saati bir-iki aralıktan fazla bozuksa kodlar eşleşmez. Yeni oluşturulmuş kodu girersiniz, sistem yanlış der. Bu durumda insanlar kod üretici uygulamayı suçlar veya hacklenme paniğine kapılır, oysa saate bakmak yeterliydi. Buradaki tolerans çok dardır - onlarca saniye - bu yüzden TOTP mükemmel bir senkronizasyon bozukluğu göstergesi olarak çalışır.

Hata farklı istemcilerde nasıl görünür

Teori teori, ama mühendis terminalde yaşar ve hata metinlerini okur. Gelin popüler araçlarda senkronizasyon bozukluğunun nasıl tezahür ettiğini inceleyelim. Bu, semptomu anında tanımanıza yardımcı olacaktır.

curl

curl ile TLS üzerinden çalışırken bozuk saatler karakteristik mesajlar üretir. Zaman geri kalıyorsa ve sertifika sizin saatinize göre henüz başlamadıysa:

curl: (60) SSL certificate problem: certificate is not yet valid

Zaman ileri gidip sertifika sizin ölçünüze göre dolduysa:

curl: (60) SSL certificate problem: certificate has expired

Yararlı detay: hata kodu 60 sertifika doğrulama sorunlarına işaret eder. Deneyimsiz bir mühendis certificate kelimesini görür ve sertifikanın kendisini inceleme komutuyla kontrol etmeye gider, geçerlilik tarihlerinin düzgün olduğunu görür ve şaşkına döner. Çözüm şu ki sertifika tarihleri sizin yerel saatinizle karşılaştırılır. Proxy üzerinden bir örnek deneyin:

curl -x http://user:pass@gateway.proxeon.net:8080 -v https://api.example.com/status

-v çıktısında sertifika tarih kontrolü satırlarını ve ardından geçerlilik hatasını görüyorsanız - ilk iş olarak ağ geçidinden şüphelenmek yerine date -u'yu referansla karşılaştırın.

Python (requests ve httpx)

Python'da standart TLS yığını temelinde bozuk saatler el sıkışmada bir istisna fırlatır:

requests.exceptions.SSLError: HTTPSConnectionPool(host='api.example.com', port=443): Max retries exceeded (Caused by SSLError(SSLCertVerificationError("certificate verify failed: certificate is not yet valid")))

Mesajın sonuna dikkat edin: certificate is not yet valid. Bu aynı zaman semptomudur. JWT ile çalışırken tablo farklı - hiç TLS hatası yok, ama token doğrulama kütüphanesi kendine özgü bir istisna atar:

jwt.exceptions.ImmatureSignatureError: The token is not yet valid (nbf)

veya

jwt.exceptions.ExpiredSignatureError: Signature has expired

Burada signature kelimesi kafa karıştırıcıdır - sorun kriptografik imzadaymış gibi görünür. Oysa expired aslında exp alanına ve saatinize işaret eder. Koddan doğrudan hızlı zaman kontrolü:

import time, datetime; print(datetime.datetime.utcnow(), int(time.time()))

Elde edilen Unix zaman damgasını referansla karşılaştırın - birkaç saniyeden fazla sapma zaten şüphelidir.

Node.js

Node'da TLS hataları kodlarla gelir. Senkronizasyon bozukluğu için karakteristik olanlar:

Error: certificate is not yet valid\ncode: 'CERT_NOT_YET_VALID'

ve

Error: certificate has expired\ncode: 'CERT_HAS_EXPIRED'

CERT_NOT_YET_VALID ve CERT_HAS_EXPIRED kodları doğrudan işaretçilerdir. Canlı bir sertifikada birincisini görüyorsanız, saatiniz geri kalıyor. Bilinen taze bir sertifikada ikincisini görüyorsanız - saatiniz ileri gidiyor. Node'da JWT kütüphaneleriyle çalışırken TokenExpiredError ve NotBeforeError gibi isimlerde hatalar alırsınız. Hızlı kontrol:

node -e "console.log(new Date().toISOString(), Math.floor(Date.now()/1000))"

Belirti özet tablosu

Desenleri tek bir zihinsel haritada toplayalım:

  • certificate is not yet valid / CERT_NOT_YET_VALID - saat geri kalıyor.
  • certificate has expired / CERT_HAS_EXPIRED taze sertifikada - saat ileri gidiyor.
  • token not yet valid / nbf / ImmatureSignature - saat veren sunucuya göre geri kalıyor.
  • token expired / ExpiredSignature token alınır alınmaz - saat ileri gidiyor.
  • signature does not match / timestamp too skewed - saat sunucunun tolerans penceresinin dışına çıktı.
  • Sürekli yanlış TOTP kodu - saat onlarca saniye ve daha fazla bozuk.

Saat neden kayar: kaymanın anatomisi

Sebebi anlamak çözümün yarısıdır. Modern altyapıda saatin göründüğünden daha sık bozulmasının nedenini inceleyelim. Özellikle proxy trafiğini geçirdiğiniz sunucular ve iş düğümleri için.

Sanal makineler ve dondurma

Bir sanal makinenin fiziksel kuvarsa doğrudan erişimi yoktur. Zaman anlayışı, hipervizörün sürdürdüğü bir soyutlamadır. Genellikle VM kesintisiz çalıştığı sürece her şey yolundadır. Ama hipervizör makineyi duraklatırsa - harikalar başlar.

Klasik senaryo - dondurma ve anlık görüntüler. Hipervizör VM'yi duraklatır, örneğin geçiş veya yedekleme için. Konuk içinde zaman sanki durur. Makine çözüldüğünde sistem saati tam olarak duraklama süresi kadar geri kalır. Bu bir dakikaysa - bir dakikalık kayma anında, tek seferde gelir. Kısa ömürlü token'lar ve dar imza pencereleri için bu ölümcüldür.

Eski bir anlık görüntüden geri yüklemede durum daha da kötüdür. Makine anlık görüntünün alındığı andaki zamanla canlanır - bu saatler veya günler geçmiş olabilir. TLS hemen sertifikaları henüz geçerli değil diye reddetmeye başlar. Birçok bulut platformu çözülmeden sonra saati hizalayan konuk ajanlar sunar, ama her zaman kurulu ve çalışır olmazlar.

Konteynerler

Konteynerlerde hikâye daha incedir. Konteynerin kendi sistem saati yoktur - ana makinenin çekirdeğini ve dolayısıyla ana makinenin saatini kullanır. Bu iyi haber: ana makine senkronizeyse konteyner doğru saati otomatik görür.

Kötü haber nüanslarda. Birincisi, konteyner içinde genellikle sistem saatini değiştiremezsiniz - ilgili ayrıcalıkları yoktur ve bu doğrudur. İkincisi, önemle, konteyner içinde senkronizasyon arka plan programı genellikle yoktur ve bu normaldir - senkronize etmesi gereken ana makinedir. Sorun, ana makine kendisi senkronize değilse ve siz bunu fark etmiyorsanız ortaya çıkar, çünkü geliştiricinin dizüstü bilgisayarında her şeyin kutudan çıktığı gibi senkron olduğuna alışmışsınızdır.

Senkronizasyon arka plan programının yokluğu

En basit ve en sık sebep. Minimal sunucu imajlarında saat senkronizasyon arka plan programı kurulu veya çalışır değil olabilir. Makine başlar, RTC'den zamanı alır, sonra düzeltmesiz kaydıran kuvars üzerinde yaşar. Gün geçtikçe kayma birikir.

Özellikle elle oluşturulmuş veya klonlanmış imajlar tehlikelidir. Mühendis her şeyi referans makinesinde yapılandırdı, imajı aldı, yüz düğüme dağıttı - ama senkronizasyon arka plan programı orada etkin değildir. Yüz düğüm sessizce her biri kendi tarafına doğru ayrılmaya başlar. Kayma küçükken her şey çalışır. Bir hafta sonra en hızlı kuvarslar tolerans penceresini aşar ve siz parkın bir bölümünde değişken, tekrarlanamaz arızalar alırsınız.

Manuel düzeltme ve takılı kalmış RTC

Bazen zamanı insan bozar. Birisi bir test için tarihi elle ayarladı ve geri almayı unuttu. Birisi belirli bir deneyi engellediği için senkronizasyonu kapattı. Ayrı bir bela da fiziksel sunucudaki bitmiş RTC pili: yeniden başlatmadan sonra saat uzak bir geçmişe sıfırlanır ve ilk senkronizasyona kadar TLS hiç çalışmaz.

Çift zaman yönetimi

Unutulan ince bir durum. Bazen zaman için aynı anda iki mekanizma yarışır: hipervizörün konuk ajanı ve işletim sistemi içindeki senkronizasyon arka plan programı. Saati farklı yönlere çekerler ve ileri geri salınımlar alırsınız. Bu, yakalanması imkânsız, aralıklı arızalar olarak tezahür eder. Kural basit: zamandan tam olarak bir mekanizma sorumlu olmalıdır.

Bir dakikada teşhis: hızlıca tanı koymak

Pratiğe geçelim. Amacınız altmış saniyede işin saatle ilgili olup olmadığını anlamaktır. İşte Proxeon'da olay incelemelerinde kullandığımız adım adım çerçeve.

Birinci adım: kendi zamanınıza UTC'de bakın

İlk iş, saatinizin ne düşündüğünü öğrenin, özellikle UTC'de, saat dilimi karışıklığını elemek için:

date -u

Değeri kaydedin. Şimdi referansla karşılaştırın.

İkinci adım: harici kaynakla karşılaştırın

En güvenilir yol, bir ağ zaman sunucusundan zamanı sormak ve kaymaya bakmaktır. chrony kuruluysa:

chronyc tracking

Çıktıda System time satırını arayın - sistem saatinin referansa göre kaymasını gösterir. 0.000030 seconds gibi bir değer idealdir. systemd-timesyncd ise:

timedatectl show-timesync --all | grep -i offset

Bir başka hızlı yöntem de saati değiştirmeden zaman sunucusuna tek seferlik sorgu:

chronyd -Q 'server pool.ntp.org iburst'

Tahmini düzeltmeyi yazdırır. Modülü büyükse - işte cevabınız.

Üçüncü adım: HTTP Date başlığıyla kontrol edin

Tonlarca zaman kazandıran bir içgörü. Neredeyse her web sunucusu yanıtta UTC cinsinden geçerli zamanla Date başlığını döndürür. Proxy'niz üzerinden doğrudan saatinizle karşılaştırın:

curl -sI -x http://user:pass@gateway.proxeon.net:8080 https://example.com | grep -i ^date

date -u ile karşılaştırın. Fark saniyelerse - her şey yolunda. Dakikalarsa - işte sebebiniz. Yöntemin güzelliği kurulu arka plan programları gerektirmemesi ve curl'den başka bir şeyin olmadığı çıplak konteynerlerde bile çalışmasıdır.

Hangi sapma normal sayılır

Deneyimle geliştirilmiş pratik kılavuzlar:

  • 1 saniyeye kadar - mükemmel, yapılacak bir şey yok. Sağlıklı senkronize bir sistem saniyenin kesirlerini tutar.
  • 1-5 saniye - TLS ve çoğu JWT için kabul edilebilir, ama dikkat bölgesi. İstek imzaları ve TOTP hâlâ dayanıyor, ama marj eriyor.
  • 5-30 saniye - alarm. TOTP bozulmaya başlar, dar imza pencereleri tehdit altında. Senkronizasyon açıkça gerektiği gibi çalışmıyor.
  • 30 saniyeden fazla - kritik. İmzalar, kısa ömürlü token'lar ve büyük kaymalarda TLS de başarısız olur. Derhal düzeltin.
  • Dakikalar ve saatler - felaket, genellikle dondurma, anlık görüntü veya ölü RTC pilinin sonucu.

Altın kural: sapma beş saniyeden fazlaysa, zamanı tüm TLS, token ve imza arızalarında birinci şüpheli olarak değerlendirin.

Senkronizasyon yapılandırması: gerçekten çalışsın diye

Teşhis etmek yetmez - tedavi etmek ve tekrarını önlemek gerekir. Linux'taki iki ana aracı ve en önemlisi, senkronizasyonun gerçekten aktif olduğundan nasıl emin olacağınızı inceleyelim - sadece kurulu olmadığından. Bu, gözden kaçırılan kilit farktır.

systemd-timesyncd: basit seçenek

Çoğu istemci makinesi ve hafif düğüm için systemd'ye gömülü istemci yeterlidir. Zaman protokolü üzerinden basit senkronizasyon yapar. Etkinleştirme:

timedatectl set-ntp true

Senkronizasyonun gerçekten devam ettiğini kontrol edin:

timedatectl status

İki satırı arayın. System clock synchronized: yes sistemin kendini senkronize saydığı anlamına gelir. NTP service: active arka plan programının çalıştığı anlamına gelir. Her ikisi de olumlu olmalıdır. active iken synchronized: no ise - arka plan programı başlamış ama henüz sunucuya bağlanamamış veya sunucu erişilemezdir.

Belirli bir sunucu hakkında detay:

timedatectl show-timesync --all

Burada hangi sunucuya bağlandığınız ve hangi sapmayı aldığınız görünür. Tam da bu komut gerçekten çalışan senkronizasyonu dekoratif olandan ayırır.

chrony: ciddi seçenek

Kararlılığın önemli olduğu sunucular için, özellikle dondurma riski olan sanal makineler için chrony tercih edilir. Zaman sıçramalarından daha akıllıca çıkar ve kesintiden sonra daha hızlı yakınsar. Paket yöneticisiyle kurulum, ardından servis başlatma. Çalışma kontrolü - ana komut:

chronyc tracking

Çıktının anahtar satırlarının çözümü:

  • Reference ID - hangi kaynağa bağlı. 00000000 veya kaynak seçilmediğine dair bir satırsa senkronizasyon yok.
  • Stratum - referans saatlerden uzaklık seviyesi. Küçük bir sayı görmek normaldir.
  • System time - sistem saatinin geçerli kayması. Bu ana göstergenizdir.
  • Last offset ve RMS offset - son ve ortalanmış düzeltmeler, kararlılığı gösterir.

Kaynak listesi ve durumları:

chronyc sources -v

Sunucunun solundaki yıldız işareti tam olarak onun aktif kaynak olarak seçildiği anlamına gelir. Hiçbir kaynakta seçim işareti yoksa, arka plan programı kurulu ama senkronize olmuyor demektir - tipik bir tuzak.

Kurulu senkronizasyonu çalışandan nasıl ayırt edersiniz

İşte tam da bu bölümü okumaya değer içgörü. Paketin kurulu olması ve hatta servisin çalışıyor olması senkronizasyonu garanti etmez. Servis dönüyor ve zaman sunucularına erişimi yok olabilir - örneğin güvenlik duvarı doğru porta giden giden paketleri kesiyor olabilir veya kapalı bir ağda iç zaman sunucusu yoktur.

Gerçek kontrol üç sorudan oluşur. Birincisi: aktif kaynak seçili mi? sources'taki işarete veya tracking'deki Reference ID'ye bakın. İkincisi: geçerli sapma nedir? System time saniyenin kesirlerinde olmalı. Üçüncüsü: güncelleniyor mu? Kontrolü aralıklı iki kez çalıştırın ve sayıların canlı olduğundan, donmadığından emin olun. Üç cevap da olumluysa - senkronizasyon gerçekten çalışıyor.

Kaymayı metrik olarak izleme

Profesyonel yaklaşım olayı beklemek değil, kaymayı sürekli izlemektir. System time değerini izleme sisteminize normal bir metrik olarak çıkarın. Örneğin iki saniyeyi aşınca uyarı, beşte alarm ayarlayın. O zaman imzalar ve token'lar çökmeye başlamadan önce sorunu öğrenirsiniz. Böyle bir izlemenin maliyeti sıfıra yakın, geri dönüşü muazzamdır: önlenen bir gece olayı her şeyi haklı çıkarır.

Konteynerler ve saat: ne miras alınır, ne alınmaz

Konteynerleştirme ayrı bir derin incelemeyi hak eder, çünkü mühendislerin en çok yanlış anladığı yer burasıdır. Konteynerin ana makineden ne aldığını, neyi almadığını raflara ayıralım.

Miras alınan: zamanın kendisi

Kilit gerçek: konteyner ana makinenin çekirdeğini ve dolayısıyla sistem saatini paylaşır. Konteyner içinde date -u ana makinedekiyle tam olarak aynı mutlak zamanı gösterir. Konteynerin ayrı zaman sayacı yoktur. Bu temeldir. Buradan ana sonuç çıkar: konteynerin doğru saati görmesi için ana makineyi senkronize etmek gerekir, konteyner içinde senkronizasyon ayarlamaya çalışmak değil.

Miras alınmayan: saat dilimi

Ama zamanın gösterimi başka bir konu. Saat dilimi konteyner içindeki ayarlarla, genellikle bir zone dosyası ve ortam değişkeniyle belirlenir. Temel imaj genellikle UTC ile gelir ve bu, bu arada sunucular için iyi bir uygulamadır. Konteyner içinde yerel saat ana makinedekinden farklı görünüyorsa - bu hemen hemen her zaman gerçek zaman değil saat dilimi farkıdır. Paniklemeden önce UTC üzerinden mutlakı kontrol edin.

Konteynerde neden zaman arka plan programı çalıştırmamalı

Yeni başlayanların yaygın bir hatası - senkronizasyon arka plan programını konteynerin içine tıkmak. Bu iki nedenden dolayı yanlıştır. Birincisi, sistem saatini değiştirmek tüm çekirdeği ve dolayısıyla ana makinedeki tüm konteynerleri ve ana makinenin kendisini etkileyen ayrıcalıklı bir işlemdir. Varsayılan olarak konteynere bu yasaktır ve bu iyidir. Senkronizasyon için bu ayrıcalığı vermek - bir delik açmak ve çatışma yaratmak demektir.

İkincisi, buna gerek yoktur: zaman zaten ana makineden gelir. Doğru mimari - bir senkronize ana makine, otomatik olarak doğru saati gören birçok konteyner. Birden çok düğümlü bir orkestratörünüz varsa, senkronizasyonu her pod'da değil, her düğüm-ana makinede sağlamalısınız.

Geliştirici dizüstü bilgisayarının tuzağı

Ayrıca sinsi bir durum konusunda uyaralım. Geliştiricinin dizüstü bilgisayarında her şey çalışır: konteynerler doğru saati görür, çünkü iş istasyonunun işletim sistemi kutudan çıktığı gibi senkronizedir. Mühendis imajı oluşturur, her şey yeşil. İmaj ana makinesinin senkronize olmadığı bir sunucuya gider - ve orada arızalar başlar. Ders: uygulamanın davranışını sadece ideal zamanda değil, bozuk zamanda da test edin. Test ortamında saati bilinçli olarak kaydırın ve uygulamanın nasıl tepki verdiğini görün.

Çalışan bir konteynerde zaman kontrolü

Çalışan bir konteynerin içine bakmak ve mutlak zamanını karşılaştırmak için hızlı komut:

docker exec -it my_container date -u

Ana makinedeki date -u ile eşleşiyorsa - her şey yolunda, sorunu başka yerde arayın. Konteyner bir şekilde farklı bir mutlak zaman gösteriyorsa, bu standart dışı, potansiyel olarak tehlikeli bir yapılandırmanın işaretidir ve derhal gözden geçirilmelidir.

Tipik hatalar: yapılmaması gerekenler

Olay inceleme deneyimi tekrar tekrar basılan tırmıkların listesini oluşturur. Baştan savmak için üzerinden geçelim.

Birinci hata: refleks olarak proxy'yi suçlamak

Bununla başladık ve tekrarlayalım. Proxy üzerinden çalışırken hatada certificate veya signature kelimesi otomatik olarak ağdan ve ağ geçidinden şüphelenmeye yol açar. Karşı koymayın. Bu hatalarda ilk iş, uç noktayı değiştirmek değil, saati karşılaştırmaktır. Bu on saniye sürer ve en sık görülen gizli sebebi eler.

İkinci hata: zaman yerine saat dilimini düzeltmek

Mühendis loglarda garip yerel saat görür ve saat dilimini değiştirir. Loglardaki semptom değişir ama kriptografi düştüğü gibi düşmeye devam eder, çünkü UTC'deki gerçek mutlak zaman bozuk kalır. Her zaman date -u ve referansla karşılaştırma ile teşhis edin, yerel gösterimle değil.

Üçüncü hata: senkronizasyon kurulumunu çözüm sanmak

Paketi kurdunuz, servisi çalışır gördünüz, işi kapattınız. Bir hafta sonra yine arızalar, çünkü servisin zaman sunucularına erişimi yoktu. Kurulum senkronizasyona eşit değildir. Her zaman gerçek sapmayı ve seçili kaynağın varlığını kontrol edin.

Dördüncü hata: çalışırken saati sertçe düzeltmek

Doğrudan ayarlama komutuyla sistem saatinde ani sıçrama, zaman monotonluğuna güvenen çalışan süreçleri bozabilir: zaman aşımları biter, oturumlar kopar, zamanlayıcı yanlış tetiklenmeleri olur. Doğrusu, senkronizasyon arka plan programının saati yumuşakça hizalamasına izin vermektir. Sert düzeltme yalnızca çok büyük tek seferlik kaymada, o da bilinçli olarak kabul edilebilir.

Beşinci hata: sanal makinelerin dondurulmasını görmezden gelmek

Ekip, geçişlerin, anlık görüntülerin ve duraklatmaların tek seferlik kaymalar yarattığını hesaba katmaz. Bu tür ortamlar için sıçramalara dayanıklı bir arka plan programı ve bakım işlemlerinden sonra kayma izlemesi gerekir. Arızalarınız yedeklemeler veya geçişlerle zaman içinde korele ise - işte çözümünüz.

Altıncı hata: çift zaman yönetimi

Aynı anda hipervizörün konuk ajanı ve iç arka plan programı çalışıyor. Saat çekiliyor, arızalar aralıklı ve tekrarlanamaz. Bir mekanizma seçin ve ikincisini kapatın. Bu, en yıpratıcı değişken hataları tedavi eder.

Yedinci hata: marjsız çok dar pencereler

İstek imzalı bir API geliştiriyorsanız, geçerli bir neden olmadan otuz saniyelik tolerans penceresi yapmayın. Birkaç dakikalık makul bir marj, tekrara karşı korumadan ödün vermeden istemcilerin küçük senkronizasyon bozukluklarına olan hassasiyetini keskin bir şekilde azaltır. Katılık ile dayanıklılık arasındaki denge bir mühendislik kararıdır, dogma değil.

Araçlar ve kaynaklar

El altında tutmaya değer cephaneliği toplayalım. Tüm araçlar standart ve yasaldır, normal mühendislik operasyonu için.

Komut satırı

  • date -u - mutlak zamana anlık bakış. Herhangi bir şüphede ilk komut.
  • timedatectl - systemd'li sistemlerde senkronizasyon ve saat dilimi durumu.
  • chronyc tracking ve chronyc sources - chrony'nin derin teşhisi: kayma, kaynaklar, kararlılık.
  • curl -sI ... | grep -i date - yanıtın HTTP başlığıyla zaman karşılaştırması, arka plan programlarının olmadığı yerlerde bile çalışır. Çıplak konteynerler ve ağ geçidi üzerinden kontrol için ideal.

Dil kontrolleri

  • Python'da: uygulamanın çalışma ortamından doğrudan karşılaştırma için utcnow ve zaman damgası çıktısı veren tek satır.
  • Node'da: tam olarak sizin çalışma zamanınızın gözüyle zamanı görmek için toISOString ve Date.now içeren tek satır.
  • JWT'yi imza doğrulaması olmadan çözmek, exp, nbf, iat alanlarını kendi gözünüzle görmek ve geçerli zamanla karşılaştırmak. Bu tahminleri ortadan kaldırır: token'ın sizin saatinize göre dolup dolmadığını tam anlamıyla görürsünüz.

Sürekli izlenecekler

  • Sistem saati kayması uyarı ve alarm eşikleriyle sayısal metrik olarak.
  • Seçili zaman kaynağının varlık durumu - senkronizasyon sağlığının boolean göstergesi.
  • TLS ve token hata sıklığı düğüm bazında - belirli bir düğümdeki ani artış genellikle onun bozuk saatine işaret eder.

Proxeon altyapısı

Proxeon ağ geçitleri üzerinden çalışırken, iş düğümlerinizin başlangıç betiğine zaman kontrolü yerleştirmenizi öneririz. Başlangıçta ağ geçidi üzerinden Date başlığının tek satır karşılaştırması - ve ilk iş isteğinden önce senkronizasyon bozukluğunu yakalarsınız. Bu ucuzdur ve kökün proxy'de değil istemci tarafında saatte olduğu yanlış destek başvurularının payını radikal biçimde azaltır.

Vakalar ve sonuçlar

Teori gerçek hikâyelerde canlanır. Pratikten genelleştirilmiş vakalar verelim - sayılar yuvarlanmış, detaylar anonimleştirilmiş, ama desenler tamamen gerçek.

Birinci vaka: yedeklemeden sonra gece parser çöküşü

Ekip proxy üzerinden günün her saati veri topluyordu. Her gece saat üç civarında certificate is not yet valid hata duvarı başlıyor, sabaha doğru kendiliğinden düzeliyordu. Mühendisler iki hafta proxy havuzunu suçladı, uç noktaları değiştirdi, şikayetler yazdı. Çözüm, birinin korelasyonu fark etmesiyle geldi: arızalar tam olarak gece sanal makine yedeklemesi sırasında başlıyordu.

Hipervizör tutarlı anlık görüntü almak için VM'yi bir buçuk-iki dakika donduruyordu. Çözülmeden sonra saat bu dakikalar kadar geri kalıyordu ve konuk ajan onları hemen hizalamıyordu. Çözülme ile düzeltme arasındaki pencerede TLS taze sertifikaları henüz geçerli değil diye reddediyordu - çünkü geri kalan saate göre gelecekte başlıyorlardı. Çözüm, sıçramadan sonra hızlı yakınsayan chrony'ye geçiş ve yedekleme işlemlerinden hemen sonra kayma izlemesi oldu. Gece arızaları tamamen kayboldu, benzer gelecek sorunların teşhis süresi günlerden dakikalara düştü.

İkinci vaka: birbirinden ayrılan yüz düğüm

Kuruluş yüz iş düğümünden oluşan bir parkı tek imajdan dağıttı. İlk hafta her şey çalıştı. Sonra rastgele düğümlerde değişken istek imzası arızaları başladı - request timestamp too skewed. Tekrarlanamaz: görevi yeniden başlatırsınız, başka bir düğümde geçebilir.

Sebep - imajda zaman senkronizasyonu etkinleştirilmemişti. Yüz düğüm her biri kendi kuvarsıyla kayıyordu. En hızlıları bir haftada imzadaki tolerans penceresini aştı. Tüm parkta toplu chronyc tracking kontrolü saniyenin kesirlerinden on beş saniyeye kadar sapmalar gösterdi. Tüm düğümlerde senkronizasyonu açıp gerçekten çalıştığını doğruladıktan sonra, artı izlemeye kayma metriği ekledikten sonra arızalar durdu. Ekibin çıkarımı: toplu dağıtımda kurulum gerçeğini değil senkronizasyon gerçeğini doğrulayın.

Üçüncü vaka: kimsenin anlamadığı geliştirici

Bir mühendis, yönetim paneline TOTP ile yerel olarak yetkilendirmenin geçmediğinden şikayet ediyordu, oysa herkeste çalışıyordu. Doğru kodu giriyor, sistem reddediyordu. Hesabıyla ilgili sorun olduğundan şüphelenildi.

Bir hafta önce başka bir uygulamayı test etmek için iş istasyonunda sistem saatini elle kaydırdığı ve geri almayı unuttuğu, senkronizasyonu da kapattığı ortaya çıktı. Saat neredeyse bir dakika kaymıştı. Otuz saniyelik pencereli TOTP eşleşmemeye başladı. Otomatik senkronizasyonu açmak her şeyi anında düzeltti. Ahlaki ders: TOTP'nin dar toleransı yerleşik bir senkronizasyon bozukluğu dedektörüdür. Kodlar eşleşmiyorsa, ilk iş saate bakın.

Dördüncü vaka: yabancı saat dilimli konteyner

Konteynerdeki uygulama loglarında zaman ana makineye göre üç saatlik kaymayla gidiyordu. Mühendisler konteynerin saatinin bozuk olduğuna karar verdi ve içinde senkronizasyon ayarlamaya bir gün harcadı, neredeyse konteynere fazladan ayrıcalıklar veriyorlardı.

İçeride ve dışarıda date -u kontrolü aynı mutlak zamanı gösterdi. Kayma sadece gösterimdeydi: temel imaj bir saat dilimine, ana makine başkasına sahipti. Kriptografi kusursuz çalışıyordu, çünkü UTC'de her şey eşleşiyordu. Aslında gerçek bir sorun yoktu - sadece loglarda kozmetik karışıklık. Ders bir günlük işe mal oldu: her zaman mutlak zamanı ve gösterimini ayırt edin.

SSS: sık sorulan sorulara derin cevaplar

Proxy bana zamanı kendisi bozabilir veya TLS'te ikame edebilir mi?

Ağ geçidi üzerinden çalışmanın normal senaryolarında - hayır. Proxy sizinle hedef sunucu arasında baytları iletir. Sertifika süresi, exp ve nbf alanları, imza penceresi kontrolü sizin tarafınızda veya son sunucu tarafında, onların kendi saatlerine dayanarak gerçekleşir. Bu yüzden zamana benzeyen hatalarda önce iş düğümünün yerel saatinden şüphelenmek gerekir, ağ geçidinden değil. Proxy sadece zinciri uzatır ve psikolojik olarak şüpheyi ortaya kaydırır.

Her şeyin çalışması için saat ne kadar doğru gitmelidir?

TLS için marj genellikle büyüktür - oradaki sertifika geçerlilik pencereleri gün cinsinden ölçülür ve dakikalık kayma bile genellikle güncelleme sınırının hemen dışında fark edilmez. JWT için her şey token ömrüne bağlıdır: kısa token'larda saniyeler bile rol oynar. İstek imzaları için tipik pencere dakikalardır, ama kaymayı saniye içinde tutmak daha iyidir. TOTP en talepkâr olanıdır - onlarca saniye. Evrensel öneri: kaymayı bir saniye içinde tutun, o zaman listelenen tüm mekanizmalardan aynı anda korunursunuz.

Sertifika geçerli tarihleri gösteriyor ama istemci henüz geçerli değil diyorsa neden?

Çünkü istemci sertifika tarihlerini mutlak gerçekle değil, sizin yerel saatinizle karşılaştırır. Saatiniz geri kalıp notBefore alanından önceki bir anı gösteriyorsa, istemci için sertifika henüz gelmemiştir. Sertifikanın kendisindeki tarihler kusursuzdur. Çözüm her zaman date -u değerinizi referansla karşılaştırmaktır. Bu, mühendislerde en sık şaşkınlık kaynağıdır.

Konteyner içine senkronizasyon arka plan programı kurmak gerekli mi?

Hayır. Konteyner ana makinenin çekirdek saatini kullanır, dolayısıyla senkronize edilmesi gereken ana makinedir. Konteyner içine arka plan programı kurmak yararsızdır ve tüm ana makineyi etkileyen sistem saatini değiştirmek için tehlikeli ayrıcalıklar gerektirir. Doğru model - senkronize bir ana makine ve otomatik olarak doğru saati gören birçok konteyner. Orkestratörde senkronizasyon her düğüm-ana makinede sağlanır.

Zaman sorununu gerçek proxy veya ağ sorunundan nasıl ayırt ederim?

Zaman kontrolüyle başlayın - bu on saniye. date -u'yu referansla ve ağ geçidiniz üzerinden HTTP Date başlığıyla karşılaştırın. Kayma küçükse ve TLS ve token hataları devam ediyorsa - o zaman ağ teşhisine geçin. Kayma büyükse - sebebi buldunuz. Zaman sorunlarının kilit işareti: canlı sertifikalar ve taze token'larla bile hataların not yet valid, expired, skewed, signature kelimelerini içermesi.

Sanal makine çözüldükten veya geçişten hemen sonra ne yapmalı?

Senkronizasyon arka plan programının saati hızlıca hizalandığından emin olun. Dondurmalı ortamlar için sıçramalardan iyi çıkan chrony tercih edilir. chronyc tracking kontrol edin ve System time'ın saniyenin kesirlerine döndüğünden emin olun. İyi bir uygulama - bakım işlemlerinden sonra kayma kontrolünü zorla başlatmak ve saat hizalanana kadar kritik imzalı istekleri başlatmamak.

Yanlış saat dilimi TLS ve token'ların çalışmasını etkiler mi?

Hayır, UTC'de mutlak zaman doğru olduğu sürece. Tüm kriptografi UTC ile çalışır ve saat dilimi sadece insan için gösterimdir. Yanlış saat dilimi loglarda kafanızı karıştırır, ama TLS, JWT veya imzayı düşürmez. Bu yüzden teşhis yerel zamanla değil UTC ile yapılmalıdır. Saat dilimi ve mutlak zaman karışıklığı klasik bir tuzaktır.

Proxy üzerinden iş akışına zaman kontrolü nasıl yerleştirilir?

Düğüm başlangıç betiğine tek satır karşılaştırma ekleyin: Proxeon ağ geçidiniz üzerinden Date başlığını isteyin ve yerel date -u ile karşılaştırın. Eşiğin üzerinde sapma varsa başlatmayı durdurun ve alarm yükseltin. Artı sistem saati kaymasını eşiklerle kalıcı bir metrik olarak izlemeye çıkarın. Bu iki önlem, zaman olaylarının büyük çoğunluğunu TLS ve token arızalarına dönüşmeden önce yakalar.

Neden ben

Yazar Hakkında

Andrey Kokh

Andrey Kokh

Leading Expert and Business Consultant

İş Deneyimi: Leading expert with 12 years of experience. Consults Forbes-listed companies, author of 3 books. Teaches at HSE and SKOLKOVO. His methodologies are used by hundreds of companies across Russia. RBC and Forbes expert on strategic development and digital transformation.
Eğitim: Higher School of Economics. Faculty of Economics, Master's Program
Uzmanlık:
Strategic Consulting Digital Transformation Change Management Business Strategy Innovation Management Organizational Development Lean Management Agile Transformation

Makaleyi paylaşın: