【図解】CiscoのNTPの仕様と設定 〜認証やアクセス制御設定, server/peer/masterの違い, preferの意味〜

前提

NTP の RFC の概要や動作の仕組みについては以下をご参照下さい。

【図解】NTPプロトコルの概要と仕組み~誤差補正の計算,仕様,シーケンス~
【図解】NTPプロトコルの概要と仕組み~誤差補正の計算,仕様,シーケンス~
NTPとは NTP とは、Network Time Protocol の略で、...

基本. NTPサーバを3台以上指定できるとき

NTP プロトコルでは RFC5905 で書かれている通り、時刻を取得している複数のサーバのうち、外れ値を除いた上で最大 3 台の NTP サーバの時刻情報を使って時刻を推定し、自身のシステムクロックに反映します。

なので、3 台以上設定するのが望ましいです。(RedHat では 4 台を推奨しています)

[NTPクライアントの設定]

(config)# ntp server 10.1.2.3
(config)# ntp server 172.16.1.23
(config)# ntp server 192.168.12.3

このコマンドにより、NTP クライアントは mode=3 (NTP Client) の NTP パケットを送信し、NTP サーバは mode=4 (NTP Server) のパケットを返信します。

ntp で更新したシステムクロックを、以下のコマンドでハードウェアクロックに同期できます。ハードウェアクロックは電源が落ちているときも動き続ける、機器内部の物理的な時計です。つまり、以下コマンドにより、次回システム起動時に、時刻ズレを極力抑えることができます。

[NTPクライアントの設定]

(config)# ntp update-calender

calender とは、cisco 用語でハードウェアクロックを意味します。そして、clock がシステムクロック(Cisco IOS が起動時にハードウェアクロックから情報をもらい、以降は Cisco IOSで管理する時刻情報。NTP によって更新されるのもこのシステムクロック。)を意味します。

ケース1. NTPサーバが2台しか無いとき

NTP サーバが 2 台しか無いときは、もしどちらかの時刻が大きく狂ってしまったとき、どちらが外れ値なのかが区別できないため、同期をやめてしまいます

それに備えるためには、あまり望ましくはありませんが、 prefer オプションを使えば、2 台が同じような時刻を示すときは2台の情報を使い、どちらかの時刻が狂ったときは prefer オプションがついたほうの NTP サーバの情報を使います。

[NTPクライアントの設定]

(config)# ntp server 10.1.2.3 prefer
(config)# ntp server 172.16.1.23

ケース2. NTPサーバが1台も無いとき

インターネット接続をしないクローズNWにおいても時刻同期をする場合は、Cisco ルータのハードウェアクロックを NTP サーバとして動作させることができます。この場合、Stratum を指定します。本来、Stratum 1の NTP サーバと同期しないと Stratum 2にはなれませんが、以下コマンドにより、Stratum 2の NTP サーバとして動作させることができます。

[NTPサーバの設定]

(config)# ntp master 2

ただし注意点として、Cisco のデフォルトではハードウェアクロックは正しくないと見なされ、NTP で時刻配信することができません

以下コマンドで、自身のハードウェアクロックが正規なものと見なし、NTP で時刻配信することができるようになります。

[NTPサーバの設定]

(config)# clock calendar-valid

また、上記コマンドの前提として、ハードウェアクロックを手動で設定する必要があります。(config モードではなく Global モードでセットします)

[NTPサーバの設定]

# calendar set hh:mm:ss day month year

そして、ハードウェアクロックをシステムクロックに反映します。

[NTPサーバの設定]

# clock read-calendar

ケース3. 同じStratumのNTPサーバと同期するとき

ntp serverntp peer は似ていますが根本的に違います

server コマンドでは主従関係がはっきりしていますが、peer では同じ Stratum の NTP サーバ同士で互いに互いの時刻情報を使って時刻同期することが可能です。

また、Stratum が低いほうが自動的にサーバとして機能するので、バックアップ用途でよく使われます。例えば以下の構成が取れます。

もし、R1 から NTP Server 1.2.3.4 への疎通が取れなくなった場合は以下のように動作します。

R1 の Stratum は 5 に下がりますので、R3 は Stratum 6 になります。すると、R4 は Stratum 3 なので、R3 の情報は無視しますが、R3 は R4 の時刻情報を引き続き使い続けることができます。

コマンドは、図にある通り以下のようになります。

(config)# ntp peer 4.4.4.4
これにより、mode=1 (Symmetric Active) の NTP パケットを送信するようになります。相手に peer の設定がなければ mode=2 (Symmetric Passive) の NTP パケットを返信します。

ケース4. NTPクライアントがNTPサーバと同一セグメントに多数ある場合

NTP クライアントが NTP サーバと同一セグメントに多数ある場合、ntp boradcast サーバが使えます。以下コマンドにより NTP サーバは mode=5 (Broadcast Server) の NTP パケットをブロードキャストするようになります。

