Sinkronisasi Waktu

Setiap malam pukul dua dini hari, systemd timer di server backup menjalankan script rsync menuju server DNS internal yang kita bangun di Bab 9. Suatu pagi, Sysadmin mendapati folder backup penuh salinan ganda untuk tanggal yang sama, sementara arsip hari sebelumnya malah hilang tanpa jejak. Setelah ditelusuri, penyebabnya ternyata sepele: jam sistem server backup tertinggal delapan jam dari server DNS karena tidak pernah disinkronkan sejak awal instalasi. Akibatnya, script yang seharusnya berjalan sekali sehari malah terpicu berkali-kali dan saling menimpa arsip pada tanggal yang keliru. Masalah seperti ini biasanya baru ketahuan saat backup yang dibutuhkan justru tidak ada, tepat ketika data production benar-benar hilang. Akar masalahnya nyaris selalu sama: server yang tidak pernah dijaga akurasi waktunya.

Bab ini membahas cara menjaga akurasi waktu di server Linux menggunakan chrony, mulai dari alasan topik ini penting meski sering luput dari perhatian, verifikasi status chrony sebagai layanan NTP default di Ubuntu Server, konfigurasi satu server internal sebagai sumber waktu bagi server lain di jaringan yang sama, hingga cara memverifikasi hasil sinkronisasi melalui chronyc tracking.

11.1 Mengapa Waktu Akurat Penting di Server

Setiap komputer memiliki hardware clock yang berjalan menggunakan osilator kristal internal. Komponen ini tidak pernah benar-benar presisi, sehingga jam sistem cenderung melenceng sedikit demi sedikit dari waktu sebenarnya, yaitu fenomena yang dikenal sebagai clock drift. Pada mesin fisik, pergeserannya biasanya kecil dan lambat. Namun, pada virtual machine, drift ini cenderung lebih parah karena virtual clock bergantung pada penjadwalan hypervisor, yang dapat menunda atau menjeda eksekusi vCPU tanpa sepengetahuan sistem operasi tamu. Di lapangan, VM yang baru saja di-restore dari snapshot lama merupakan salah satu penyebab paling umum jam sistem tiba-tiba meleset jauh.

Tanpa mekanisme koreksi, drift ini terus terakumulasi dan berdampak nyata pada operasional server:

• Validasi sertifikat TLS: browser atau aplikasi client mana pun akan menolak sertifikat HTTPS yang tanggal Not Before atau Not After-nya tidak masuk akal dibandingkan jam sistem, meskipun sertifikat itu sendiri sebenarnya masih sah. Topik ini akan kita bahas lebih lanjut saat menyiapkan Let's Encrypt di Bab 17.
• Korelasi log lintas server: seperti pada skenario pembuka, investigasi insiden keamanan sangat bergantung pada urutan waktu kejadian yang konsisten di semua server. Bab 39 nanti akan membahas log terpusat, dan pekerjaan tersebut tidak banyak berguna jika timestamp masing-masing sumbernya tidak sinkron.
• Protokol autentikasi berbasis waktu: Kerberos, salah satu metode autentikasi terpusat yang disinggung di Bab 4, menolak permintaan autentikasi jika selisih jam antara client dan server melampaui ambang toleransi tertentu (umumnya sekitar 5 menit) sebagai perlindungan terhadap serangan replay.
• Keandalan layanan yang sudah kita bangun: masa berlaku (lease) DHCP di Bab 10 dan Time To Live (TTL) cache DNS di Bab 9 sama-sama dihitung berdasarkan jam sistem. Jam yang salah membuat kedua mekanisme tersebut berperilaku tidak sesuai dengan rencana, misalnya lease dianggap kedaluwarsa padahal belum, atau sebaliknya.
• Penjadwalan otomatis: systemd timer dari Bab 5 dan script backup terjadwal di bab-bab selanjutnya bergantung penuh pada jam sistem yang akurat agar tugasnya berjalan tepat waktu.

