web-dev-qa-db-ja.com

ntpdateは機能しますが、ntpdは同期できません

これはRHEL 5.5にあります。

まず、リモートホストへのntpdateが機能します。

$ ntpdate XXX.YYY.4.21
24 Oct 16:01:17 ntpdate[5276]: adjust time server XXX.YYY.4.21 offset 0.027291 sec

次に、/ etc/ntp.confのサーバー行です。すべてのrestrict行はトラブルシューティングのためにコメント化されています。

server 127.127.1.0
server XXX.YYY.4.21

service ntpd startおよびntpqで確認：

$ ntpq
ntpq> peer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*LOCAL(0)        .LOCL.           5 l   36   64  377    0.000    0.000   0.001
 timeserver.doma .LOCL.           1 u   39  128  377    0.489   51.261  58.975

ntpq> opeer
 remote           local          st t when poll reach   delay   offset    disp
==============================================================================
*LOCAL(0)        127.0.0.1        5 l   40   64  377    0.000    0.000   0.001
 timeserver.doma XXX.YYY.22.169   1 u   43  128  377    0.489   51.261  58.975

XXX.YYY.22.169は、作業しているホストのアドレスです。 ntp.confファイルのIPアドレスを逆引きして、ntpq出力がリモートサーバーの名前を正しく指定していることを確認します。ただし、ご覧のように、私の.LOCLにロールオーバーするだけです。タイムサーバー。また、ntptraceはローカルタイムサーバーを返し、ntptrace XXX.YYY.4.21タイムアウト。

$ ntptrace
localhost.localdomain: stratum 6, offset 0.000000, synch distance 0.948181

$ ntptrace XXX.YYY.4.21
XXX.YYY.4.21: timed out, nothing received
***Request timed out

これは、私のntpデーモンが自分自身を照会しているように見えます。

私のテストネットワークタイムサーバーと企業ネットワークタイムサーバーの間のルーターが制御できないことが、送信元ポートでブロックされている可能性について考えています。 （ntpdateはポート123で送信すると思います。これにより、フィルターが回避され、ntpdの実行中には使用できなくなります。）ネットワーク担当者にメールで確認します。

最後に、 telnet XXX.YYY.4.21 123タイムアウトしたり、接続を完了したりすることはありません。

質問：

ここで何が欠けていますか？

この接続が失敗している場所を特定するために他に何を確認できますか？

strace ntptrace XXX.YYY.4.21 ntptraceの送信元ポートを表示しますか？ほとんどのstrace呼び出しを分解できますが、そのデータの場所はわかりません。

テストネットワークとタイムサーバーの間のゲートウェイルーターを直接調べることができない場合、これらの切断の原因であるという証拠をどのように作成できますか？あるいは、どうすればそれを除外できますか？

rhel5ntpntpdntpdate
4
dafydd

壮大な解決策をお探しの方、お詫び申し上げます。これは安っぽくなるでしょう。

はい、タイムサーバーに到達できません。理由を特定できませんでした。良いニュースは、私がアクセスできる外部DNSサーバーの1つが、NTPパケット自体、およびitは、ティックのためにその外部タイムサーバーに接続しています。これは回避策であり、修正ではありません。しかし、取得できるものを使用します。

つまり、結局のところ、私は1つのサービス層しか失うことはありません。

補足として、私はNTPバグデータベースに登録したので、拡張機能 bug 2297 を書くことができました。ピアのrefids .INIT。、。 LOCL。、およびLOCAL（0）。

0
dafydd

reach列の_377_は、接続に問題がないことを意味します。 NTPはUDPであるため、telnetは接続しません。

構成から_server 127.127.1.0_を削除してみてください。*LOCAL(0)による_*_は、層5のローカルサーバーが同期に使用されていることを示しています。層1のリモートサーバーよりも優先されます。遅延とオフセットの両方が0.000であることは、おそらくそれと関係があります。

4
Shane Madden

私は同じ問題を抱えていました：

ntpq -pはリーチ= 0を示していました

