Debian NTP入門：時刻同期の設定方法を解説

By /

はい、承知いたしました。DebianにおけるNTP（時刻同期）の設定方法について、詳細な解説を含む記事を作成します。約5000語を目指し、初心者の方にも理解しやすいよう、NTPの基礎から応用、トラブルシューティングまで網羅します。

Debian NTP入門：時刻同期の設定方法を解説

はじめに：なぜサーバーの時刻同期は重要なのか？

現代のコンピュータシステム、特にサーバーにおいては、正確な時刻を維持することが極めて重要です。なぜなら、システム内で発生するあらゆる活動は、そのタイムスタンプによって記録され、追跡されるからです。時刻がずれていると、以下のような様々な問題が発生する可能性があります。

  1. ログの整合性: 複数のサーバーで構成されるシステム（データベースサーバー、ウェブサーバー、アプリケーションサーバーなど）において、それぞれのサーバーのログの時刻がずれていると、障害発生時やセキュリティインシデント発生時に、イベントの発生順序を正確に追跡することが困難になります。問題の原因特定や影響範囲の調査が著しく遅れる可能性があります。
  2. 分散システムにおける整合性: 分散データベース、ファイルシステム、クラスタリングソフトウェアなど、複数のノードが協調して動作するシステムでは、ノード間の時刻のずれがデータの不整合やサービスの誤動作を引き起こす可能性があります。
  3. 認証とセキュリティ: Kerberosのような認証プロトコルや、TLS/SSL証明書の有効期限チェックなど、時刻に依存するセキュリティ機能は、システム時刻が正確でないと正しく機能しません。これにより、通信が確立できない、認証が失敗するといった問題が生じます。
  4. バックアップとリカバリ: バックアップファイルのタイムスタンプがずれていると、正しい時点へのリカバリが困難になったり、差分バックアップが意図せず完全バックアップになったりする可能性があります。
  5. アプリケーションの正常動作: 特定のアプリケーション、特に金融取引システムや科学技術計算システムなど、時刻に厳密な依存関係があるアプリケーションは、時刻のずれによって誤った結果を出力したり、クラッシュしたりする可能性があります。
  6. タスクのスケジューリング: cron などで定期的に実行されるタスクは、システム時刻に基づいて動作します。時刻がずれていると、意図しない時間にタスクが実行されたり、全く実行されなかったりする可能性があります。

このように、正確な時刻同期はサーバー運用の基盤となる要素です。そして、この時刻同期を実現するための標準的なプロトコルが NTP (Network Time Protocol) です。本記事では、Linuxディストリビューションの中でも特に安定性と人気が高いDebianに焦点を当て、NTPを利用した時刻同期の設定方法を詳しく解説します。

NTPの基礎知識

時刻同期の重要性を理解したところで、次にNTPとは具体的にどのようなプロトコルなのかを見ていきましょう。

NTP (Network Time Protocol) とは

NTPは、コンピュータネットワーク上のシステム間で時刻を同期するためのプロトコルです。UDPのポート番号123を使用します。1985年にデラウェア大学のデイヴィッド・ミルズ（David L. Mills）によって設計され、以来、インターネット上の多くのシステムで時刻同期のために利用されています。

NTPは、単にサーバーから時刻情報を受け取るだけでなく、ネットワーク遅延を考慮して高精度な時刻同期を目指します。複数の時刻源から情報を取得し、その中で最も信頼性の高い時刻源を選択し、自身のシステムクロックを微調整しながら同期を維持します。

ストラタム (Stratum) とは

NTPでは、時刻源の階層を「ストラタム」（Stratum）という概念で表します。ストラタムは0から始まり、数値が大きいほど元の時刻源から遠くなります。

  • Stratum 0: 原子時計やGPSクロックのような、非常に正確な時刻源そのものを指します。これらはネットワークに直接接続されるのではなく、通常はStratum 1サーバーに直接接続されます。
  • Stratum 1: Stratum 0の時刻源に直接接続され、その時刻をネットワーク経由で提供するサーバーです。これらはプライマリリファレンスサーバーとも呼ばれます。
  • Stratum 2: Stratum 1サーバーと同期するサーバーです。多くの公開NTPサーバーはStratum 2です。
  • Stratum 3: Stratum 2サーバーと同期するサーバーです。
  • …以下続く: Stratum 15までが有効で、Stratum 16は未同期または同期不可能を示します。

クライアントは通常、より低いストラタムのサーバー（つまり、より正確な時刻源に近いサーバー）と同期しようとします。ストラタムの概念は、信頼性の高い時刻源から枝分かれするように時刻情報が伝播していく様子を表しています。

NTPの仕組み

NTPクライアントとNTPサーバーは、通常、以下のような手順で時刻同期を行います。

  1. クライアントはサーバーに時刻同期要求パケットを送信します。このパケットには、クライアントが送信した時刻 (T1) が含まれます。
  2. サーバーは要求パケットを受信した時刻 (T2) を記録します。
  3. サーバーは応答パケットを作成し、送信する直前の時刻 (T3) を記録します。
  4. サーバーは応答パケットをクライアントに送信します。
  5. クライアントは応答パケットを受信した時刻 (T4) を記録します。

クライアントは、これらの4つのタイムスタンプ (T1, T2, T3, T4) を利用して、以下の2つの値を計算します。

  • オフセット (Offset): クライアントの時刻とサーバーの時刻との差です。((T2 - T1) + (T3 - T4)) / 2 で計算されます。このオフセット分だけクライアントの時刻を進めるか遅らせることで同期を行います。
  • ラウンドトリップ遅延 (Round-trip Delay): 要求パケットがクライアントからサーバーへ行き、応答パケットがサーバーからクライアントへ戻ってくるまでの往復時間です。(T4 - T1) - (T3 - T2) で計算されます。NTPはこの遅延を考慮して、より正確なオフセットを推定します。

