Telstra: сбой GPS-времени отправил её сеть в 2006 год и оборвал связь

8 июля 2026 года крупная часть мобильной сети Telstra, крупнейшего оператора связи Австралии, перестала работать: не проходили голосовые звонки и SMS, не дозванивались до экстренного номера, сбоили поезда, платёжные терминалы, билетные системы и зарядные станции для электромобилей. Сеть никто не атаковал, кабель никто не резал, электропитание было в норме. Причину нашёл независимый аудит, который заказала сама Telstra у компании Technology Audit Partners (TAP): единственный GPS-приёмник в одном шасси в Мельбурне, включившись после планового обслуживания, решил, что на дворе ноябрь 2006 года, и убедил в этом остальную сеть.

Мобильная связь стандарта 5G в Австралии (как и шведский диапазон 3,5 ГГц) построена на разделении по времени (TDD): все базовые станции по очереди переключаются между приёмом и передачей в одном и том же частотном блоке, и для этого им нужно совпадающее до микросекунд представление о том, который сейчас час. Точное время в сети Telstra распространялось протоколом NTP, который строит иерархию уровней (страт): страт 0, эталон (например, GPS-приёмник), страт 1, сервер, синхронизированный напрямую с эталоном, и так далее. По проекту 2010 года на вершине стояли эталоны Национального института метрологии Австралии (NMI), от них время получали два сервера страта 1 (в Сиднее и Мельбурне), а от них, три сервера страта 3, в Сиднее, Мельбурне и Перте. У NTP есть две независимые защиты от плохого источника времени: приоритет отдаётся источнику с более низким номером страта, а источник, чьё время расходится с большинством остальных, отбрасывается как выброс.

В 2020 году во время модернизации в Мельбурне поставили новое оборудование, и это по цепочке сломало обе защиты. Новое шасси физически не позволяло серверу страта 2 и серверу страта 3 стоять в одном корпусе, поэтому Сидней и Мельбурн перекрёстно завязали друг на друга, и на каждой площадке вместо двух независимых источников страта 2 остался один. TAP прямо пишет, что потерю резервирования тогда осознали и приняли как есть. Заодно классическую модель клиент/сервер заменили на равноправную (пиринговую), в которой узлы сами договариваются, у кого брать время; отчёт не объясняет мотив этой замены, но допускает, что ей пытались компенсировать потерянное резервирование. Пиринг открыл возможность «петли синхронизации», ситуации, когда источники, формально независимые, на деле берут время друг у друга по кругу, и вторая защита NTP перестаёт работать, потому что ей не с чем сравнивать.

В октябре 2025 года это аукнулось: сервер в Мельбурне регулярно терял связь с единственным оставшимся источником страта 1 в Сиднее. Вместо того чтобы разобраться, почему связь пропадает, инженеры включили GPS-приёмник, который простаивал в мельбурнском шасси с 2020 года, и подключили его к серверу страта 3 как замену ненадёжному сиднейскому источнику. Проблему это как будто решило, но заодно, незаметно для всех, подняло мельбурнский сервер сразу со страта 3 до страта 1: он стал источником того же ранга, что и национальный эталон NMI. К июлю 2026 года от проекта 2010 года практически ничего не осталось, а единственным самым авторитетным и никем не оспариваемым источником времени для всей сети оказалась одна GPS-плата в Мельбурне.

Второй ингредиент сбоя, известное свойство самого GPS. Спутники передают время как номер недели (10 бит, то есть максимум 1023) плюс секунды внутри недели от эпохи, начавшейся в январе 1980 года; каждые 1024 недели (19,6 года) счётчик обнуляется, это уже случалось в августе 1999-го и в апреле 2019-го. Мельбурнская плата пережила обнуление 2019 года без проблем, потому что работала без остановки и просто продолжала прибавлять недели. Но когда её выключили в 2020-м и вновь включили в октябре 2025-го, ей пришлось заново вычислять эпоху, а знать она могла только то, что заложено в прошивке. Прошивку на этой плате шесть лет не обновляли, и при старте она откатилась к устаревшей эпохе, поставив дату на 1024 недели в прошлое, то есть в ноябрь 2006 года. Первая защита NTP (приоритет низкого страта) сработала штатно и назначила самым весомым именно этот, теперь уже страт-1, источник с неверной датой. Вторая защита не сработала вовсе: сравнивать ошибочную дату было не с чем, потому что все источники, способные с ней не согласиться, к тому моменту сами оказались ниже Мельбурна в иерархии и стали лишь повторять его значение. Ни одна защита не сломалась технически, обе просто лишились того, без чего не могут работать: одной был нужен источник, действительно достойный высшего ранга, другой, источники, способные не согласиться.

Отчёт TAP отдельно отмечает: изменение в октябре 2025 года выполняли два инженера, и оба к моменту, когда последствия перезапуска GPS-платы стали понятны, уже находились на обязательном отгуле (стенд-дауне), то есть разобраться с ситуацией оказалось некому. Автор поста, сотрудник шведского национального оператора времени Netnod Свен-Кристиан «Свенне» Эбенхаг, разбирает отчёт TAP и формулирует уроки: время и синхронизацию нужно официально относить к критической инфраструктуре; вся конфигурация сети должна быть документирована и сверяться с «эталонной сборкой» в автоматическом режиме (у Telstra такой эталонной конфигурации не было вовсе); резервировать нужно не только оборудование, но и компетенции инженеров; синхронизацию времени стоит рассматривать как поверхность атаки (спутниковый сигнал слабый, не аутентифицированный и его можно заглушить или подделать дешёвым оборудованием); уведомления вендора о прошивках должны иметь ответственного и выполняться по графику, а не по факту сбоя; предпочтительна топология «точка-точка» с документированными связями, а не самоорганизующийся пиринг; аварийные оповещения должны идти в круглосуточный мониторинг с понятной степенью серьёзности, а не проверяться только в рабочие часы горсткой людей; а стареющее, но исправно работающее оборудование синхронизации нужно планово заменять, а не откладывать его модернизацию в пользу более заметных проектов. Автор отдельно хвалит Telstra за то, что компания заказала и опубликовала независимый разбор случившегося.