Solusi standar industri untuk masalah ini adalah NTP (Network Time Protocol), yaitu protokol yang memungkinkan sebuah komputer menyelaraskan jam sistemnya dengan sumber waktu yang lebih akurat melalui jaringan. Sebelum masuk ke konfigurasi, mari kita lihat kondisi jam server saat ini terlebih dahulu.

date
timedatectl status

Perhatikan baris System clock synchronized dan NTP service pada output timedatectl status. Kedua baris tersebut menjadi indikator singkat mengenai status sinkronisasi server sebelum kita masuk lebih jauh ke chrony sebagai implementasi NTP yang digunakan oleh Ubuntu Server.

11.2 Chrony sebagai Default NTP Client di Ubuntu Server

chrony adalah implementasi NTP yang terdiri dari dua komponen utama: chronyd, yaitu daemon yang berjalan di latar belakang untuk terus-menerus menyesuaikan jam sistem, dan chronyc, yaitu command-line interface untuk memeriksa status serta mengatur chronyd. Menurut dokumentasi resmi Ubuntu Server, chrony terpasang secara default untuk sinkronisasi waktu otomatis sejak Ubuntu 25.10, dan status tersebut tetap dipertahankan pada Ubuntu Server 26.04 LTS yang menjadi acuan course ini. Langkah ini menggantikan kombinasi lama ntpd atau systemd-timesyncd yang masih sering muncul di tutorial-tutorial lama, karena chrony terbukti lebih cepat mencapai sinkronisasi dan lebih akurat dalam menangani jaringan yang koneksinya tidak stabil. Kedua karakteristik tersebut sangat penting untuk server produksi.

11.2.1 Verifikasi Instalasi dan Status Layanan Chrony

Karena chrony sudah terpasang secara default, langkah pertama kita bukanlah instalasi, melainkan verifikasi bahwa layanannya benar-benar berjalan.

Langkah Praktik

1. Pastikan package chrony memang terpasang.

   dpkg -l chrony

   Jika ternyata belum terpasang, misalnya karena instalasi minimal yang menghapusnya, pasang paket tersebut secara manual.

   sudo apt update
   sudo apt install chrony

2. Periksa status chronyd melalui service systemd-nya.

   systemctl status chrony.service

3. Konfirmasi ulang melalui timedatectl bahwa sistem mengenali chrony sebagai penyedia sinkronisasi NTP yang aktif.

   timedatectl status

Verifikasi dan Troubleshooting

• Output timedatectl status idealnya menampilkan System clock synchronized: yes dan NTP service: active. Jika salah satu masih bernilai no atau inactive, aktifkan chrony secara eksplisit.

  sudo systemctl enable --now chrony.service

• Jika timedatectl justru menunjukkan systemd-timesyncd sebagai penyedia NTP aktif, hal itu menandakan kedua layanan sedang berebut kendali atas jam sistem. Nonaktifkan systemd-timesyncd agar tidak bentrok dengan chrony.

  sudo systemctl disable --now systemd-timesyncd.service

11.2.2 Struktur Konfigurasi dan Network Time Security (NTS)

Konfigurasi utama chrony berada di /etc/chrony/chrony.conf. Sejak beberapa rilis terakhir, Ubuntu memisahkan daftar sumber waktu (NTP source) ke direktori tersendiri di /etc/chrony/sources.d/, alih-alih ditulis langsung di chrony.conf. File bawaannya adalah /etc/chrony/sources.d/ubuntu-ntp-pools.sources, yang berisi:

pool 1.ntp.ubuntu.com iburst maxsources 1 nts prefer
pool 2.ntp.ubuntu.com iburst maxsources 1 nts prefer
pool 3.ntp.ubuntu.com iburst maxsources 1 nts prefer
pool 4.ntp.ubuntu.com iburst maxsources 1 nts prefer
pool ntp-bootstrap.ubuntu.com iburst maxsources 1 nts certset 1

