ntp服务器高效配置与同步指南
最近帮客戶處理CDN節點時間漂移問題，踩了不少坑。當邊緣伺服器時間差超過500毫秒，TLS握手直接失敗，用戶看到的就是一片空白頁面。這行幹久了才明白，NTP配置根本不是設個pool.ntp.org就能了事的活兒。
先說硬體時鐘這老傢伙。上個月某客戶的東南亞節點頻繁時間回跳，查了三天發現是主機板電池沒電。你可能覺得可笑，但全球分散式架構裡，這種破事每年至少遇到兩回。現在我們強制在監控告警加上了BIOS時鐘電壓檢測，畢竟節點重啟時若沒網路同步，全靠這玩意撐著。
真正的戰場在於分層架構設計。曾經迷信過直接對接time.cloudflare.com這類公共源，直到南美節點在總統就職演說時集體抽風——當地運營商把NTP流量當DDoS給攔了。血淚教訓是：核心層必須有兩台本地Stratum 1伺服器，用GPS和銣鐘雙源，再透過專線同步到區域節點。公共源？那只是最後的backup。
防火牆策略比你想像的狡猾。UDP 123端口全開根本不夠，有些老設備會走隨機高端口發送NTP控制報文。去年某次DDoS演練，防禦系統把NTP流量當反射攻擊給清洗了，結果整個東亞CDN網域時間全亂套。現在我們在邊緣節點固定使用123和319-321端口，還得在防禦規則裡打白名單。
遇到最陰險的是閏秒事件。2017年元旦某頂級CDN商全球節點CPU飆到90%，就因為沒部署ntpd -x的slew模式。當時我們在閏秒前72小時啟動漸進式調整，每千秒微調幾毫秒，監控圖上看像條平滑曲線。事後復盤，那些直接跳秒的節點，日誌時間戳全亂了套，連故障時間軸都拼不回來。
監控切忌只看時間差。現在我們自研的探針會同時檢測時鐘漂移率（clock drift rate），某次就抓到批伺服器每小時慢15毫秒。拆機發現是散熱不良導致晶振頻偏，這種溫飄問題用普通ntpq監控根本抓不出來。
最後分享個血腥案例：某金融客戶的CDN節點曾遭NTP反射攻擊，攻擊者偽造來源IP指向其NTP伺服器。當時緊急啟用了restrict default noquery配合disable monitor，但真正治本的是在邊緣設備啟用BCP38源地址驗證。現在看NTP伺服器日誌裡還留著當年的攻擊痕跡——每秒12萬個畸形報文，硬碟寫入量比DDoS清洗中心還高。
時間同步這玩意，平時沒人在意，出事就是全鏈路崩潰。前幾天東京機房搬遷，新上的節點因為NTP服務沒調優，導致HSTS過期時間計算錯誤。用戶被強制跳轉https失敗時，沒人會想到是牆上掛的時鐘出了問題。
评论: