Роскомнадзор блокирует Telegram: заодно кладёт AWS и GCP

13 апреля Таганский районный суд Москвы выносит решение о блокировке Telegram. Роскомнадзор обязан исполнить. 16 апреля - дедлайн. Как именно будет исполняться - мы, как и все остальные, не знаем заранее. Что у нас есть: несколько клиентов с инфраструктурой на AWS и GCP, которые вполне могут оказаться в зоне поражения, если РКН пойдёт по жёсткому сценарию.

Жёсткий сценарий наступил.

Что произошло в первые часы

Telegram мигрирует между IP-адресами быстро. РКН не гонится за конкретными адресами - он начинает блокировать подсети. Большими. Amazon и Google дали Telegram диапазоны из своих публичных пулов, и регулятор просто берёт эти пулы и добавляет в реестр запрещённых. Масштаб - миллионы IP-адресов в течение первых суток.

Побочный эффект предсказуемый, но всё равно впечатляет своей конкретностью: под блокировку попадают не только серверы Telegram, но и всё что живёт по соседству. EC2-инстансы клиентов, RDS, эластичные балансировщики - если они оказались в заблокированной подсети, доступ к ним из российских сетей пропадает.

У нас два клиента получают обрыв доступа к production-сервисам в первые несколько часов после начала блокировок.

Что мы делали

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

Первый приоритет - понять, у каких клиентов что именно пострадало. Не «AWS недоступен» как абстракция, а конкретно: какой EIP, какая подсеть, заблокирована ли она в реестре РКН. Берём актуальные списки из реестра (они обновляются несколько раз в день), сверяем с нашим инвентарём IP-адресов. Где-то - да, адрес в чёрном списке. Где-то - сеть формально не заблокирована, но провайдер клиента применяет более широкие блоки «на всякий случай».

Дальше - несколько параллельных направлений.

Elastic IP и смена адресов. Для сервисов на EC2 с EIP - пробуем переназначить адрес на другой, из незаблокированной подсети. Это работает, но ненадёжно: сегодня адрес чист, завтра РКН добавит его подсеть. Временная мера, не решение.

Перенос critical workloads в российские облака. Для двух клиентов принимаем решение экстренно поднять параллельную инфраструктуру в российском облаке - Selectel и Mail.ru Cloud (облако тогда ещё относительно молодое, но ресурсы есть). Это не быстро и не бесплатно, но альтернатива - жить в режиме «завтра опять положат».

Что реально переносим в приоритете: базы данных и API-эндпоинты, на которые завязан основной трафик из России. Статику и CDN - через отечественные сети, благо CloudFlare ещё работает нормально. Бэкенд для B2C - первый кандидат на переезд.

Обходные маршруты для доступа к AWS из России. Где немедленный перенос невозможен - настраиваем промежуточный прокси в незаблокированном месте. Схема простая: VPS у нейтрального европейского провайдера, который не попал под раздачу, принимает трафик от российских пользователей и проксирует к AWS-эндпоинту. Некрасиво, но работает пока ситуация не стабилизируется.

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

Что сейчас неясно

Через несколько дней после начала блокировок у нас нет понимания когда это закончится и закончится ли вообще. РКН продолжает добавлять подсети, Telegram продолжает мигрировать, провайдеры - кто выполняет требования точно, кто блокирует с запасом.

Несколько наблюдений по первым дням:

• Разные провайдеры - разные блокировки. У одного клиента часть пользователей на одном операторе видит сервис, другие на другом операторе - нет. Реестр один, исполнение разное. Это усложняет диагностику: «у нас не работает» может означать что угодно.
• AWS сам по себе не делает ничего особенного. Он не резервирует диапазоны специально для российских клиентов - зачем, с их точки зрения. Elastic IP pool - это просто pool, адреса выдаются из того что есть.
• Российские облака внезапно становятся актуальнее. Не потому что они технически лучше - по возможностям они уступают AWS заметно - а потому что они находятся в другой юрисдикции и их адреса РКН блокировать не будет.

Где мы стоим

Перенос критических частей инфраструктуры двух клиентов в российские облака идёт - рассчитываем завершить основное за пару недель. Это параллельная работа: поднять окружение, настроить репликацию данных, переключить трафик, убедиться что всё работает, и только потом отпускать AWS как primary.

Для остальных клиентов - мониторинг ситуации с реестром и запасной план в виде прокси-маршрутов.

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