Кратко

  • В доступном исследовательском пакете нет подтверждённой последовательности отказа, изъятия маршрута, восстановления, переключения трафика или влияния на уровень сервиса для AS210860.
  • Данные RIPEstat, IODA, RIPE Atlas, PeeringDB, RIPE и маршрутизаторов могут построить проверяемый тест непрерывности, но ни один из этих слоёв по отдельности не доказывает операционный контроль DFINFRA.

Вопрос непрерывности начинается с временной цепочки

Для утверждения о непрерывности сети недостаточно увидеть автономную систему в реестре или зафиксировать её присутствие в таблицах маршрутизации. Нужна последовательность, где каждое звено подтверждается отдельным типом наблюдения: маршрут исчезает или деградирует в определённый момент; независимый источник показывает изменение доступности; затем маршрут объявляется вновь либо меняется путь; после этого есть свидетельство действия оператора или другой проверяемый операционный документ.

Именно такой тест отделяет инфраструктурный факт от предположения. История маршрутизации RIPEstat может показать интервалы видимости префиксов, связанных с AS210860, через участвующие коллекторы: https://stat.ripe.net/data/routing-history/data.json?resource=AS210860. Поток BGP-обновлений может уточнить, были ли в найденном интервале объявления или изъятия маршрутов: https://stat.ripe.net/data/bgp-updates/data.json?resource=AS210860. Но ни один из этих источников не превращает отсутствие наблюдения у части коллекторов в доказательство глобального отказа.

Коллектор видит не интернет в целом, а конкретную перспективу наблюдения. На результат влияют география, политика сбора, фильтрация, время обновления и состояние соседних сетей. Поэтому утверждение «AS210860 исчезла из маршрутизации» требует осторожной формулировки: корректнее говорить о потере видимости в определённом наборе наблюдений, если более широкая и независимая проверка не проведена.

Что можно проверить по независимым слоям

IODA может дать дополнительный сигнал об изменениях маршрутизации или активного измерения, однако его покрытие и чувствительность к конкретной автономной системе требуют отдельной проверки: https://ioda.inetintel.cc.gatech.edu/asn/210860. Это полезный независимый слой, но не автоматическое доказательство недоступности сервисов. Потеря маршрута, потеря ответов на измерительный сигнал и недоступность приложения — разные события.

Первый практический шаг — определить набор префиксов и временные границы. Данные об объявляемых префиксах RIPEstat помогают установить, какие адресные блоки связаны с наблюдаемыми объявлениями AS210860: https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS210860. Сведения о соседях ASN показывают, какие внешние связи видны в выбранном источнике: https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS210860. Вместе эти данные задают основу для вопроса: исчез ли конкретный маршрут, изменился ли его путь и совпало ли это по времени с независимым признаком деградации.

Следующий слой — измерения с точки зрения конечной доступности. Метаданные RIPE Atlas могут указать на наличие проб, связанных с AS210860, по IPv4 и IPv6: https://atlas.ripe.net/api/v2/probes/?asn_v4=210860 и https://atlas.ripe.net/api/v2/probes/?asn_v6=210860. Но исчезновение пробы или изменение её результата не равно отказу всей автономной системы. Проба может быть отключена, перемещена, отфильтрована или потерять связь по причине, не связанной с остальной сетью.

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

Топология не равна доказанному резервированию

PeeringDB может дать контекст о сетевых связях, присутствии и заявленной инфраструктуре: https://www.peeringdb.com/api/net?asn=210860&depth=2. Реестровая запись RIPE для AS210860 и связанные объекты маршрутов могут уточнить административные и технические атрибуты: https://rest.db.ripe.net/ripe/aut-num/AS210860.json и https://rest.db.ripe.net/search.json?query-string=AS210860&type-filter=route&type-filter=route6&flags=no-referenced. BGP.tools, CAIDA AS Rank и Hurricane Electric предоставляют дополнительные представления о маршрутах, соседях и топологии: https://bgp.tools/as/210860, https://asrank.caida.org/asns/210860, https://bgp.he.net/AS210860.

Такие источники полезны для построения карты потенциальных путей. Например, несколько наблюдаемых соседей могут указывать на возможную многосвязность. Но топологическое разнообразие ещё не доказывает, что резервирование действительно сработало во время инцидента. Для этого нужно увидеть событие: один путь перестал быть доступен, другой был объявлен или стал предпочтительным, а независимое измерение показало сохранение либо восстановление доступности.

Здесь особенно важно не смешивать три утверждения:

  1. у автономной системы есть внешние связи;
  2. у неё есть техническая возможность использовать альтернативный путь;
  3. альтернативный путь действительно поддержал сервис во время конкретного отказа.

Первое может следовать из топологических данных. Второе — из сочетания маршрутов, политики и конфигурации, если эти сведения доступны. Третье требует временного события и независимых измерений. В текущем пакете третье утверждение не установлено.

Почему реестр не определяет того, кто восстановил сеть

Связь DFINFRA с AS210860 остаётся исследовательским сигналом, а не самостоятельным доказательством владения, эксплуатации или коммерческого контроля. Реестр, IRR, PeeringDB и публичные карты маршрутизации помогают найти объект и сформировать гипотезу атрибуции. Они не отвечают на вопрос, какая организация обнаружила инцидент, кто принял решение о переключении или кто восстановил объявление.

Даже если в будущем будет найдено исчезновение маршрута и последующее объявление, это ещё не свяжет событие автоматически с DFINFRA. Для атрибуции потребуется независимое подтверждение: публикация оператора, технический журнал, сообщение поставщика, регуляторный документ или согласующаяся совокупность наблюдений. В противном случае корректный вывод должен оставаться ограниченным: маршрут изменился у AS210860; причина и ответственный оператор не установлены.

Что текущий пакет устанавливает

Текущие материалы не содержат зафиксированных динамических ответов, поэтому исследование не устанавливает конкретную аварию, временную метку изъятия маршрута, момент восстановления, путь переключения, прекращение работы пробы или влияние на пользовательский сервис. Это не отрицание того, что инцидент мог произойти. Это граница того, что можно утверждать по сохранённым данным.

Такая граница важна и для оценки риска. Наличие автономной системы и нескольких потенциальных соседей может быть релевантно для анализа устойчивости. Но без временной цепочки нельзя сказать, что сеть пережила отказ, что DFINFRA контролировала восстановление или что клиенты не заметили перебой. Нельзя также преобразовывать административную ассоциацию в утверждение о коммерческой выгоде.

Публичная страница DFINFRA служит контекстом для объекта и не заменяет технические доказательства: https://btw.media/ru/directory/dfinfra. Для читателя это означает, что справочная запись помогает связать расследование с конкретной сущностью, но не расширяет доказательную силу маршрутизирующих и реестровых источников.

Следующий проверяемый тест

Наиболее полезное продолжение расследования должно начинаться не с новой формулировки о контроле, а с поиска конкретного временного окна. Сначала нужно получить историю видимости и определить необычный интервал. Затем — проверить BGP-обновления на наличие изъятия и повторного объявления. После этого следует сопоставить изменения с IODA или иным независимым измерением, проверить результаты RIPE Atlas и сравнить наблюдаемые пути до и после события.

Только после такой корреляции возникает вопрос об операторе. Если в тот же период есть сообщение о переключении, изменение политики маршрутизации и согласующийся технический след, можно осторожно обсуждать механизм восстановления. Если же есть только исчезновение у одного коллектора, вывод должен быть уже: наблюдалась локальная потеря видимости, а не доказанный отказ сети.

Эта последовательность также показывает, где находится реальная инфраструктурная власть. Контроль — это не только регистрационное имя. Он проявляется в способности объявлять префиксы, менять внешние пути, поддерживать резервирование, обнаруживать деградацию и выполнять восстановление. Каждая из этих способностей оставляет отдельный класс следов. Пока эти следы не соединены, утверждение о контроле остаётся гипотезой.