Perhatikan flag nts pada setiap baris. Sejak Ubuntu mengaktifkan NTS (Network Time Security) secara default, seluruh komunikasi ke pool NTP Ubuntu terenkripsi dan terautentikasi menggunakan TLS, bukan sekadar paket UDP polos seperti NTP klasik. Hal ini penting dari sisi keamanan karena NTP tradisional rentan terhadap spoofing. Attacker pada jaringan yang sama dapat memalsukan balasan NTP untuk menggeser jam target ke waktu yang salah, misalnya untuk membuat sertifikat TLS yang sudah kedaluwarsa tampak masih valid. NTS menutup celah tersebut melalui proses negosiasi kunci lewat port 4460/TCP, sedangkan pertukaran data waktu itu sendiri tetap berjalan pada port 123/UDP seperti NTP pada umumnya. Flag prefer menandakan chronyd mengutamakan sumber tersebut ketika beberapa sumber sama-sama dapat dihubungi.

Verifikasi dan Troubleshooting

• Lihat daftar sumber waktu yang sedang digunakan oleh chronyd beserta status seleksinya.

  chronyc -N sources

  Simbol ^* di kolom paling kiri menandai sumber yang saat ini dipilih sebagai referensi utama, sedangkan ^+ menandai sumber kandidat yang layak tetapi belum dipilih.
• Pastikan negosiasi NTS berhasil dengan memeriksa data autentikasi setiap sumber.

  sudo chronyc -N authdata

  Sumber yang berhasil menunjukkan Mode: NTS dengan nilai KeyID dan KLen yang tidak nol. Jika nilainya tetap nol setelah beberapa menit, kemungkinan terdapat firewall di jaringan kita yang memblokir port 4460/TCP untuk negosiasi kunci NTS.

11.3 Mengonfigurasi Server sebagai NTP Source Internal

Setiap server yang melakukan query secara langsung ke pool NTP publik satu per satu memang tetap dapat berfungsi, tetapi hal itu kurang ideal untuk jaringan internal yang sudah memiliki beberapa server, seperti server DNS dari Bab 9 dan server DHCP dari Bab 10 yang telah kita bangun. Idealnya, cukup satu server internal yang menyinkronkan diri ke pool publik, kemudian server serta perangkat lain di jaringan yang sama menyinkronkan diri ke server internal tersebut. Pendekatan ini memiliki beberapa keuntungan nyata: latensi ke sumber waktu menjadi jauh lebih kecil karena berada di jaringan lokal, jumlah request ke internet berkurang drastis, dan hal yang tidak kalah penting adalah server internal tetap dapat memberikan waktu yang konsisten ke seluruh jaringan lokal meskipun koneksi internet sedang bermasalah.

Pada praktik ini, kita akan menjadikan server yang sama dengan server DNS internal di Bab 9 (IP 192.168.1.10) sebagai sumber NTP internal untuk jaringan 192.168.1.0/24, sekaligus menjaga konsistensi dengan skema jaringan yang sudah digunakan sejak Bab 9 dan Bab 10.

11.3.1 Mengizinkan Akses Client dengan Directive allow

Secara default, chronyd menolak seluruh permintaan NTP dari luar, meskipun sudah berjalan sebagai client yang tersinkron. Agar server ini dapat melayani permintaan waktu dari perangkat lain, kita memerlukan directive allow yang secara eksplisit menentukan subnet mana yang diizinkan.

Langkah Praktik

1. Edit /etc/chrony/chrony.conf pada server yang akan berperan sebagai sumber NTP internal.

   sudo nano /etc/chrony/chrony.conf

2. Tambahkan directive allow berikut di bagian akhir file.

   allow 192.168.1.0/24

3. Tambahkan juga directive local stratum 10 jika kita menghendaki server ini tetap dapat melayani waktu ke jaringan lokal walau koneksi ke pool internet sedang terputus. Directive ini membuat chronyd "berpura-pura" tersinkron dari sudut pandang client yang meminta waktu ke sana, meskipun sumber upstream-nya sendiri sedang tidak tersedia.

   local stratum 10

   Perlu digarisbawahi bahwa waktu yang dibagikan melalui mode local ini bukanlah waktu yang benar-benar akurat terhadap dunia luar begitu upstream terputus cukup lama, melainkan sekadar menjaga konsistensi waktu antarperangkat di jaringan lokal itu sendiri. Jangan andalkan mode ini sebagai pengganti permanen sumber NTP yang sah; gunakan hanya sebagai jaring pengaman sementara.