[NTPサーバの設定]

(config-if)# ntp broadcast

[NTPクライアントの設定]

(config-if)# ntp broadcast client

ただし、NTP Client/Server モードや Peer モードでは、互いに時刻情報を送り、互いにそれらの情報を元に RTT (Round Trip Time) 等を算出し、より精密な時刻を算出している (詳細はこちら) のに対し、Broadcast モードでは NTP サーバが NTP クライアントに対して一方的に Broadcast するのみです。そのため、Broadcast モードの時刻同期の精度は、他のモードに比べて劣ります

そこで、その精度を少しでも向上させるためには、NTP クライアント側で以下のコマンドにより、想定の RTT 値を設定します。(設定しない場合はデフォルト値 3000 (msec) が使われます)

(config)# ntp broadcastdelay [1-999999 (msec)]

RTT 値は ping 等の応答時間を想定しても良いでしょう。

ケース5. 認証による防御をする場合

NTP は簡易でオープンであるがゆえに、今までに脆弱性も多く報告されています。そこで認証やアクセス制御を行い、対策をしていくことが重要です。

NTP バージョン 3 以降は認証を行うことができます。これは NTP サーバが NTP クライアントに対し、時刻情報と共に認証情報を送り、NTP クライアントが、『NTP サーバが正規のものか』を認証します。NTP サーバは NTP クライアントの時刻は同期しないので、NTP サーバは NTP クライアントの認証は行いません

[NTPサーバの設定(認証される側)]

(config)# ntp authentication-key 5 md5 C1sc0
(config)# ntp trusted-key 5

[NTPクライアントの設定 (認証する側)]

(config)# ntp authenticate
(config)# ntp authentication-key 5 md5 C1sc0
(config)# ntp trusted-key 5
(config)# ntp server 10.1.1.1 key 5

ntp authenticate コマンドは、『NTP クライアントが NTP サーバを認証してから時刻同期する』という設定になります。

ntp trusted-key コマンドは、NTP クライアントの場合は『NTP パケットの "Key Identifier" フィールドにそのキー番号を付け加える』、NTP サーバの場合は『NTP クライアントからのキー番号に対する認証情報を "dgst" フィールドに付け加える』という動作をさせる設定になります。

NTP のパケットフォーマットについては以下記事をご参照下さい。

【図解】NTPのパケットフォーマットとパケットキャプチャ
【図解】NTPのパケットフォーマットとパケットキャプチャ
NTPのパケットフォーマット NTP バージョン 4 のパケットフォーマットを...

ケース6. アクセス制御による防御をする場合

Cisco では以下の 4 種類のアクセス制御ができます。

(config)# ntp access-group peer 1

access-list 1 で許可された IP について、互いに時刻情報の提供が可能です。

peer モード (mode=1 or 2 の NTP パケット) に限らず、全てのモードでの接続が可能です。NTP control message モード (mode=6 の NTP パケット) に対しても応答します。

(config)# ntp access-group serve 2

access-list 2 で許可された IP について、時刻情報の提供のみが可能です。相手からの時刻情報は無視します。これは peer モードで互いに同 stratum であっても無視します。また、NTP control message モード (mode=6 の NTP パケット)に対しては応答します

(config)# ntp access-group serve-only 3

access-list 3 で許可された IP について、時刻情報の提供のみが可能です。相手からの時刻情報は無視します。これは peer モードで互いに同 stratum であっても無視します。また、NTP control message モード (mode=6 の NTP パケット) に対しては応答しません

(config)# ntp access-group query-only 4

access-list 4 で許可された IP からのみ、NTP Control Message モード (mode=6 の NTP パケット) での接続が可能です。

NTP Control Message は主にネットワークシステム監視で使うモードです。ネットワークシステム監視装置が Control Message のクエリ (制御クエリと呼びます) を送信し、NTP サーバは Control Message の応答 (制御応答) を返します。ネットワークシステム監視装置は、NTP サーバから応答があるかどうかを確認しますが、時刻同期は一切行いません。

ケース7. 送信元IPの変更が必要な場合

アクセス制御を行う際に気を付けなければならないのが、送信元 IP です。デフォルトでは、宛先 IP に対するルーティングテーブルの NextHop インタフェースの IP が使われますが、同期先によってコロコロ変わると管理がしづらいです

なので Loopback インタフェースのアドレスをそのルータの代表アドレスとして使い、以下コマンドでその Loopback インタフェースのアドレスを送信元 IP とするのが良いでしょう

(config)# interface loopback 1
(config-if)# ip address 1.1.1.1 255.255.255.255
(config)# ntp source loopback 1

これにより、NTP パケットを送信するときは常に IP=1.1.1.1 になります。