まだ1- ntpdが実行されていました2- ntp.confにサーバーがリストされています3- ntpdateはそれらのサーバーを使用して機能しました4- ntpdate -uはそれらのサーバーを使用して機能しました5- ncはTCPポート123が開いていましたサーバー6-ncは、それらのサーバーでUDPポート123が開いていることを示しました

したがって、基本的にntpdateは機能し、ファイアウォールの問題はありませんでしたが、ntpq -pは、リストされた各サーバーのリーチ= 0を示しました。

Ntp.confの制限行であることが判明しました。 ntp.confからすべての制限行を削除してntpdを再起動すると、そこからすべてが機能しました。

1
Brad Allison

ローカルクロックを含める場合は、そのレベルをかなり控えめにします。 5に設定しているようです。通常、少なくとも8（fudge 127.127.1.0 stratum 8）に設定します。ファッジしないと、ネットワーク上の他のホストからは原子時計のように見えます。スキャンした1つのネットワーク上で、多くの低階層サーバーが時間をアナウンスしているのを発見しました。これは通常、数時間または数日では不正確でした。

Shaneは、サーバーにアクセスできることを示すreach値については正しいです。タイムサーバーのoffsetとjitterの値が高い場合は、信頼性があまり高くない可能性があります。サーバーがまだ同期しているため、値が高い可能性があります。 poll間隔が128に増加したという事実は、サーバーが一貫した結果を得ていることを示しています。 1024秒まで徐々に増加します。

次のようなループを実行してみてください：

while sleep 60; do
    ntpq -n -c peers; done

これにより、ntpがどの程度うまく機能しているかがわかります。時間の経過とともに安定するはずです。

リモートでサーバーにアクセスできる情報量を制限するために、ntpdに設定できるいくつかの制限があります。タイムソースとして上流サーバーのみを使用するように制限されている可能性があります。

送信元と宛先の両方でポート123へのトラフィックを制限するファイアウォールルールが可能です。これにより、NTP設定が機能しますが、他のツールによるアクセスが制限されます。一部のツールでは、利用可能な場合、ポート123をソースポートとして使用できます。デバッグモードでntpdateを使用することに部分的です。

上流サーバーのrefidがあなたのIPアドレスであることが正しい場合、それは優先タイムソースとしてサーバーを使用しているようです。 restrict noqueryを構成に追加してみてください。上流サーバーの設定が適切でない可能性があります。ルーターやネームサーバーをソースとして追加してみてください。公式の企業サーバーよりも優れたソースになる可能性があります。

1
BillThor

私の2セントを上部のGoogle検索結果に追加したかっただけです。NTPがホストの外部インターフェイスにバインドされていないホストでこの問題に遭遇しました。この問題がある場合は、 netstat -tulpnの出力。

このntpdのインスタンスは、既知の適切なタイムソースと同期できません。

$ Sudo netstat -tulpn | grep ntp
udp        0      0 127.0.0.1:123               0.0.0.0:*                                  31316/ntpd          
udp        0      0 0.0.0.0:123                 0.0.0.0:*                               31316/ntpd

この意志。

$ Sudo netstat -tulpn | grep ntp
udp        0      0 192.168.1.15:123            0.0.0.0:*                               32294/ntpd          
udp        0      0 127.0.0.1:123               0.0.0.0:*                               32294/ntpd          
udp        0      0 0.0.0.0:123                 0.0.0.0:*                               32294/ntpd

これは、構成ファイルが0.0.0.0ワイルドカードのみを使用してIPv4インターフェースへのバインドを制限しようとした結果です。

$ grep ^interface /etc/ntp.conf 
interface listen 0.0.0.0

正しい（望ましい）構成は次のとおりです。

$ grep ^interface /etc/ntp.conf 
interface listen ipv4
interface ignore ipv6

（または、両方のインターフェース構成オプションを削除します。）

/etc/sysconfig/ntpまたは同等のものをチェックして、インターフェースのバインディングを制限する可能性のある構成がないか確認することもできます。

0
Aaron Copley