4. Karena allow dan local merupakan directive akses dan perilaku server (bukan sekadar daftar sumber waktu di sources.d/), terapkan perubahan dengan melakukan restart penuh, bukan sekadar reload sources.

   sudo systemctl restart chrony.service

   Restart ini menyebabkan jeda yang sangat singkat pada proses sinkronisasi chronyd itu sendiri. Dampaknya biasanya tidak terasa, tetapi sebaiknya tetap dilakukan di luar jam sibuk untuk server produksi.
5. Buka akses port NTP di UFW dan batasi hanya untuk subnet internal yang relevan agar server ini tidak melayani permintaan NTP dari internet secara sembarangan.

   sudo ufw allow from 192.168.1.0/24 to any port 123 proto udp

Verifikasi dan Troubleshooting

• Setelah beberapa client mulai menyinkronkan diri ke server ini (lihat Bagian 11.3.2), periksa daftar client yang pernah meminta waktu ke server internal ini.

  chronyc clients

• Jika client tetap tidak dapat mengakses server ini, penyebab paling umum adalah subnet pada directive allow tidak sesuai dengan subnet client yang sebenarnya, atau port 123/UDP belum terbuka di UFW seperti pada langkah terakhir di atas.

11.3.2 Mengarahkan Client ke NTP Server Internal

Server internal telah siap melayani permintaan waktu. Langkah selanjutnya adalah mengarahkan server-server lain di jaringan yang sama agar menyinkronkan diri ke server ini, bukan langsung ke pool publik.

Langkah Praktik

1. Pada setiap server client, buat file sumber waktu baru di direktori sources.d/ alih-alih mengedit langsung ubuntu-ntp-pools.sources bawaan.

   sudo nano /etc/chrony/sources.d/internal-ntp.sources

2. Isi file tersebut dengan directive server yang menunjuk ke IP server NTP internal, lengkap dengan flag iburst agar proses sinkronisasi awal lebih cepat dan flag prefer agar diutamakan dibandingkan pool publik bawaan.

   server 192.168.1.10 iburst prefer

   Kita sengaja tidak menghapus ubuntu-ntp-pools.sources bawaan agar pool publik tetap tersedia sebagai fallback jika server NTP internal sedang down. Flag prefer sudah cukup membuat chronyd mengutamakan server internal selama server tersebut dapat dijangkau.
3. Terapkan sumber waktu baru ini tanpa perlu melakukan restart penuh pada chronyd.

   sudo chronyc reload sources

Verifikasi dan Troubleshooting

• Periksa apakah chronyd di client sudah memilih server internal sebagai sumber utama.

  chronyc -N sources

  Baris dengan alamat 192.168.1.10 seharusnya bertanda ^* di kolom paling kiri, yang menandakan bahwa server itulah yang sedang aktif digunakan sebagai referensi.
• Jika server internal belum terpilih meskipun sudah tercantum di daftar sumber, tunggu beberapa menit karena chronyd membutuhkan beberapa siklus polling untuk menilai kualitas suatu sumber sebelum memutuskan untuk menggunakannya, bahkan dengan flag prefer sekalipun.

11.4 Verifikasi Sinkronisasi dengan chronyc tracking

Setelah konfigurasi server maupun client selesai, chronyc tracking adalah perintah paling penting untuk memastikan sinkronisasi benar-benar berjalan sesuai harapan, bukan sekadar service yang aktif di systemd tanpa hasil nyata.

Langkah Praktik

