pool.ntp.orgに ⾃宅サーバーで 参加してみたら...(QUNOG 34)

2025年12月末より自宅サーバーをstratum2としてpool.ntp.orgに参加させてみたところ、AWSから多くのアクセスがあることがわかった。本発表ではNTPサーバーの(泥臭い)チューニングについて、また、なぜAWSからのアクセスが多いのか？を仮説を交えて発表する

＃JANOG 57のTS-OPSで話をした内容について、新たにパケットダンプを取得し再度解析しました。

Transcript

1. pool.ntp.orgに ⾃宅サーバーで 参加してみたら... 2026/2/27 QUNOG34 ⾕崎⽂義(ぼぇぼぇ団)
2. 2 ⾃⼰紹介 • 名前︓⾕崎⽂義(たにざきふみのり) • 所属︓NTT⻄⽇本/NTTスマートコネクト(AS7671) • 属性︓ネットワークエンジニア(たまにサーバー) • 福岡⼤学公開NTPサービスの中の⼈ • さまざまな社外の団体やプロジェクトに参加 • JPOPF運営チーム(JPOPF-ST) • サイバー関⻄プロジェクト(CKP) • 九州ギガポッププロジェクト(QGPOP) • BAKUCHIKU boardメンバー • 過去)APNIC 56 ネットワークチーム(お⼿伝い係) • 過去)APRICOT-APAN 2015 ネットワークチームチェア • 過去)IPv6普及・⾼度化推進協議会 • 趣味︓メタル/⾶⾏機/猫/⼟器・⼟偶・埴輪・古墳/スターウォーズ • 最近はまっていること︓ゲーム(Backpack Battles,DiabloIV)、パイナップル栽培🍍 https://www.jpopf.net/
3. 3 はじめる前に... • これは個⼈の活動です • JANOG 57のTS-OPS BoFで発表した内容に最新情報を追加しました。 • 資料はのちほど公開します • 後半でAWSの話がでてきますが... • わたしはAWSは全く詳しくありません︕詳しい⽅、ぜひアドバイスをお願いします︕ • 『トラフィックが多いからアクセスを⽌めろ︕』という話ではありません︕!
4. 4 ⼀番⾔いたいこと︓『時刻同期の重要性』 •時刻はシステムの根源とも⾔える重要な構成要素 • 必要な精度、信頼できる時刻源 •『正確な時刻』と『システム全体の時刻の統⼀』 • どちらかのみでは意味がない • 後者は忘れられがち(な気がする)
5. 5 pool.ntp.orgとは︖ • 世界最⼤の公開NTPサーバーの仮想クラスタ • ボランタリベースで提供されたNTPサーバーをまとめたサービス • クライアントが利⽤したい場合は、ntpdateやchrony.conf、ntp.conf等の 設定でFQDNを指定 • 例︓jp.pool.ntp.org、[0-3].jp.pool.ntp.org • NTP Pool Projectが運営する権威DNSにAもしくはAAAAを問い合わせた 際、あるルールに基づいて振り分け(DNSによる広域負荷分散) • 『GeoDNS』による地理情報的評価 • NTP Pool Projectで⾏なっている測定と監視の結果 • 世界中に測定/監視⽤サーバーがある模様 • NTP Pool Projectに参加する際に⼊⼒するパラメータ(ネットスピード) • https://www.ntppool.org/ % dig +short jp.pool.ntp.org 162.159.200.123 165.140.142.8 162.159.200.1 172.105.192.74 %
6. 6 なぜpool.ntp.orgに参加しようと思ったか︖ • ⾃宅にGNSS/PPSなStratum1がたくさん • Raspberry Pi 3 x 1 • 産業⽤PC x 1(旧pool.ntp.org⽤サーバー) • FC-NTP-MINI x 2 (アプライアンス) • TF-NTP-LITE x 1 (アプライアンス) • TZT ZG802-01 NTP Time Server x 1 (アプライアンス) • Raspberry Pi 3と産業⽤PCで作ったStratum1がそれなりに⾼精度 • 上記アプライアンスの精度調査ができた • 精度に問題があるアプライアンスのおかげで、chronyやntpdの動作がよく理解できたw • 新しい遊びはないかな︖ 『せや︕pool.ntp.orgに参加してみよ︕!』 『とりあえずサーバーをなんか買っとこw』
7. 7 GNSSアンテナは南向きの窓に設置 ⾃宅のStratum1たち 精度に問題あり GNSS/PPS同期のRaspberry Pi 3 GNSS/PPS同期の産業⽤PC
8. 8 poolで使⽤しているサーバー • CPU︓Celeron N2840 @ 2.16GHz • コア数︓2 • メモリ︓8GB DIMM DDR3 x 1 • ストレージ︓128GB SATA SSD • NIC︓Realtek RTL8118h/8111h x 2 • USB︓3.0 x 2、2.0 x 4 • シリアルポート︓UART 16550A x 2 • おまけ︓USB イーサーネットアダプタ x 1 新しいサーバーを 買いましたw
9. 9 poolで使⽤しているサーバー • CPU︓Pentium 3825U@1.90GHz • コア数︓2 (HT有効︓4) • メモリ︓4GB DIMM DDR3 x 1 • ストレージ︓64GB SATA SSD • NIC︓Realtek RTL8168 x 2 • USBポート︓3.0 x 4 • シリアルポート︓UART 16550A x 2 • おまけ︓USB イーサーネットアダプタ x 1 • ⾼価なサーバーでなくても、それなりに遊べますw
10. 10 ⽅針と設計 • ⾃宅固定IPv4アドレスを使い、NAT経由で外部に公開 • ⾃宅ネットワークに影響がないようにしたい • 受けるNTPリクエストはほどほどで • 公開するNTPサーバーはstratum2 • ⾃宅にあるstratum1(GNSS/PPS同期)は⼤切な時刻源なので外部公開しない • 公開するstratum2サーバーは、⾃宅内のstratum1や外部の公開NTPサーバーと同 期させ、時刻源の冗⻑性を確保 • OS︓Ubuntu 24.04 LTS • ソフトウェアはchronyを選択 • 設定がわかりやすく、機能がntpdより多い(例︓maxdistance、clientloglimit...) • 再起動時の収束が早い • モニタリング機能(chronyc)が豊富 • Prometheus/Grafanaとの親和性が⾼い
11. 11 チューニング -1- • ポイント • 可能な限り、パケットを取りこぼさない • NTPの処理を最優先、遅延と揺らぎを抑える • とはいえ、頑張りすぎない • ネットワーク︓冗⻑性の確保、サービストラフィックと管理トラフィックの分離 • サービス⽤︓NIC x 2 を bond0(Active/Standby)で設定 • 管理⽤︓USBイーサーネットアダプタを使⽤ • OS︓ネットワーク遅延と揺らぎの原因を排除 • /etc/default/grub = 電⼒監視無効、通常プロセスはCPU0を使⽤ • intel_idle.max_cstate=0 processor.max_cstate=0 isolcpus=1,2,3 • /etc/sysctl.conf = ネットワーク関連のバッファを拡⼤ • /etc/rc.local = NIC毎に処理するコアを固定、パケット毎に即時処理、CPUは常に最 速の周波数で動作
12. 12 /etc/rc.local echo 1 > /proc/irq/51/smp_affinity_list echo 2 > /proc/irq/52/smp_affinity_list /usr/sbin/ethtool -C enp2s0 rx-usecs 0 rx-frames 1 /usr/sbin/ethtool -C enp3s0 rx-usecs 0 rx-frames 1 for i in {0..3}; do if [ -f /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor ]; then echo performance > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor fi done exit 0 /etc/sysctl.conf net.ipv6.conf.<USB Ether>.disable_ipv6 = 1 net.core.wmem_max = 134217728 net.core.wmem_default = 134217728 net.ipv4.tcp_window_scaling = 1 net.core.rmem_max = 134217728 net.core.rmem_default = 134217728 net.ipv4.udp_mem = 4096 87380 134217728 net.core.netdev_max_backlog = 10000 CPUコアに関する考え⽅ • 物理コアは2、ハイパースレッディングでコアは4 • 物理コア#0 • CPU0︓下記以外の処理 • CPU2︓NTPパケット処理(NIC#2) • 物理コア#1 • CPU1︓NTPパケット処理(NIC#1) • CPU3︓NTP計算処理⽤
13. 13 チューニング -2- (chrony) • chronydのリアルタイムスケジュールの 優先度をあげる(あげすぎはダメ) • chronydをmlock() • 主同期先はhome-ntp[1-2] • 強く信⽤ • ⾼頻度で同期 • IPv6で同期させると、Reference IDが ハッシュ値に︕つまり⾃宅stratum1の IPv4アドレスがバレないw • ratelimitはほどほど且つゆるめ • interval 0︓制限をかける最⼩間隔を 2^0=1秒に設定 • burst 64︓⼀時的な連射枠は64発、そ れ以上は破棄 • leak 4︓連射枠は1秒に4個復活 cmdallow 127.0.0.1 cmdallow ::1 rtcsync sched_priority 1 lock_all server home-ntp1 iburst prefer trust port 123 minpoll 4 maxpoll 6 xleave server home-ntp2 iburst prefer trust port 123 minpoll 4 maxpoll 6 xleave server home-ntp3 iburst server home-ntp4 iburst pool ntp.jst.mfeed.ad.jp maxsources 2 pool ntp.nict.jp maxsources 2 keyfile /etc/chrony/chrony.keys driftfile /var/lib/chrony/chrony.drift log tracking measurements statistics logdir /var/log/chrony maxupdateskew 5.0 makestep 1 3 maxdistance 0.05 allow all ratelimit interval 0 burst 64 leak 4 clientloglimit 10000000
14. 14 監視/計測 • 監視︓ポイントを押さえて、楽にやりたい • uptime kumaにNTP監視機能を追加し、githubで公開 • https://github.com/tanyorg/uptime-kuma-mon • 計測︓かっこいいグラフを描きたいw • Prometheus + Grafana + (chrony-exporter, ntp-exporter) 監視システムの時計とNTPサーバーとの時刻のずれ 緑︓GNSS/PPS同期のラズパイ、⾚は精度に問題があるアプライアンス uptime-kuma-mon
15. 15 pool.ntp.orgへの参加から時刻配信開始までの流れ 1. webページからサーバーを登録 • https://www.ntppool.org/ja/ • IPアドレスとネットスピードを⼊⼒ • ネットスピード︓サーバーが受信するクエリの量は概ねこの 「ネットスピード」設定に正⽐例 2. IPアドレスが正しいかの簡易認証 3. サーバー群に追加され、ステータスページ開通 4. pool.ntp.org側から監視開始、スコアがつけられはじ める 5. スコアが10より多くなるとクラスタに⾃動的に参加し、 時刻配信開始 • 参照︓NTP Pool News/Monitoring system/Technical. details • https://news.ntppool.org/docs/monitoring/ https://www.ntppool.org/scores/162.159.200.123
16. 16 実際のトラフィック クライアントからのアクセスがある︕サービス提供はやっぱりたのしい︕︕ 『インターネットに貢献している』という満⾜感がある︕ ところで、どこからアクセスがあるんだろう︖ ⽇本国内とアジア対象として NTP Pool Project側で割り当て
17. 17 どこからアクセスが︖ 期間︓2026/2/17 18:05〜2026/2/19 13:18 (43h13m) 分析⽅法︓以下の⽅法で取得したpcapを解析 取得⽅法︓tcpdump -i bond0 -nn -s 150 -W 24 -C 1200 ¥ -w ./ntp_icmp_24h.pcap ¥ "udp port 123 or (icmp and (icmp[icmptype] == 3))" • 右の⽅法でパケットダンプし中⾝を解析 • 1億3400万強のリクエストの30%が AWS(AS16509)からのアクセス︕ • なんで︖︕︖︕ 送信元IPv4アドレスをAS番号毎に集計 ASN Requests Organization AS16509 40,712,692 AMAZON-02 - Amazon.com, Inc. AS4134 12,727,477 CHINANET-BACKBONE No.31,Jin-rong Street AS4713 10,804,128 OCN NTT DOCOMO BUSINESS,Inc. AS9808 9,710,010 CHINAMOBILE-CN China Mobile Communications Group AS4837 8,871,167 CHINA169-BACKBONE CHINA UNICOM China169 Backbone AS2516 7,348,713 KDDI KDDI CORPORATION AS17676 5,165,011 GIGAINFRA SoftBank Corp. AS9605 3,748,507 DOCOMO NTT DOCOMO, INC. AS2527 1,722,594 SO-NET Sony Network Communications Inc. AS24547 1,606,460 CMNET-V4HEBEI-AS-AP Hebei Mobile Communication other 31,993,004 12,150 other ASN TOTAL 134,409,763
18. 18 AS16509全体からのアクセス • 縦軸：Packets/sec • 横軸：⽇時 2026/2/18 2026/2/19 2026/2/17
19. 19 詳細解析 • 送信元IPアドレスを元にリクエスト数ランキングTOP100を調べると、 AWSのIPアドレス(AS16509)が99個 • ⼀つのIPv4アドレスから最⼤で43h13mに29万パケット弱 • リクエストに対してICMP port unreachableが0.2%程度返ってくる • TOP100の逆引きを調べると以下の通り • ec2-*-*-*-*-ap-northeast-1.compute.amazonaws.com︓83 • ec2-*-*-*-*-ap-northeast-3.compute.amazonaws.com︓15 • ユーザー側で逆引きを独⾃設定(AS16509)︓1 • AS4713︓1 • 別ネットワークにある複数のフルリゾルバに対して180秒毎に pool.ntp.orgのAレコードを引き、我が家のIPアドレス出現数を調査 • 調査期間︓2026/2/1〜2026/2/6 • 調査したFQDN(TTL:130s) • jp.pool.ntp.org、[0-3].jp.pool.ntp.org • amazon.pool.ntp.org、 [0-3].amazon.pool.ntp.org • 我が家の出現率は0.8%弱 IPアドレス毎の NTPリクエスト数ベスト10 IPv4 address パケット数 1 35.72.***.*** 286,667 2 57.180.***.*** 285,507 3 35.73.***.*** 284,537 4 18.178.***.*** 284,510 5 18.177.***.*** 282,733 6 43.206.***.*** 282,040 7 18.180.***.*** 281,735 8 18.181.***.*** 281,162 9 18.182.***.*** 280,855 10 57.181.***.*** 280,540
20. 20 AWS内特定ホストからのNTPリクエスト • ランキング1位から5位のホストのリク エスト数を5分毎にグラフ化 • 傾向が同じ︖︕ データより⼀部抜粋 2026/2/18 2026/2/19 2026/2/17 DateTime IP1 IP2 IP3 IP4 IP5 2026-02-17 20:15 1036 1054 1040 894 998 2026-02-17 20:20 1407 1272 1439 1380 1221 2026-02-17 20:25 598 622 696 612 685 2026-02-17 20:30 510 557 488 643 635 2026-02-17 20:35 1370 1226 1260 1299 1437 2026-02-17 20:40 1003 913 928 970 867 2026-02-17 20:45 647 478 701 618 547 2026-02-17 20:50 396 331 392 374 372 2026-02-17 20:55 380 384 372 319 378 2026-02-17 21:00 1890 1896 1787 1955 1817 2026-02-17 21:05 1196 1222 1144 1207 1185 2026-02-17 21:10 734 651 678 757 695 2026-02-17 21:15 641 558 649 652 689 2026-02-17 21:20 635 529 637 627 585 2026-02-17 21:25 714 754 761 776 684 2026-02-17 21:30 551 609 586 539 592 2026-02-17 21:35 261 346 314 361 275 2026-02-17 21:40 232 218 208 230 209 2026-02-17 21:45 1471 1479 1532 1565 1528
21. 21 chronyやntpd、定期実⾏(cron)ではない︖ IPアドレス毎に24hに送ってきたリクエスト数をグラフ化 • 縦軸︓ホスト数 • 横軸︓リクエスト数 • ⾚点線︓リクエスト数が2のn乗を⽰す補助線 • 緑点線︓リクエスト数がn時間に1回を⽰す補助線 1024s間隔でリクエストを送ってくるIPアドレス (chrony/ntpd︖) n時間毎にリクエストを送ってくるIPアドレス
22. 22 何が起こっているのか︖ • AWSからの多数のアクセス、常時流れるトラフィック、なんらかの理由で増減、... • chronyやntpdからのアクセス、cronではない • いまどきのEC2で仮想ホストに普通にOS(例えばubuntu)をインストールすると、chrony やntpdはAmazon Time Sync Serviceと同期する • EC2を使っているユーザーが構築した何かが起因︖ • NATの裏側にいる︖ • 少量だがICMP port unreachableが返ってくるのはNATテーブルが溢れてる︖ • 定期的ではない、何かのイベントをトリガーに動作︖ • 時刻同期ではなく時刻情報取得︖ • ntpdateのようなコマンド、もしくはPythonやJavaScript、コンテナ的なもの︖ • 我が家へのアクセスはpool.ntp.org全体から⾒たらごく少量 • 我が家の出現率は0.8%弱 • このようなNTPアクセスをしているAWS上の『何か』からpool.ntp.org全体 に送られているリクエストはめちゃ多い︖︕ 回数 パケット数 1 13395 2 16746 3 13824 4 8422 5 4138 6 1685 7 597 8 157 9 69 10 17 11 1 ランキング1位ホスト のリクエストパケット の送信元ポート番 号出現回数とパ ケット数
23. 23 仮説とその場合の問題点 • 仮説︓ • あるユーザーがAWS上で、イベント駆動型のマイクロサービス的な実装を⾏っている • Lambda? Fargate? • このマイクロサービスは、イベント発⽣時に起動し、処理完了後に即終了する構成である • 処理の中で時刻情報(例︓署名検証、タイマー、ログ整合性等)が必要 • 時刻情報の取得⽅法としてpool.ntp.orgを直接参照している︕ • マイクロサービスが起動し時刻情報を取得するために使⽤するNTPサーバー (pool.ntp.org)は常に同じサーバーとは限らないため、システムの構成要素間で時刻 のズレが発⽣している可能性がある • 少量だがICMP port unreachableが返ってくることから時刻情報が取得できていない場合も︖ • pool.ntp.orgは(善意の)第三者が運⽤しているが、システム設計者がそのシステムの 重要な構成要素である『時刻』を結果として第三者に丸投げしている • 嘘の時刻を突っ込まれたら︖時刻を改竄されたら︖ • おまけ︓トラブルが起こった場合にいかにも原因を⾒つけにくそう • たまに起こる、ほとんどの場合はうまくいく、再起動したらOK...
24. 24 どうすべきなのか︖ • ⾃ネットワーク内の時間を正確に保ち、且つ全体を統⼀ a. AWS内の時刻情報を使う • ⽤意されている関数(例︓Date.now())を使う • Amazon Time Sync Serviceを直接参照 • 主要クラウド事業者は時刻同期サービスを無料で提供している • Amazon Time Sync Serviceは我が家のNTPサーバーより圧倒的に正確で堅牢w b. ⾃ネットワーク内にNTPサーバーを⽴てる • 複数の信頼できる同期先を3つ以上参照 • 参照︓なぜNTPサーバーの同期先は3台以上必要なのか • https://qiita.com/tanyorg/items/58488e030a89c77e6411 • ⾃ネットワーク内のホストはそのNTPサーバーを参照 • これはAWS固有の問題ではない︕ • どのクラウドでもオンプレでも起こりうるシステムの作り⽅そのものの問題
25. 25 まとめ • pool.ntp.orgに参加、それなりにアクセスがあって楽しい • ⼤学の研究室などでやると楽しいかも︖ • リソースが少ない安価なPCでも⼗分に動く • リクエストトラフィックをpool.ntp.org側のパラメータである程度調整できそう • ⾃宅でもできるよ︕ • トラフィック解析するとAWS⽅⾯からの多数のアクセスが︕︕ • 『イベント駆動 × 短命プロセス × 時刻取得』という構造問題の可能性 • (仮説が正しいとすると)これはAWS固有の問題ではなく、システムの作り⽅そのものの問題 • システム全体で考える時刻のあり⽅ • システムの重要な構成要素である『時刻』 • 『正確な時刻』と『システム全体の時刻の統⼀』 • 第三者がネットワーク経由で(無料)提供する機能の使い⽅ • ベンダーやメーカーの倫理、実装のマナー、利⽤者の倫理 • AWSに詳しい⼈がいらっしゃったら教えてください︕ • 『マイクロサービス的な何か』という推測について
26. 26 本分析にあたって笠原義晃先⽣(九州⼤学)に 技術的なアドバイスをいただきました。 厚くお礼申し上げます。