Nejprve něco málo z historie: pro synchronizaci času v sítích TCP/IP se původně používal protokol, nazvaný jednoduše time protocol, definovaný v RFC 868. Použití bylo jednoduché: klient navázal spojení na příslušný TCP port, případně poslal prázdný packet na příslušný UDP port. Server pak odpověděl přesným časem. Standardní přístup pro synchronizaci času UNIXových serverů pak byl, že jednou za den (například z /etc/cron.daily) si počítač srovnal čas příslušným časovým serverem. Pro většinu použití toto zaručovalo přesný čas na počítačích v toleranci jednotek sekund.
Potřeba něčeho přesnějšího v naší síti vyvstala s instalací druhé generace aplikačních serverů ISu začátkem tohoto tisíciletí :-). Ukázalo se, že tyto stroje měly interní hodiny natolik nepřesné, že se během 24 hodin navzájem rozešly i o deset sekund. Toto dělalo problémy při hromadných časových soutěžích o registraci předmětů nebo zápis do seminárních skupin, běžících typicky od 17:00:00. Proto jsme zavedli interní server s protokolem NTP, který již poskytuje přesnost v řádu desítek milisekund. Náš server je synchronizován vůči několika dalším serverům v Česku i v zahraničí. Tyto servery mají buďto hardwarový zdroj přesného času, jako například atomové hodiny v Ústavu jaderné fyziky AV ČR v Řeži u Prahy, anebo jsou synchronizovány pomocí přijímačů signálu GPS jako servery tik.cesnet.cz a tak.cesnet.cz.
Službu přesného času také nabízíme veřejně: proti našemu časovému serveru je možno synchronizovat svůj počítač odkudkoli v Internetu. Navíc jsme se zapojili do celosvětového projektu NTP Pool, který sdružuje takovéto veřejné NTP servery. Pomocí protokolu DNS je zpřístupňuje klientům s tím, že mimo jiné monitoruje dostupnost a přesnost těchto serverů a umožňuje klientům nabízet přednostně ty servery, které jim jsou z hlediska topologie sítě bližší.
Protokol NTP je citlivý na zpoždění sítě, proto je realizován výhradně nad nespojovanou transportní vrstvou UDP. To s sebou mimo jiné nese možnost zneužití veřejně dostupného NTP serveru pro distribuovaný útok na odepření služby (DDoS) pomocí odrážení NTP packetů zaslaných serveru z podvržené IP adresy oběti. Historicky NTP umožňoval zesílení síťového provozu až na několik stonásobků původního objemu dat (podrobnosti například v blogu CloudFlare). Tento problém jsme stejně jako mnoho ostatních veřejných NTP serverů poprvé zaznamenali ve druhé polovině roku 2013.
Čas od času se podobně jako jiní členové NTP Poolu potýkáme s tím, že monitoring poolu vyhodnotí náš server jako špatně dostupný a dočasně jej z poolu vyřadí. Na členovi poolu je pak zjišťovat, kde je co špatně. Pokud tušíme problém mimo naši síť, je dobré se porozhlédnout po okolí: jestli NTP Pool hodnotí jinak dostupnost našeho serveru po IPv4 než po IPv6, jestli je problém vidět i na alternativním monitorovacím systému, a případně jestli podobný pokles kvality zaznamenávají další členové poolu v blízkém síťovém okolí (například servery AV ČR, MFF UK nebo CESNETu).
Zhruba od začátku letošního roku nám začaly zprávy o vyřazení z poolu z důvodu nedostupnosti chodit poměrně často, i když lokálně se zdálo, že je se serverem všechno v pořádku. Tento problém jsme řešili poměrně dlouho, protože časová koincidence s okolními členy poolu nebyla až tak prokazatelná a problém se týkal jen IPv4. Nakonec se ale přece jen ukázalo, že jde o společný problém, který pak v CESNETu vyřešili vynucením směrování sítě, ze které NTP Pool dělá monitoring, přes jednu konkrétní zahraniční linku. Na grafu počtu IPv4 NTP packetů za minutu je vidět nerovnoměrnost cca od prosince 2019 do poloviny května 2020, kdy došlo k nápravě.
Přesnou příčinu problému není jednoduché zjistit. Předpokládáme, že na vině je příliš agresivní detektor DDoS útoků v některé síti mezi CESNETem a monitoringem NTP Poolu. Může to být tak, že pokud někde zaznamenají větší množství NTP odpovědí od jedné IP adresy, začnou tyto odpovědi na nějakou dobu zahazovat. Dostupnost našeho NTP serveru pak záleží na tom, kolik NTP klientů za touto mezilehlou sítí náš NTP server používá, a ve kterých časech se ptají (NTP klienti se typicky dotazují několika dotazy krátce po sobě každých 15 minut).
Tato epizoda je poučením, že Internet už dávno není takové neutrální a transparentní prostředí, kde každý může komunikovat s každým nezávisle na protokolech vyšších vrstev. Realita je taková, že komunikace na některých portech může "magicky" ztrácet i mimo koncové sítě, i když "základní" protokoly jako je ping nebo HTTP fungují.
Zájemcům o problematiku sítí doporučujeme k dalšímu studiu článek The world in which IPv6 was a good design, ve kterém se autor zamýšlí nad historií a současností síťových protokolů různých vrstev, adresací v nich, od Ethernetu a IPv4 až po IPv6 a moderní protokol QUIC.