NTPクライアントは、複数のNTPサーバーと通信し、それぞれのサーバーから得られたオフセットと遅延の情報を統計的に処理します。最も信頼性が高く、オフセットが少なく、遅延が安定しているサーバーを「選択」し、そのサーバーの時刻に基づいて自身のシステムクロックを調整します。

時刻の調整は、急激に行うとシステムに悪影響を与える可能性があるため、通常はクロックの周波数をわずかに変える（スキューを調整する）ことで、時間をかけてゆっくりと目標時刻に近づけていきます。これを「スムージング」と呼びます。ただし、時刻が大きくずれている場合は、起動時などに一度に時刻を設定する（ステップ同期）こともあります。

その他の時刻同期プロトコル

NTPの他にも時刻同期プロトコルは存在しますが、インターネットやLAN環境での一般的なサーバー時刻同期にはNTPが最も広く利用されています。

  • SNTP (Simple Network Time Protocol): NTPの簡易版で、NTPサーバーから時刻情報を受け取るクライアント機能に特化しています。サーバー機能や高精度なアルゴリズムは持ちません。組み込み機器などでリソースが限られている場合に使用されることがあります。
  • PTP (Precision Time Protocol / IEEE 1588): より高精度な時刻同期を目指すプロトコルです。μs (マイクロ秒) や ns (ナノ秒) オーダーの精度が必要な産業制御システムや金融取引システムなどで使用されます。専用のハードウェアサポートが必要になる場合が多いです。

本記事では、Debianで一般的に利用されるNTP、特にその実装であるデーモンソフトウェアに焦点を当てます。

DebianにおけるNTP設定の変遷と選択肢

Debianでは、システム時刻を同期するための標準的な方法として、いくつかのソフトウェアパッケージが提供されています。歴史的な経緯やsystemdの導入に伴い、推奨される方法や利用可能なソフトウェアが変わってきました。

主な選択肢は以下の通りです。

  1. ntp パッケージ (ntpd):

    • 古くからある伝統的なNTPデーモンです。豊富な機能と高い設定自由度を持ちます。
    • NTPクライアントとしてもNTPサーバーとしても機能します。
    • 設定ファイルは /etc/ntp.conf です。

  2. systemd-timesyncd:

    • systemdの一部として提供される、シンプルで軽量なNTPクライアントです。
    • Debian 9 (Stretch) 以降のsystemdを採用したバージョンで、デフォルトで有効になっていることが多いです。
    • クライアント機能のみで、NTPサーバーとしては機能しません。
    • 設定ファイルは /etc/systemd/timesyncd.conf です。

  3. chrony:

    • 比較的新しいNTPデーモンで、ntpd の代替として開発されました。
    • ntpd よりも高速な同期、ネットワークの中断からの迅速な回復、変動するネットワーク遅延への耐性など、いくつかの点で優れているとされています。
    • 仮想環境や、ネットワーク接続が不安定な環境で特に有利です。
    • NTPクライアントとしてもNTPサーバーとしても機能します。
    • 設定ファイルは /etc/chrony/chrony.conf です。

どのソフトウェアを選択するかは、システムの用途や要件によって異なります。

  • 単に外部のNTPサーバーと時刻を同期したいだけで、サーバー機能は不要: systemd-timesyncd が最もシンプルで管理が容易です。デフォルトで有効になっていることが多いので、設定を変更するだけで済みます。
  • 高精度な時刻同期が必要、ネットワークが不安定、仮想環境で利用、または自身がNTPサーバーとして機能したい: chrony が推奨されます。近年のDebianでは chrony がデフォルトのNTPデーモンとしてインストールされる傾向にあります (ntp パッケージは非推奨化されつつあります)。
  • 古くからのシステムで ntpd を使い慣れている、または ntpd の高度な機能が必要: ntp パッケージを選択することになりますが、新規構築では chrony を検討するのが良いでしょう。

本記事では、最もシンプルでデフォルトで利用可能な systemd-timesyncd と、近年のDebianで推奨され高機能な chrony に焦点を当てて設定方法を解説します。伝統的な ntpd については、簡単に触れるに留めます。

systemd-timesyncd を利用した時刻同期 (クライアント)

systemd-timesyncd は、systemdに組み込まれた軽量なNTPクライアント機能です。Debian 9以降のsystemd環境では、特別な設定なしに外部NTPサーバーと時刻を同期しようとします（ただし、デフォルトのNTPサーバーリストを使用します）。単に外部の標準的なNTPサーバーと同期したいだけであれば、これが最も簡単な方法です。

1. systemd-timesyncd の状態確認

まず、systemd-timesyncd が有効になっているか、そして現在どのような状態にあるかを確認します。timedatectl コマンドを使用します。

bash
timedatectl status

出力例：

Local time: Thu 2023-10-26 10:00:00 UTC
Universal time: Thu 2023-10-26 10:00:00 UTC
RTC time: Thu 2023-10-26 10:00:00
Time zone: UTC (UTC, +0000)
System clock synchronized: no
NTP service: active
RTC in local TZ: no

上記の例では、NTP service: active となっており、systemd-timesyncd は起動していますが、System clock synchronized: no となっており、まだ時刻同期は完了していません。しばらく待つか、設定を確認・変更する必要があります。

もし NTP service: inactive や NTP service: n/a の場合は、systemd-timesyncd がインストールされていないか、無効化されています。有効化するには以下のコマンドを実行します。

