web-dev-qa-db-ja.com

サーバー時刻とntpdの同期の問題

あるマシンを別のマシンとntp同期しようとしています。どちらもDebian lennyを実行しており、両方にntpパッケージをインストールしました。私はサーバーを外部マシンと同期するように設定して

server IP.ADDRESS iburst

その中に/etc/ntp.confファイルがあります。

サーバーのみをクライアントの/etc/ntp.confに配置して、クライアントをサーバーと同期するように構成しました。

ただし、それらは同期していないようです。 ntpqは、状態がINIT=であることを示しています。これは、ドキュメントによれば、「関連付けがまだ初めて同期されていない」ことを示しています。

# ntpq -n
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.99.84.134    .INIT.          16 u  665 1024    0    0.000    0.000   0.000

ntpq-> asは、条件行に「拒否」を示します。

# ntpq
ntpq> as

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 40102  8000   yes   yes  none    reject

これを解決する方法はありますか？ （ntpdateは使用しません）。

linuxntpntpd
5
Omry

問題は、サーバー自体が上流のサーバーと同期できないことでした。解決策は、次のようにサーバー構成を変更することでした。

ハードコードされた単一のサーバーではなく、Debianプールサーバーを再度有効にしました。

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

ローカルクロックリファレンスを追加しました。これにより、サーバーがクライアントと同期していない場合でも同期されているように見えます。これは、私のセットアップにとって望ましい動作です。

server 127.127.1.0
fudge 127.127.1.0 stratum 10

これらの変更を加えると、サーバーはそれ自体を同期させることができ、クライアントはサーバーと同期することができました。

3
Omry

最近の多くのディストリビューションでは、アクセスを制限するようにntpdを設定しています。 restrict行がサーバーの/etc/ntp.confに存在する場合、それらの行に一致するホスト/ネットワークのみがntpdへの接続を許可されます。サーバーとの同期を許可するホストまたはネットワークに対して、restrict行を追加する必要があります。たとえば、言及したクライアントを同期させるには、次のいずれかの行を追加します。

# allow just this Host
restrict 10.99.84.134 nomodify notrap

# or allow the whole /24 segment
restrict 10.99.84.0 mask 255.255.255.0 nomodify notrap

その後、ntpdを再起動すると、クライアントが同期できるはずです。

5
James Sneeringer

また、「リーチ」がまだ0であるため、何らかの接続の問題があると言うこともできます。

しばらくntpをオフにし、ntpdateを実行して一度同期してみます。

ntpdate 10.99.84.134

それが失敗した場合は、接続の問題があります。

  1. 2つのマシンがICMP（ping）を介して互いに通信できることを確認します
  2. 可能であれば、ntpへの接続を妨げるファイアウォール設定が10.99.84.134にないことを確認します

  3. ファイアウォールの問題がない場合は、ntpがリッスンしていることを10.99.84.134で確認します

    netstat -tapn | grep 123

1
Greeblesnort

ファイアウォールでUDPポート123が許可されていることを確認してください。同じ問題がありましたが、ファイアウォールがポート123をブロックしていることが原因でした。

0
Vipin Ms

サーバー上でtcpdumpを実行して、ポート123に出入りするすべてのtcpおよびudpトラフィックをインターセプトしてみてください。パケットが問題なくポートに到達できるかどうかは、クライアントのファイアウォールによって何らかの方法でブロックされます。例

0
dmityugov