1. Jalankan perintah berikut, baik di server NTP internal maupun di client-nya.

   chronyc -N tracking

   Output-nya kurang lebih seperti berikut.

   Reference ID    : B97DBE7B (2.ntp.ubuntu.com)
   Stratum         : 3
   Ref time (UTC)  : Mon Jun 16 13:06:04 2025
   System time     : 0.000000004 seconds slow of NTP time
   Last offset     : +0.001758954 seconds
   RMS offset      : 0.017604901 seconds
   Frequency       : 3.889 ppm slow
   Residual freq   : +0.202 ppm
   Skew            : 1.458 ppm
   Root delay      : 0.022837413 seconds
   Root dispersion : 0.003050051 seconds
   Update interval : 1032.5 seconds
   Leap status     : Normal

Beberapa baris berikut adalah yang paling sering kita perhatikan saat melakukan verifikasi maupun troubleshooting:

• Reference ID: identitas sumber waktu yang sedang digunakan. Pada server internal kita, nilai ini seharusnya menunjuk ke salah satu pool Ubuntu, sedangkan pada client, nilai ini seharusnya menunjuk ke IP server NTP internal yang baru saja kita konfigurasi.
• Stratum: jarak sumber waktu dari reference clock fisik (jam atom atau GPS yang berada di stratum 0). Server yang terhubung secara langsung ke stratum 0 disebut stratum 1. Client yang menyinkronkan diri ke server internal kita secara otomatis berada satu stratum lebih tinggi dari server itu sendiri, misalnya stratum 4 jika server internal berada di stratum 3.
• System time: selisih jam sistem terhadap waktu NTP yang sebenarnya saat ini, yang dilaporkan dalam hitungan detik. Semakin mendekati nol, waktunya akan semakin akurat.
• Root delay dan Root dispersion: total keterlambatan jaringan dan total ketidakpastian yang terakumulasi dari seluruh hop hingga ke stratum 0. Nilai yang kecil menandakan jalur ke sumber waktu cukup singkat dan stabil.
• Leap status: idealnya bernilai Normal. Nilai Not synchronized berarti chronyd belum berhasil menyinkronkan diri ke sumber mana pun, yang merupakan tanda paling jelas bahwa ada hal yang perlu ditelusuri lebih lanjut.

Verifikasi dan Troubleshooting

• Untuk melihat kualitas dan riwayat keterjangkauan setiap sumber secara lebih terperinci, gunakan perintah berikut.

  chronyc sourcestats

• Perhatikan kolom Reach pada output chronyc -N sources, yang ditulis dalam basis oktal. Nilai 377 berarti 8 dari 8 polling memang berhasil dijawab oleh sumber tersebut, sementara nilai yang jauh lebih kecil menandakan sumber itu sering tidak merespons, entah karena masalah jaringan atau server tujuan yang sedang bermasalah.
• Jika Leap status terus-menerus menunjukkan Not synchronized pada client, urutan pengecekan yang paling efisien adalah: pastikan server internal sendiri sudah Normal terlebih dahulu, periksa directive allow di server sudah mencakup subnet client, lalu pastikan port 123/UDP tidak terblokir di kedua sisi.
• Satu catatan penting untuk lingkungan container yang akan kita bahas di Bab 26 dan 27: container Docker berbagi kernel clock yang sama dengan host, sehingga tidak perlu (dan tidak lazim) menjalankan chronyd terpisah di dalam setiap container. Cukup pastikan host tempat container tersebut berjalan sudah tersinkron dengan baik.

Sampai di sini, kita telah memahami alasan akurasi waktu bukan sekadar detail kosmetik di server, melainkan fondasi bagi TLS, autentikasi, log, dan layanan-layanan yang sudah kita bangun di bab-bab sebelumnya. Kita juga telah mempraktikkan verifikasi chrony sebagai NTP client bawaan Ubuntu Server, membangun satu server internal sebagai sumber waktu bagi jaringan lokal, hingga membaca output chronyc tracking untuk memastikan semuanya benar-benar tersinkron. Bab 12 akan beralih ke topik baru yang menjadi fondasi Bagian IV, yaitu menyiapkan web server pertama kita dengan Nginx.