bash
sudo systemctl enable systemd-timesyncd
sudo systemctl start systemd-timesyncd

2. NTPサーバーの設定

systemd-timesyncd はデフォルトでいくつかのNTPサーバーを使用しようとしますが、明示的に指定することもできます。設定ファイルは /etc/systemd/timesyncd.conf です。このファイルはデフォルトではコメントアウトされた状態になっています。

編集にはroot権限が必要です。

bash
sudo nano /etc/systemd/timesyncd.conf

ファイルを開き、[Time] セクションにある NTP= の行を探します。デフォルトではコメントアウトされているはずです (#NTP=)。コメントを外し、使用したいNTPサーバーのIPアドレスまたはホスト名を設定します。複数のサーバーを指定する場合は、スペースで区切ります。

例：日本のNTPサーバーを指定する場合
“`ini
[Time]

NTP=

FallbackNTP=ntp.pool.org

NTP=ntp.jst.mfeed.ad.jp ntp.nict.jp

FallbackNTP=

RootDistanceMaxSec=5

PollIntervalMinSec=32

PollIntervalMaxSec=2048

“`

日本の一般的な公開NTPサーバーとしては、以下のようなものがあります。
* ntp.jst.mfeed.ad.jp (インターネットマルチフィード)
* ntp.nict.jp (情報通信研究機構)
* pool.ntp.org のアジア/日本ゾーン (asia.pool.ntp.org や jp.pool.ntp.org)

設定を保存してエディタを終了します。

3. 設定の反映と状態確認

設定ファイルを変更したら、systemd-timesyncd サービスを再起動して設定を反映させます。

bash
sudo systemctl restart systemd-timesyncd

再起動後、再び timedatectl status コマンドで状態を確認します。

bash
timedatectl status

しばらく待つと、System clock synchronized: yes と表示されるようになるはずです。

Local time: Thu 2023-10-26 10:05:30 JST
Universal time: Thu 2023-10-26 01:05:30 UTC
RTC time: Thu 2023-10-26 01:05:30
Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
(上記の例ではタイムゾーンもJSTに変更されていますが、これはNTP同期とは直接関係ありません。timedatectl set-timezone Asia/Tokyo などで設定できます。)

timedatectl timesync-status コマンドで、より詳細な同期状態を確認することもできます。

bash
timedatectl timesync-status

出力例：
Server: 210.173.160.27 (ntp.jst.mfeed.ad.jp)
Poll interval: 2min 8s (min: 32s; max: 34min 8s)
Leap: normal
Operational: yes
Packet age: 30s
Offset: -15us
Delay: 2.123ms
Jitter: 0us
Packet count: 2
Tx count: 2

これにより、現在同期しているサーバーや、オフセット、遅延などの情報が表示されます。

systemd-timesyncd の注意点

  • 前述の通り、systemd-timesyncd はNTPクライアント機能のみを提供します。他のマシンに時刻を提供するNTPサーバーとしては機能しません。
  • 高精度な時刻同期（マイクロ秒レベル）には向いていません。一般的なサーバーやデスクトップの時刻同期としては十分な精度ですが、高い精度が求められるシステムでは chrony の利用を検討してください。
  • 時刻が大きくずれている場合でも、systemdの起動時に一度に時刻を設定する「ステップ同期」を行います。その後は周波数調整で同期を維持します。

chrony を利用した時刻同期 (クライアント/サーバー)

chrony は ntpd の代替として設計された、より応答性が高く、多様なネットワーク条件下で優れた性能を発揮するNTPデーモンです。近年のDebianでは推奨されるNTP実装となっています。クライアントとしてもサーバーとしても機能します。

1. chrony のインストール

多くのDebianシステムでは chrony がデフォルトでインストールされていますが、もしインストールされていない場合は以下のコマンドでインストールします。

bash
sudo apt update
sudo apt install chrony

インストールすると、自動的にサービスが起動し、デフォルトの設定ファイルに基づいて動作を開始します。通常、デフォルト設定では公開NTPサーバープールと同期しようとします。

もし ntp パッケージなど、他のNTPデーモンがインストールされている場合は、競合を避けるためにそれらを停止・無効化してから chrony をインストールまたは起動することをお勧めします。

bash
sudo systemctl stop ntp # もしntpが動いていれば
sudo systemctl disable ntp # ntpdを自動起動させない
sudo systemctl status chrony # chronyが動いているか確認

2. chrony の基本的なクライアント設定

chrony の設定ファイルは /etc/chrony/chrony.conf です。root権限で編集します。

bash
sudo nano /etc/chrony/chrony.conf

このファイルには様々な設定ディレクティブがありますが、最も重要なのは同期するNTPサーバーを指定する server または pool ディレクティブです。

デフォルトの設定ファイルには、通常、pool ディレクティブで pool.ntp.org の地域別プールが指定されています。

“`ini

Welcome to the chrony configuration file. See chrony.conf(5) for more information.

This is using servers from the NTP Pool Project. Please consider joining

the pool (http://www.pool.ntp.org/join.html).

pool 0.debian.pool.ntp.org iburst
pool 1.debian.pool.ntp.org iburst
pool 2.debian.pool.ntp.org iburst
pool 3.debian.pool.ntp.org iburst

Use Debian’s own NTP servers

server ntp.debian.org iburst

This directive is used to prevent chronyd from raising the system clock

gain beyond the limits of the kernel, which might cause issues on some

platforms. Uncomment this if you’re observing chronyd setting clock

gain outside of the default +/- 500 PPM.

maxupdateskew 100.0

This directive enables kernel synchronisation (using the adjtimex or

ntp_adjtime syscalls) on Linux. Note that it’s disabled by default.

rtcsync

Save NTS keys and cookies

ntsdumpdir /var/lib/chrony

Specify the keyfile.

keyfile /etc/chrony/chrony.keys

Specify the logging directory.

logdir /var/log/chrony

Select which information is logged.

log measurements statistics tracking rtcclient

The following restrict line gives permission to any clients to query

the chrony instance.

See chrony.conf(5) for details.

allow all

The following directive tells chrony to stop synchronisation if the system

clock is stepped or if it changes by more than 1 second.

makestep 1.0 -1

The following directive specifies that chronyd should be a server

even when it isn’t synchronised to a time source.

local stratum 10

“`

pool ディレクティブは、指定されたプール内の複数のサーバーからランダムに選択して同期を試みる便利な機能です。server ディレクティブは、特定のサーバーを指定する場合に使用します。

例：日本の公開NTPサーバーを指定する場合
既存の pool 行をコメントアウトし、以下の server 行を追加します。

“`ini

Welcome to the chrony configuration file. See chrony.conf(5) for more information.

This is using servers from the NTP Pool Project. Please consider joining

the pool (http://www.pool.ntp.org/join.html).

pool 0.debian.pool.ntp.org iburst

pool 1.debian.pool.ntp.org iburst

pool 2.debian.pool.ntp.org iburst

pool 3.debian.pool.ntp.org iburst

Use specific Japanese NTP servers

server ntp.jst.mfeed.ad.jp iburst
server ntp.nict.jp iburst
pool jp.pool.ntp.org iburst # プールも併用可能

… (その他の設定はデフォルトのままで良いことが多い)

“`

iburst オプションは、chronyd が起動した際に、指定されたサーバーに対して最初の同期試行をより積極的に行うように指示します。これにより、システム起動後の同期が速やかに行われます。

設定を保存したら、chrony サービスを再起動して変更を反映させます。

bash
sudo systemctl restart chrony

3. chrony の状態確認

chrony の状態を確認するには、chronyc コマンドを使用します。

同期ソースの確認 (chronyc sources)

現在 chronyd がどのサーバーと同期しようとしているか、それぞれのサーバーの状態はどうかを確認します。

bash
chronyc sources

出力例：
210 Number of sources = 3
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^+ ntp.jst.mfeed.ad.jp 2 6 37 63 +251us[-261us] +/- 19ms
^? ntp.nict.jp 0 6 0 - +0ns[ +0ns] +/- 4000ms
^* 133.243.238.164 2 6 37 62 -118us[-117us] +/- 24ms

出力の意味：
* MS: ソースの状態を示します。
* ^: サーバー (Server)
* *: 現在同期に使用しているサーバー (Synchronized)
* +: 同期候補として選択されているサーバー (Candidate)
* -: 同期候補から除外されているサーバー (Outlier)
* ?: ネットワークの問題などで到達できないサーバー (Unavailable)
* x: クライアントの時刻がサーバーに対して遠すぎるため除外されている (Falseticker)
* #: 同期候補だが、より高いストラタムのソースが優先されている
* Name/IP address: サーバーのホスト名またはIPアドレス。
* Stratum: サーバーのストラタムレベル。
* Poll: ポーリング間隔の2のべき乗。例えば 6 なら $2^6 = 64$ 秒。
* Reach: 8ビットのシフトレジスタで、直近8回のポーリングの成功/失敗を示します。37 はバイナリで 00100101 となり、最近の成功率が高いことを示します。0 は全く到達できていないことを示します。
* LastRx: 前回の応答を受信してからの時間（秒）。
* Last sample: 前回の同期でのオフセットと推定誤差。+251us[-261us] は、前回の測定でクライアントの時刻がサーバーより約251マイクロ秒進んでおり、クロック源の補正（スミアリング）により-261マイクロ秒の調整が適用されたことを意味します。+/- 19ms は測定の推定誤差です。

* が付いているサーバーが表示されていれば、そのサーバーと同期が確立されています。

同期状態の確認 (chronyc tracking)

現在の同期状態、具体的にはどのサーバーと同期しているか、どのストラタムで同期しているか、オフセットはどのくらいかなどを確認します。

bash
chronyc tracking

出力例：
Reference ID : 82F3EEA4 (ntp.jst.mfeed.ad.jp)
Stratum : 3
Ref time (UTC) : Thu Oct 26 01:10:30 2023
System time : 0.000001000 seconds slow of NTP time
Last offset : +0.000000123 seconds
RMS offset : 0.000004567 seconds
Frequency : 1.234 ppm slow
Residual freq : +0.005 ppm
Skew : 0.010 ppm
Root delay : 0.015678 seconds
Root dispersion : 0.001234 seconds
Update interval : 64.0 seconds
Leap status : Normal

出力の意味：
* Reference ID: 同期しているサーバーのID (通常はIPアドレス) とホスト名。
* Stratum: クライアント自身が同期しているストラタム。同期しているサーバーのストラタムに1を加えた値になります（例：Stratum 2のサーバーと同期していれば、自身はStratum 3となる）。
* Ref time (UTC): 同期しているサーバーの参照時刻 (UTC)。
* System time: システムクロックがNTP時刻に対してどのくらいずれているか。通常は非常に小さい値になります。
* Last offset: 前回の同期で計算されたオフセット。
* RMS offset: オフセットの平均平方根（同期精度の目安）。
* Frequency: システムクロックが基準周波数からどのくらいずれているか（ppm = parts per million）。chronyd はこのずれを学習し、補正します。
* Root delay: Stratum 1サーバーからの合計遅延。
* Root dispersion: Stratum 1サーバーからの合計分散。
* Update interval: 次回のポーリングまでの間隔（秒）。
* Leap status: うるう秒の状態。

これらの情報から、NTP同期が正常に行われているか、どのサーバーと同期しているか、どの程度の精度で同期できているかなどを把握できます。

ステップ同期の実行 (chronyc makestep)

もしシステム時刻がNTPサーバーに対して大きくずれている場合、chronyd はデフォルトでは時間をかけてゆっくりと調整しようとします。しかし、起動時や時刻が大きく狂ってしまった場合などに、一度に時刻を修正したいことがあります。これには makestep ディレクティブを使用しますが、コマンドラインから一時的に実行することも可能です。

bash
sudo chronyc makestep

このコマンドは、設定ファイルで makestep ディレクティブが指定されていない場合に、時刻が大きくずれていれば一度だけステップ同期を実行します。

4. chrony をNTPサーバーとして設定する

chrony を利用して、自身のサーバーをローカルネットワーク内の他のマシンに時刻を提供するNTPサーバーとして機能させることができます。設定ファイル /etc/chrony/chrony.conf を編集します。

他のクライアントからのアクセスを許可するには、allow ディレクティブを使用します。特定のネットワークアドレスまたはアドレス範囲を指定します。

例：192.168.1.0/24 ネットワークからのアクセスを許可する場合
“`ini

… (クライアント設定、例: server ntp.nict.jp iburst など)

Allow access from 192.168.1.0/24 network

allow 192.168.1.0/24

… (その他の設定)

“`

allow ディレクティブがない場合、デフォルトではどのクライアントからのアクセスも許可されません。

設定を保存したら、chrony サービスを再起動します。

bash
sudo systemctl restart chrony

Firewallの設定

NTPサーバーとして機能させるには、FirewallでUDPポート123を開放する必要があります。Debianで一般的なFirewallツールであるufwとiptablesでの設定例を以下に示します。

ufwの場合:

“`bash
sudo ufw allow ntp

またはポート番号で指定

sudo ufw allow 123/udp

sudo ufw reload # 設定を反映
sudo ufw status # 状態を確認
“`

iptablesの場合:

現在のiptablesルールを確認します。
bash
sudo iptables -L -n -v

新しいルールを追加して、外部からのUDP 123ポートへのアクセスを許可します。
“`bash

クライアントからのNTPクエリ (外部からIN) を許可

sudo iptables -A INPUT -p udp –dport 123 -j ACCEPT

自身のサーバーからのNTP応答 (自身からOUT) を許可 (通常はデフォルトで許可されていることが多い)

sudo iptables -A OUTPUT -p udp –sport 123 -j ACCEPT # 必要に応じて

変更を保存 (Debianでは iptables-persistent パッケージを使用することが多い)

sudo apt install iptables-persistent

sudo netfilter-persistent save

“`
iptablesのルールは複雑になる可能性があるため、現在のルールセットを確認し、慎重に変更を適用してください。

5. chrony の応用的な設定

/etc/chrony/chrony.conf には、他にも様々な設定ディレクティブがあります。いくつか有用なものを紹介します。

  • makestep <threshold> <limit>: システムクロックがNTPソースに対して <threshold> 秒以上ずれている場合に、クロック周波数の調整ではなく、一度に時刻を <limit> 回までステップ修正します。例えば makestep 1.0 -1 は、1秒以上ずれていたら回数無制限でステップ修正します。起動時などに時刻が大きくずれている場合に有用です。
  • rtcsync: システムクロックが同期された際に、ハードウェアクロック（RTC – Real-Time Clock）も同期するようにします。これにより、システム停止中も比較的正確な時刻がハードウェアクロックに維持されます。仮想環境では、ホスト側の時刻がRTCとしてゲストに提供される場合があるため、注意が必要です。
  • local stratum <stratum>: 外部のNTPサーバーと同期できない場合に、自身のシステムクロックをリファレンスにしてNTPサーバーとして機能させます。これはオフライン環境や、外部とのNTP同期が不可能な閉じたネットワーク内で、内部のサーバー間で時刻を同期させたい場合に有用です。<stratum> には1以外の値を指定します（例: local stratum 10）。
  • logdir <path>: ログファイルを保存するディレクトリを指定します。
  • log <types>: 記録するログの種類を指定します (measurements, statistics, tracking など)。
  • allow <address/subnet> / deny <address/subnet>: NTPサーバー機能を利用するクライアントのアクセス制御を行います。allow より deny が優先されます。

これらの設定を適切に組み合わせることで、様々な環境や要件に対応したNTP同期システムを構築できます。

ntp パッケージ (ntpd) を利用した時刻同期 (簡単な紹介)

ntp パッケージに含まれる ntpd デーモンは、古くからLinuxで利用されている伝統的なNTP実装です。多機能で信頼性も高いですが、設定がやや複雑であったり、chrony に比べてネットワーク変動への適応が遅いといった特性があります。

Debianでは、新規インストールでNTPが必要な場合は chrony が推奨される傾向にあるため、ここでは簡単な紹介に留めます。もし既存のシステムで ntpd が動作している場合や、特定の理由で ntpd を使用したい場合は参考にしてください。

1. ntp のインストール

bash
sudo apt update
sudo apt install ntp

インストールすると、自動的に ntpd サービスが起動します。もし chrony など他のNTPデーモンが動作している場合は、事前に停止・無効化してください。

2. ntpd の基本的なクライアント設定

設定ファイルは /etc/ntp.conf です。

bash
sudo nano /etc/ntp.conf

基本的なNTPサーバーの指定は server ディレクティブで行います。

例：
“`ini

… (その他のデフォルト設定)

Specify one or more NTP servers.

Use iburst option for faster initial synchronisation.

server ntp.jst.mfeed.ad.jp iburst
server ntp.nict.jp iburst
server jp.pool.ntp.org iburst # プールを指定する場合

… (その他の設定)

“`

設定を保存したら、ntpd サービスを再起動します。

bash
sudo systemctl restart ntp

3. ntpd の状態確認

ntpd の状態確認には ntpq コマンドを使用します。

bash
ntpq -p

出力例：
remote refid st t when poll reach delay offset jitter
==============================================================================
+ntp.jst.mfeed. 210.173.160.27 2 u 10 64 377 12.345 -0.123 0.045
*ntp.nict.jp .INIT. 1 u 12 64 377 15.678 0.098 0.032
+ntp.sakura.ne. 210.173.160.27 2 u 15 64 377 8.765 -0.054 0.021

出力の意味：
* remote: サーバーのホスト名またはIPアドレス。
* refid: サーバーが同期しているサーバーの参照ID。.INIT. は初期状態を示します。
* st: サーバーのストラタム。
* t: タイプ (u はユニキャスト)。
* when: 前回の応答を受信してからの時間（秒）。
* poll: ポーリング間隔（秒）。
* reach: 8ビットのシフトレジスタ（chronyc sources と同じ）。377 (8進数) はバイナリで 11111111 となり、直近8回のポーリング全てが成功したことを示します。
* delay: 往復遅延（ミリ秒）。
* offset: オフセット（ミリ秒）。
* jitter: オフセットの変動（ミリ秒）。

remote の左端の記号は、chronyc sources の MS カラムに似ていますが、記号の意味が異なります。
* *: 現在同期に使用しているサーバー (System Peer)
* +: 同期候補として選択されているサーバー (Candidate)
* #: 同期候補だが、より高いストラタムのソースが優先されている (Culled)
* o: PPS (Pulse Per Second) と同期しているサーバー (PPS Peer)
* x: クライアントの時刻がサーバーに対して遠すぎるため除外されている (Falseticker)
* .: 候補から除外されている (Excess)
* -: クライアントの時刻がサーバーより遠い (Outlier)
* : 選択されていない、または到達できない

* が付いているサーバーが表示されていれば、そのサーバーと同期が確立されています。

ntpd をNTPサーバーとして設定する場合も、/etc/ntp.conf に restrict ディレクティブを追加し、FirewallでUDPポート123を開放する必要があります。chrony の allow ディレクティブに似た機能です。

ntpd は設定オプションが非常に多く、詳細な解説は本記事の範囲を超えますが、より高度な設定や特定のネットワーク構成が必要な場合は、ntp.conf(5) のmanページや公式ドキュメントを参照してください。

トラブルシューティング

NTP同期がうまくいかない場合、様々な原因が考えられます。以下のチェックリストと手順を参考にトラブルシューティングを行ってください。

1. NTPデーモンの状態確認

まず、使用しているNTPデーモン（systemd-timesyncd または chrony または ntpd）が正常に動作しているか確認します。

  • systemd-timesyncd の場合:
    bash
    sudo systemctl status systemd-timesyncd
    timedatectl status
    timedatectl timesync-status
    サービスが active になっているか、System clock synchronized が yes になっているか確認します。

  • chrony の場合:
    bash
    sudo systemctl status chrony
    chronyc sources
    chronyc tracking
    サービスが active になっているか、chronyc sources で * が付いているサーバーが表示されているか、chronyc tracking で Leap status: Normal となっているか確認します。

  • ntpd の場合:
    bash
    sudo systemctl status ntp
    ntpq -p
    サービスが active になっているか、ntpq -p で * が付いているサーバーが表示されているか確認します。

サービスが inactive や failed の場合は、サービスを起動または再起動してみてください (sudo systemctl start <service_name> または sudo systemctl restart <service_name>)。それでも起動しない場合は、設定ファイルの誤りや競合するサービスなどが原因かもしれません。

2. 設定ファイルの確認

使用しているNTPデーモンの設定ファイルに誤りがないか確認します。

  • systemd-timesyncd: /etc/systemd/timesyncd.conf
  • chrony: /etc/chrony/chrony.conf
  • ntpd: /etc/ntp.conf

特に、指定しているNTPサーバーのホスト名やIPアドレスが正しいか、コメントアウトすべきでない行がコメントアウトされていないか、構文エラーがないかなどを確認してください。設定ファイルを修正した場合は、必ずサービスを再起動してください。

3. ネットワーク接続とFirewall

NTPはUDPポート123を使用します。クライアントは通常、ローカルの任意のポートからリモートのUDP 123ポートへ接続します。サーバーとして機能させる場合は、外部からのUDP 123ポートへのアクセスを許可する必要があります。

  • NTPサーバーへの到達性: 指定したNTPサーバーにネットワーク的に到達可能か確認します。ping や traceroute コマンドで確認できますが、UDP 123ポートへの接続が可能かはこれだけでは分かりません。
    • ntpdate -q <ntp_server_address> (ntpdateがインストールされている場合) は、UDP 123でNTPサーバーから時刻を取得できるか確認できます。
    • nmap -sU -p 123 <ntp_server_address> (nmapがインストールされている場合) でポートが開いているか確認できます。
    • または、chrony や ntpd のログを確認するのが確実です。
  • Firewall設定: ローカルのFirewall (ufw, iptables, firewalld など) で、NTP通信に必要なポートがブロックされていないか確認します。
    • クライアントの場合: アウトバウンドのUDP 123ポートへの通信が許可されているか確認します（多くのFirewallではデフォルトで許可されています）。
    • サーバーの場合: インバウンドのUDP 123ポートへの通信が許可されているか確認します (allow ディレクティブで制限している場合は、Firewallと併せて確認が必要です)。
  • ルーターや外部Firewall: サーバーがグローバルIPアドレスを持っている場合や、NAT環境下の内部サーバーを外部に公開している場合、中間にあるルーターや外部FirewallでUDP 123ポートが転送または開放されているか確認してください。

4. システム時刻の大きなずれ

システム時刻がNTPサーバーの時刻に対して大きくずれている場合（通常、数分以上）、多くのNTPデーモンは急激な時刻修正（ステップ同期）を行わず、時間をかけてゆっくり調整しようとします。しかし、あまりにずれていると同期自体が成功しないこともあります。

  • システム時刻が大きくずれている場合は、一度手動で時刻を設定し、その後NTPデーモンを起動して同期させるのが効果的です。
    “`bash
    # NTPデーモンを停止
    sudo systemctl stop systemd-timesyncd # または chrony, ntp

    手動でだいたいの時刻を設定 (例: 2023年10月26日 10時30分00秒)

    事前に正確な時刻を確認しておく

    sudo date -s “YYYY-MM-DD HH:MM:SS”

    ハードウェアクロックも更新 (任意だが推奨)

    sudo hwclock -w

    NTPデーモンを起動または再起動

    sudo systemctl start systemd-timesyncd # または chrony, ntp
    ``
    *    chronyの場合は、makestepディレクティブを設定するか、chronyc makestep` コマンドで一時的にステップ同期を有効にすることもできます。

5. NTPサーバーの選択

指定しているNTPサーバーが正常に機能しているか、負荷が高すぎないかなども確認が必要です。可能であれば、複数の異なるNTPサーバーを指定し、信頼性を向上させましょう。特に、pool.ntp.org の地域別プールは負荷分散されており推奨されます。

6. ログの確認

NTPデーモンのログは、トラブルシューティングに最も役立ちます。

  • systemd-timesyncd: journalctl -u systemd-timesyncd
  • chrony: /var/log/chrony/chrony.log (デフォルト設定の場合) または journalctl -u chrony
  • ntpd: /var/log/syslog や /var/log/daemon.log など (syslogの設定による)

これらのログを確認することで、サービスが起動しているか、どのサーバーにアクセスしようとしているか、通信に成功しているか、エラーが発生していないかなどの詳細な情報を得ることができます。

応用的な設定と考慮事項

ローカルクロックをリファレンスにする (chrony: local stratum)

インターネットに接続されていない、または外部NTPサーバーとの同期が常に不可能な環境で、ローカルネットワーク内のマシン間で時刻を同期させたい場合があります。この場合、ネットワーク内の1台のサーバーをNTPサーバーとして設定し、そのサーバー自身は自身のローカルクロックを時刻源として機能させることができます。

chrony では、/etc/chrony/chrony.conf に以下の行を追加します。

“`ini

… (外部NTPサーバーの行はコメントアウトするか削除)

If no external sources are available, use the local clock.

local stratum 10

Allow local network clients to synchronize

allow 192.168.1.0/24 # 例: ローカルネットワークの範囲を指定
“`

local stratum 10 は、外部ソースと同期できない場合に、自身のローカルクロックをストラタム10のソースとして扱うことを意味します。ストラタム1は原子時計などに予約されているため、ローカルクロックをリファレンスとする場合は通常、それより大きい値を指定します。

この設定により、サーバー自身は厳密なUTCと同期しないかもしれませんが、ローカルネットワーク内の他のマシンは、このサーバーをNTPサーバーとして参照することで、互いの時刻のずれを解消し、相対的に同期した状態を維持できます。

オフライン環境での時刻維持

完全にオフラインで、NTPサーバーにもアクセスできない環境では、システム起動時にハードウェアクロック（RTC）から時刻を読み込み、シャットダウン時にシステム時刻をハードウェアクロックに書き込むことで、ある程度の時刻精度を維持できます。

Debianでは、systemd がデフォルトでこの処理を行いますが、確実に設定を確認・有効化したい場合は、timedatectl コマンドを使用します。

“`bash
timedatectl status # 現在の設定を確認
sudo timedatectl set-local-rtc no # システム時刻(UTC)をRTCに書き込む (通常推奨)

または set-local-rtc yes # システム時刻(ローカルタイム)をRTCに書き込む (Windowsとのデュアルブートなどで必要になる場合がある)

“`

また、hwclock コマンドで手動でシステム時刻とハードウェアクロックを同期させることも可能です。

bash
sudo hwclock -w # システム時刻 -> RTCに書き込む
sudo hwclock -s # RTC -> システム時刻に読み込む

ただし、ハードウェアクロックは時間の経過とともにずれが生じるため、定期的に手動で時刻を合わせるなどの運用が必要になります。

仮想環境における時刻同期の注意点

仮想マシン（ゲストOS）の時刻同期は、物理マシンとは異なる考慮が必要です。

  • ホストとの時刻同期: 多くの仮想化プラットフォーム（VMware, KVM, VirtualBoxなど）は、ホストOSとゲストOSの間で時刻同期機能を提供しています。例えば、KVM/QEMUでは virtio-blk デバイスとして時刻同期が提供されることがあります。デフォルトでは、ゲスト内のNTPデーモンと、ホストとの時刻同期機能が両方有効になっている可能性があり、これにより時刻同期が不安定になることがあります。
  • 推奨される設定:
    • ホストとの時刻同期機能を利用する場合: ゲストOS内のNTPデーモン（systemd-timesyncd, chrony, ntpd など）は無効化します。ホストの正確な時刻に依存します。
    • ゲスト自身がNTP同期する場合: 仮想化プラットフォームのホストとの時刻同期機能は無効化します。ゲストOS内でNTPデーモンを起動し、外部のNTPサーバーと直接同期させます。この方法の方が、ゲストの負荷変動に影響されにくく、より高精度な同期が期待できます。
    • chrony は仮想環境での利用を考慮して設計されており、クロックソースの変動に強い特性があります。ゲスト自身がNTP同期を行う場合は chrony の利用が推奨されます。

仮想化プラットフォームによって設定方法が異なるため、使用している環境のドキュメントを確認してください。

セキュリティに関する考慮事項

NTPはインターネット上で広く利用されているため、セキュリティ上のリスクも考慮する必要があります。

  • DDoS攻撃の踏み台: 設定が不適切なNTPサーバーは、NTP Monlist機能などを悪用したDDoS攻撃の踏み台にされる可能性があります。最近のNTP実装（特にデフォルト設定の chrony）では、Monlist機能は無効化されているか、認証されたクエリ以外には応答しないようになっています。ntpd を使用する場合は、restrict ディレクティブでアクセス元を制限し、Monlist機能（noquery オプションなどで）を無効化することが強く推奨されます。
  • 偽の時刻源: 悪意のあるNTPサーバーから偽の時刻情報を受け取り、システム時刻を改ざんされるリスクがあります。これを防ぐために、信頼できる複数のNTPサーバーを指定し、統計的な処理によって信頼性の低いサーバーを除外するNTPのメカニズムを利用します。さらに高いセキュリティが必要な場合は、NTPv4の認証機能を利用することも検討できます。
  • 認証 (Authentication): NTPv4では、メッセージダイジェスト（MD5やSHA1）やNTS (Network Time Security) を使用して、NTPパケットの送信元を認証する機能があります。これにより、改ざんされた時刻情報を受け取るリスクを低減できます。認証を設定するには、共有鍵を生成し、設定ファイル (/etc/chrony/chrony.keys や /etc/ntp.conf) に鍵情報と使用するNTPサーバーを記述する必要があります。公開されているNTPサーバーでは認証機能を提供していない場合が多いですが、閉じたネットワーク内でのサーバー間同期など、特定の環境では有効なセキュリティ対策となります。

監視ツールとの連携

サーバーの運用監視において、NTP同期が正常に行われているかを監視することは重要です。

  • Zabbix, Nagios, Prometheus + Alertmanager など: 多くの監視ツールは、NTP同期状態を監視するためのテンプレートやプラグインを提供しています。
    • timedatectl の出力監視: timedatectl status の System clock synchronized が yes になっているか監視します。
    • chronyc の出力監視: chronyc tracking の Leap status や System time、chronyc sources の MS カラム（* があるか、? や x がないか）などを監視します。
    • ntpq の出力監視: ntpq -p の出力で * が付いているサーバーが存在するか、オフセットや遅延が異常に大きくないかなどを監視します。
  • 独自のスクリプト: これらのコマンドの出力をパースし、異常があればアラートを通知する独自のスクリプトを作成することも可能です。

時刻同期の異常は、潜在的な問題（ネットワーク障害、Firewall設定ミス、サーバー負荷、ソフトウェアの不具合など）を示すサインであることも多いため、NTP監視は積極的に導入することをお勧めします。

まとめ

本記事では、Debian Linuxにおける時刻同期の重要性から始まり、NTPの基礎知識、そしてDebianで利用可能な主要なNTPデーモンである systemd-timesyncd と chrony を中心とした設定方法について詳しく解説しました。

  • 正確な時刻同期は、ログの整合性、分散システムの協調動作、セキュリティ、アプリケーションの正常動作など、サーバー運用の多くの側面において不可欠です。
  • NTPは、ネットワーク遅延を考慮して高精度な時刻同期を実現する標準的なプロトコルです。
  • Debianでは、用途に応じて systemd-timesyncd (シンプルクライアント) または chrony (高機能クライアント/サーバー) を選択するのが一般的です。
  • systemd-timesyncd はデフォルトで有効な軽量クライアントで、設定は /etc/systemd/timesyncd.conf で行います。
  • chrony は高精度かつ堅牢なNTPデーモンで、設定は /etc/chrony/chrony.conf で行います。クライアントとしてもサーバーとしても機能します。
  • NTPサーバーとして機能させる場合は、FirewallでUDPポート123を開放し、設定ファイルでアクセス元を制限する必要があります。
  • トラブルシューティングでは、デーモンの状態、設定ファイル、ネットワーク接続、Firewall、時刻のずれ、ログなどを順に確認することが重要です。
  • 仮想環境、オフライン環境、セキュリティ対策、監視ツールとの連携など、応用的な設定や考慮事項についても触れました。

システムの種類やネットワーク環境、必要な時刻精度のレベルに応じて、最適なNTP設定を選択し、適切に運用することが、安定したサーバー稼働のために非常に重要です。本記事が、DebianでのNTP入門として、皆様のシステム管理の一助となれば幸いです。

これで、約5000語の詳細な解説記事が完成しました。各セクションで概念説明、具体的な設定方法、コマンド例、トラブルシューティングなどを網羅し、十分な情報量を提供できたかと思います。
上記が、Debian NTP入門：時刻同期の設定方法を解説 の詳細な説明を含む記事になります。約5000語で記述しました。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール