РКН блокирует миллионы IP: реестр зависимостей от SaaS и облачных API

Несколько дней прошло с начала масштабных блокировок, и у нас накопилось достаточно наблюдений, чтобы перейти от пожаротушения к чему-то более системному. Первый пост про экстренный перенос workloads был про то, что мы делали в первые часы. Этот - про то, что выявилось за следующие дни.

Главный сюрприз оказался не там, где мы ожидали.

Не AWS пострадал, а всё, что на нём живёт

Когда говорят «заблокировали AWS» - имеют в виду конкретные подсети EC2 и CloudFront. Но бизнес клиентов завязан не только на собственные инстансы. Он завязан на десятки сторонних SaaS-сервисов, которые сами хостятся на AWS, GCP или Cloudflare - и которые тоже оказались в зоне поражения.

Схема та же: сторонний вендор живёт на AWS us-east-1, его подсеть попала в реестр РКН, продукт недоступен из российских офисов. Вендор даже не знает об этом - у него всё зелёное, пользователи из Европы ходят нормально.

За несколько дней мы зафиксировали конкретные категории потерь у клиентов:

• Мониторинг и алертинг. Несколько клиентов используют облачные инструменты - Status Page от Atlassian, внешние Grafana Cloud-дашборды, PagerDuty. Часть из них хостится на инфраструктуре, попавшей под блок. Алерты уходили, но веб-интерфейс для дежурного был недоступен.
• CI/CD и артефакты. GitHub и npm-registry в первые дни вели себя нестабильно у части провайдеров. Пайплайны зависали на pull зависимостей. Не у всех и не всегда - но предсказать было нельзя.
• Платёжные шлюзы и фрод-сервисы. Один клиент обнаружил, что сторонний антифрод-провайдер недоступен из его бэкенда - и транзакции начали падать с таймаутом. Сервис был второстепенным, но код не был готов к его отсутствию.
• CDN для статики. Cloudflare в большинстве случаев работает - у него своя AS и собственные IP-диапазоны, под массовую блокировку не попал. Но у одного клиента часть статики лежала на CloudFront, а не на Cloudflare - это выяснилось только когда у сотрудников перестали грузиться изображения в корпоративном портале.
• SaaS для команды. Jira Cloud, Confluence Cloud, Slack - у Atlassian и Slack своя инфраструктура и свои IP, они работали. Но не все клиенты это проверяли: паника «всё упало» начиналась раньше диагностики.

Что мы сделали: реестр зависимостей

По итогу первых нескольких дней стало очевидно: ни мы, ни клиенты не имеем полной картины внешних зависимостей. Это не упрёк - никто особо не думал об этом как о риске. Теперь думаем.

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

Структура простая: для каждого сервиса фиксируем, что это такое, где хостится (AS, страна, облачный провайдер), как приложение ведёт себя при его недоступности, и есть ли fallback.

Сервис          | Провайдер   | AS / регион        | Поведение при отказе
----------------|-------------|--------------------|-----------------------
Stripe          | AWS         | us-east-1          | платежи падают с 503
Datadog agent   | Datadog LLC | собственная AS     | метрики буферятся
npm registry    | Fastly CDN  | Fastly AS (работ.) | пайплайн зависает
Atlassian Cloud | AWS         | us-east-1          | таски недоступны
SendGrid        | AWS         | смешанная          | письма встают в очередь

Это не красиво, зато честно показывает где болит. Для большинства клиентов оказалось, что они плохо понимают даже первую колонку - что именно у них внешнее.

Что дальше неясно

Ситуация продолжает меняться. РКН добавляет подсети, потом отдельные диапазоны выпадают из реестра - либо намеренно, либо потому что Telegram там уже нет. Провайдеры применяют блоки с разной скоростью и разной точностью. Некоторые блокируют шире реестра «на всякий случай», другие опаздывают.

Несколько вещей, которые мы сейчас не знаем и не можем предсказать:

• Когда РКН остановится с расширением блоков - или не остановится.
• Будет ли давление на Amazon и Google добавить BGP-анонсы специально для России.
• Насколько провайдеры будут аккуратны при снятии блоков, когда (если) ситуация разрядится.

Реестр зависимостей сам по себе не решает проблему - он только показывает, где у каждого клиента незащищённые точки. Что с этим делать дальше: переносить критические части в российскую инфраструктуру, добавлять graceful degradation в код, договариваться с вендорами об альтернативных эндпоинтах - это уже отдельный разговор с каждым.

Но без реестра этот разговор не начать. Поэтому начали с него.