Ключевые факты

8 июля 2026 года у Telstra, крупнейшего мобильного оператора Австралии, отказали звонки, SMS, вызовы на экстренный номер, а также пострадали поезда, платёжные терминалы, билетные системы и зарядки для электромобилей.
Причина, один GPS-приёмник в шасси в Мельбурне: после планового отключения и включения в октябре 2025 года его не обновлявшаяся шесть лет прошивка откатила дату на 1024 недели назад, в ноябрь 2006 года.
Редизайн 2020 года уже убрал резервирование (один источник страта 1 на площадку вместо двух) и заменил модель клиент/сервер на равноправную (пиринговую), сделав возможной «петлю синхронизации».
Включение простаивавшего GPS-приёмника в октябре 2025 года незаметно подняло мельбурнский сервер со страта 3 до страта 1, уровня национального эталона времени, и его неверная дата разошлась по всей сети без сопротивления.
Независимый отчёт Technology Audit Partners называет ключевые уроки: относить синхронизацию времени к критической инфраструктуре, вести документированные эталонные конфигурации, резервировать компетенции инженеров (оба инженера, менявших схему в 2025-м, к моменту сбоя были на обязательном отгуле) и обновлять прошивки по графику, а не по факту аварии.

Почему это важно

История показывает, что даже отрасль, где протокол работает строго по спецификации, может рухнуть из-за архитектурных решений вокруг него. Современная мобильная связь (в том числе 5G-диапазоны с разделением по времени, TDD) физически не может работать без точного и единого представления о времени у всех базовых станций сразу, это осознанный компромисс отрасли в пользу временной синхронизации вместо разделения частот. Случай Telstra, редкий подробный разбор того, как одна забытая деталь (не обновлённая шесть лет прошивка на резервном оборудовании) и два по отдельности разумных решения (вынужденная перекоммутация из-за нового шасси и переход на пиринг ради резервирования) вместе убрали обе защиты протокола NTP одновременно, оставив критическую инфраструктуру страны зависимой от одной платы, за которой никто не следил.

Кому это важно

В первую очередь, инженерам и архитекторам телеком-сетей, дата-центров и любой инфраструктуры, использующей NTP или похожие протоколы синхронизации времени (PTP, GNSS-эталоны). Полезно операторам критических служб, зависящих от единого времени: платёжным системам, транспорту, энергетике. Материал также адресован тем, кто отвечает за мониторинг и эксплуатационные процессы, отчёт TAP говорит не только о протоколе, но и об организационных провалах: отсутствии документации, слабом резервировании компетенций и оповещениях, которые никто не проверял по-настоящему.

Как это применить

Отчёт TAP формулирует конкретные меры, применимые к любой инфраструктуре синхронизации времени: официально классифицировать время и частоту как критическую инфраструктуру, чтобы это определяло уровень риска изменений, глубину ревью и бюджет; документировать всю конфигурацию и держать «эталонные» (golden) сборки под версионным контролем с автоматической сверкой развёрнутого состояния; резервировать не только источники времени, но и экспертизу, чтобы после любого изменения оставался кто-то, способный оценить последствия; регулярно и по графику применять обновления прошивок поставщика вместо реакции по факту сбоя, и проверять изменения в лаборатории перед развёртыванием; предпочитать топологию «точка-точка» с явно документированными связями пиринговой модели, где сеть может незаметно перестроить сама себя; строить резервирование из источников, действительно независимых друг от друга (два сервера с одним и тем же GNSS-приёмником, это один источник, посчитанный дважды); и заводить аварийные оповещения в круглосуточный мониторинг с понятной степенью серьёзности и назначенным ответственным, а не проверять их только в рабочие часы.

Можно ли доверять

Материал написан сотрудником Netnod, шведского оператора национального эталона времени, то есть автором с профильной экспертизой именно в синхронизации времени, и опирается на независимый отчёт, который заказала и опубликовала сама Telstra у сторонней компании Technology Audit Partners. Изложение подробное, с конкретными датами, номерами уровней (страт) и техническими механизмами, а не общими словами. При этом стоит учитывать, что Netnod продвигает собственную модель (выделенные соединения «точка-точка» вместо пиринга) как коммерческий оператор эталонного времени, и в тексте это прямо звучит как рекомендация; в остальном источник, разбор реального инцидента одной командой на основе отчёта другой, независимой команды.

Риски и подводные камни

Ключевой риск истории, то, что деградация была невидимой: сеть годами исправно раздавала точное время и переставала работать резко, без предупреждения, а не постепенно. Отдельная опасность, отмеченная в самом отчёте, атака: спутниковый GPS-сигнал слабый и не аутентифицирован, его можно заглушить или подделать дешёвым оборудованием, и с точки зрения последствий для сети спуфинг выглядит так же, как описанная здесь непреднамеренная «петля синхронизации». Ещё один риск, организационный: два инженера, проводившие изменение в октябре 2025 года, к моменту, когда стали понятны последствия, уже были на обязательном отгуле, то есть в компании не осталось резерва компетенции, способного быстро разобраться в собственном же изменении.

«Петля синхронизации, это сетевой эквивалент веры в слух только потому, что о нём же спросили ещё нескольких человек, а те слышали его друг от друга.»

— Свен-Кристиан «Свенне» Эбенхаг, автор блога Netnod