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

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

Transcript

1. pool.ntp.orgに ⾃宅サーバーで 参加してみたら... 2026/2/13 TS-OPS BoF(JANOG 57) Fuminori –Tany- Tanizaki
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 はじめる前に... • これは個⼈の活動です • 資料はのちほど公開します • 後半でAWSの話がでてきますが... • わたしはAWSは全く詳しくありません︕詳しい⽅、ぜひアドバイスをお願いします︕ • 『トラフィックが多いからアクセスを⽌めろ︕』という話ではありません︕!
4. 4 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を問い合わせた 際、あるルールに基づいて振り分け • GeoDNSによるGeoIP的評価 • 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 %
5. 5 なぜpool.ntp.orgに参加しようと思ったか︖ • ⾃宅にGNSS/PPSなStratum1がたくさん • Raspberry Pi 3 x 1 • FC-NTP-MINI x 2 (アプライアンス) • TF-NTP-LITE x 1 (アプライアンス) • TZT ZG802-01 NTP Time Server x 1 (アプライアンス) • PCとRaspberry Pi 3で作ったStratum1がそれなりに⾼精度 • 上記アプライアンスの精度調査ができた • 精度に問題があるアプライアンスのおかげで、chronyやntpdの動作がよく理解できたw • 新しい遊びはないかな︖ 『せや︕pool.ntp.orgに参加してみよ︕!』 『とりあえずサーバーをなんか買っとこw』
6. 6 GNSSアンテナは南向きの窓に設置 ⾃宅のStratum1たち 精度に問題あり GNSS/PPS同期のRaspberry Pi 3
7. 7 ⼊⼿したサーバー • 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
8. 8 ⽅針と設計 • ⾃宅固定IPv4アドレスを使って外部に公開 • ⾃宅ネットワークに影響がないようにしたい • 受けるNTPリクエストはほどほどで • 公開するNTPサーバーはstratum2 • ⾃宅にあるstratum1(GNSS/PPS同期)は⼤切な時刻源なので外にはださない • 公開するstratum2サーバーは、⾃宅内のstratum1や外部の公開NTPサーバーと同 期させ、時刻源の冗⻑性を確保 • OS︓Ubuntu 24.04 LTS • ソフトウェアはchronyを選択 • 設定がわかりやすく、機能がntpdより多い(例︓maxdistance、clientloglimit...) • 再起動時の収束が早い • モニタリング機能(chronyc)が豊富 • Prometheus/Grafanaとの親和性が⾼い
9. 9 チューニング -1- • ポイント • 可能な限り、パケットを取りこぼさない • NTPの処理を最優先、遅延と揺らぎを抑える • とはいえ、頑張りすぎない • ネットワーク︓冗⻑性の確保、サービストラフィックと管理トラフィックの分離 • サービス⽤︓NIC x 2 を bond0(Active/Standby)で設定 • 管理トラフィック︓USBイーサーネットアダプタ経由に固定 • OS︓ネットワーク遅延と揺らぎの原因を排除 • /etc/default/grub = 電⼒監視無効、通常プロセスはCPU1を使わない • intel_idle.max_cstate=0 processor.max_cstate=0 isolcpus=1 • /etc/sysctl.conf = ネットワーク関連のバッファを拡⼤ • /etc/rc.local = IRQ毎にCPUを指定、CPUは常に最速の周波数で動作 /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 /etc/rc.local echo 1 > /proc/irq/93/smp_affinity echo 2 > /proc/irq/94/smp_affinity echo 2 > /proc/irq/92/smp_affinity echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
10. 10 チューニング -2- (chrony) • chronydのリアルタイムスケジュールの 優先度をあげる(あげすぎはダメ) • chronydをmlock() • 主同期先はhome-ntp-v6 • 強く信⽤ • ⾼頻度で同期 • IPv6で同期させると、Reference IDが ハッシュ値に︕つまり⾃宅stratum1の IPv4アドレスがバレないw • ratelimitはほどほど且つゆるめ • interval 0︓制限をかける最⼩間隔を 2^0=1秒に設定 • burst 64︓⼀時的な連射枠は64発、そ れ以上は破棄 • leak 4︓連射枠は1秒に4個復活 /etc/chrony/chrony.conf cmdallow 127.0.0.1 cmdallow ::1 rtcsync sched_priority 1 lock_all server home-ntp-v6 iburst prefer trust minpoll 4 maxpoll 6 xleave server home-ntp-01 iburst server home-ntp-02 iburst server home-ntp-03 iburst server home-ntp-04 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
11. 11 監視/計測 • 監視︓ポイントを押さえて、楽にやりたい • uptime kumaにNTP監視機能を追加し、githubで公開 • https://github.com/tanyorg/uptime-kuma-mon • 計測︓かっこいいグラフを描きたいw • Prometheus + Grafana + (chrony-exporter, ntp-exporter) 監視システムの時計とそのNTPサーバーとの時刻のずれ 緑︓GNSS/PPS同期のラズパイ、⾚は精度に問題があるアプライアンス uptime-kuma-mon
12. 12 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
13. 13 実際のトラフィック クライアントからのアクセスがある︕サービス提供はやっぱりたのしい︕︕ ところで、どこからアクセスがあるんだろう︖
14. 14 どこからアクセスが︖ ASN Requests Organization AS16509 8291403 AMAZON-02 - Amazon.com, Inc., US AS4134 3682775 CHINANET-BACKBONE No.31,Jin-rong Street, CN AS9808 3472211 CHINAMOBILE-CN China Mobile Communications Group Co., Ltd., CN AS4713 2949099 OCN NTT DOCOMO BUSINESS,Inc., JP AS4837 2904255 CHINA169-BACKBONE CHINA UNICOM China169 Backbone, CN AS2516 1744053 KDDI KDDI CORPORATION, JP AS17676 1407275 GIGAINFRA SoftBank Corp., JP AS9605 726980 DOCOMO NTT DOCOMO, INC., JP AS56040 549032 CMNET-GUANGDONG-AP China Mobile communications corporation, CN AS2527 448101 SO-NET Sony Network Communications Inc., JP others 8647832 Remaining 6,918+ ASNs TOTAL 34823016 期間︓2026/1/29 18:43〜2026/1/30 18:50 分析⽅法︓以下で取得したpcapを元に送信元IPv4アドレスをAS番号毎に集計 取得⽅法︓tcpdump -i bond0 -nn -s 150 -W 24 -C 1200 ¥ -w ./ntp_icmp_24h.pcap ¥ "udp port 123 or (icmp and (icmp[icmptype] == 3))" • ある24時間をパケットダンプし解析 • 3500万弱のリクエスト数の23.8%が AWS(AS16509)からのアクセス︕ • なんで︖︕
15. 15 詳細解析 • 送信元IPアドレスを元にリクエスト数ランキングTOP100をやってみたら、 AWSのIPアドレス(AS16509)が独占 • 最も多いホストは⼀⽇に16万リクエスト弱 • リクエストに対してICMP port unreachableが0.2%返ってくる • TOP100の逆引きを調べると以下の通り • ec2-*-*-*-*-ap-northeast-1.compute.amazonaws.com︓83 • ec2-*-*-*-*-ap-northeast-3.compute.amazonaws.com︓15 • 独⾃ドメインのFQDN(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%弱 IPv4 address request 13.231.*.* 159,084 35.79.*.* 156,531 57.181.*.* 156,231 35.73.*.* 154,396 18.182.*.* 154,324 18.176.*.* 153,898 52.193.*.* 153,735 57.180.*.* 153,654 43.206.*.* 153,622 18.181.*.* 152,894 IPアドレス毎の NTPリクエスト数ベスト10
16. 16 AWSからのNTPリクエスト • ランキング1位から5位のホストのリク エスト数を5分毎にグラフ化 • 傾向が同じ︖︕ DateTime IP1 IP2 IP3 IP4 IP5 2026-01-29 18:40 104 117 132 105 118 2026-01-29 18:45 313 323 375 297 336 2026-01-29 18:50 395 363 442 434 303 2026-01-29 18:55 2770 2431 2645 2629 2417 2026-01-29 19:00 417 574 527 591 546 2026-01-29 19:05 532 579 699 673 591 2026-01-29 19:10 432 443 434 390 467 2026-01-29 19:15 755 835 660 739 774 2026-01-29 19:20 468 478 422 345 464 2026-01-29 19:25 493 568 462 527 605 2026-01-29 19:30 612 595 550 628 566 2026-01-29 19:35 682 584 592 617 720 2026-01-29 19:40 494 490 549 540 509 2026-01-29 19:45 584 670 703 706 585 2026-01-29 19:50 889 763 710 750 703 2026-01-29 19:55 1387 1310 1289 1430 1283 データより⼀部抜粋
17. 17 chronyやntpd、定期実⾏(cron)ではない︖ IPアドレス毎に24hに送ってきたリクエスト数をグラフ化 • 縦軸︓ホスト数 • 横軸︓リクエスト数 • ⾚点線︓リクエスト数が2のn乗を⽰す補助線 • 緑点線︓リクエスト数がn時間に1回を⽰す補助線 1024s間隔でリクエストを送ってくるIPアドレス (chrony/ntpd︖) n回/1⽇リクエストを送ってくるIPアドレス
18. 19 何が起こっているのか︖ • AWS、常時流れるトラフィック、なんらかの理由で増減、多数のアクセス... • chronyやntpdからのアクセス、cronではない • いまどきのEC2で仮想ホストに普通にOS(例えばubuntu)をインストールすると、 chronyやntpdはAmazon Time Sync Serviceと同期する • EC2を使っているユーザーが構築した何かが起因︖ • NATの裏側にいる︖ • 少量だがICMP port unreachableが返ってくるのはNATテーブルが溢れてる︖ • 定期的ではない、何かのイベントをトリガーに動作︖ • 時刻同期ではなく時刻情報取得︖ • ntpdateのようなコマンド、もしくはPythonやJavaScript、コンテナ的なもの︖ • このような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位ホスト のリクエストパケット の送信元ポート番 号出現回数とパ ケット数
19. 20 仮説とその場合の問題点 • 仮説︓ • あるユーザーがAWS上で、イベント駆動型のマイクロサービス的な実装を⾏っている • このマイクロサービスは、イベント発⽣時に起動し、処理完了後に即終了する構成である • 処理の中で時刻情報(例︓署名検証、タイマー、ログ整合性等)が必要 • 時刻情報の取得⽅法としてpool.ntp.orgを直接参照している︕ • マイクロサービスが起動し時刻情報を取得するために使⽤するNTPサーバーは常に同じものとは限らない。 その結果、システムの構成要素間で時刻のズレが発⽣している可能性がある • 少量だがICMP port unreachableが返ってくることから時刻情報が取れていない場合も︖ • pool.ntp.orgは(善意の)第三者が運⽤しているが、システム設計者がそのシステムの重要な構成要素で ある『時刻』を結果として第三者に丸投げしている • 嘘の時刻を突っ込まれたら︖時刻を改竄されたら︖ • おまけ︓トラブルが起こった場合にいかにも原因を⾒つけにくそう • たまに起こる、ほとんどの場合はうまくいく、再起動したらOK...
20. 21 どうすべきなのか︖ • ⾃ネットワーク内の時間を正確に保ち、且つ全体を統⼀ 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固有の問題ではない︕ • どのクラウドでもオンプレでも起こりうるシステムの作り⽅そのものの問題
21. 22 まとめ • pool.ntp.orgに参加、それなりにアクセスがあって楽しい • ⼤学の研究室などでやると楽しいかも︖ • リソースが少ない安価なPCでも⼗分に動く • リクエストトラフィックをpool.ntp.org側のパラメータである程度調整できそう • ⾃宅でもできるよ︕ • トラフィック解析するとAWS⽅⾯からの多数のアクセスが︕︕ • 『イベント駆動 × 短命プロセス × 時刻取得』という構造問題の可能性 • (仮説が正しいとすると)これはAWS固有の問題ではなく、システムの作り⽅そのものの問題 • システム全体で考える時刻のあり⽅ • システムの重要な構成要素である『時刻』 • 『正確な時刻』と『システム全体の時刻の統⼀』 • AWSに詳しい⼈がいらっしゃったら教えてください︕ • 『マイクロサービス的な何か』という推測について
22. 23 本分析にあたって笠原義晃先⽣(九州⼤学)に 技術的なアドバイスをいただきました。 厚くお礼申し上げます。