«Дом.ру» и Роскомнадзор ломают Apple TV, iCloud и Apple Music в Твери. Технический разбор ковровых блокировок (с логами)1
Я программист с более чем 18-летним стажем, являюсь абонентом «Дом.ру» (АО «ЭР-Телеком Холдинг») в Твери более 10 лет. Пишу этот пост, так как ситуация с качеством связи вышла за рамки адекватного, а поддержка провайдера занимается отписками, перекладывая свои обязанности на клиентов. Последние недели пользоваться экосистемой Apple в сети «Дом.ру» стало невозможно. Симптомы следующие:
Стриминг в Apple TV полностью прекращает воспроизведение фильма на полуслове с ошибкой «Невозможно воспроизвести». Перезапуск приложения не помогает, сессия «отвисает» сама только через 5–10 минут.
В Apple Music постоянно прерывается и заикается аудиопоток, рвутся сессии.
Скорость скачивания файлов из облака iCloud на Mac и iPhone упала до уровня модемов из 90-х.
При этом стоит включить любой сервис, с которым активно борются последнее время — всё мгновенно начинает «летать» на максимальной скорости. Техподдержка Apple подтвердила, что с их стороны ограничений для РФ нет, а проблема носит строго сетевой характер на стороне российских узлов. Поддержка «Дом.ру» выдала дежурную базу: «С нашей стороны ограничений нет, это проблемы у самой Apple, мы ничего не знаем», после чего обязала меня самостоятельно вылавливать IP-адреса и присылать им трассировки. У рядового пользователя на это нет ни квалификации, ни времени. Но мне, как инженеру, это надоело, я расчехлил Терминал и провел независимое расследование.
Шаг 1. Локализуем целевые IP через conntrack
Для перехвата сессий использовался инструмент контроля соединений на домашнем роутере ASUS RT-BE86U. В момент очередного падения фильма на Apple TV смотрим активные сессии по порту 443 (HTTPS) для локального IP приставки (192.168.1.121):
vitaliy@RT-BE86U:/tmp/home/root# conntrack -L -p tcp --dport 443 | grep "src=192.168.1.121"
tcp 6 2113 ESTABLISHED src=192.168.1.121 dst=172.67.207.253 sport=54086 dport=443 src=172.67.207.253 dst=(hide) sport=443 dport=54086 [ASSURED] mark=0 use=1
tcp 6 2329 ESTABLISHED src=192.168.1.121 dst=17.253.39.138 sport=48624 dport=443 src=17.253.39.138 dst=(hide) sport=443 dport=48624 [ASSURED] mark=0 use=1
В логе отлично виден мой внешний IP от «Дом.ру» (скрыл его, в целях безопасности) и главный подозреваемый: 17.253.39.138.
Это официальная автономная подсеть Apple Inc. (17.0.0.0/8). Конкретно данный пул относится к собственной сети доставки контента — Apple CDN (aaplimg.com). Именно отсюда приставка пытается стримить тяжелый видеопоток.
Шаг 2. Трассировка с роутера (Ловим флаг !C)
Запускаем traceroute до найденного IP прямо из консоли роутера:
vitaliy@RT-BE86U:/tmp/home/root# traceroute 17.253.39.138 traceroute to 17.253.39.138 (17.253.39.138), 30 hops max, 38 byte packets
1 * * *
2 lag-2-435.bgw01.tver.ertelecom.ru (109.194.72.18) 1.228 ms 0.892 ms 1.960 ms
3 * * *
4 17.1.168.54 (17.1.168.54) 23.752 ms 24.901 ms 24.959 ms
5 ://aaplimg.com (17.253.39.138) 23.972 ms !C 23.305 ms !C 23.255 ms !C
Пакет за отличные 23 мс долетает до пограничного стыка сетей, но на финальном хосте утилита выплевывает флаг !C.На сетевом языке это означает «Communication administratively prohibited» (Связь запрещена административно). То есть пакет физически дошел до стыка, но государственные фильтры Роскомнадзора (ТСПУ), установленные на сетях операторов, выдали жесткий ICMP-отказ и уничтожили сессию.
Трассировка с роутера
Шаг 3. Трассировка с Mac (Ловим флаг !Z)
Повторяем процедуру непосредственно со своего Mac по протоколу ICMP:
mac-os@user ~ % traceroute 17.253.39.138 traceroute to 17.253.39.138 (17.253.39.138), 64 hops max, 40 byte packets
1 rt-be86u (192.168.1.1) 6.700 ms 9.875 ms 3.821 ms
2 * * *
3 lag-2-435.bgw01.tver.ertelecom.ru (109.194.72.18) 11.511 ms 9.470 ms 8.232 ms
4 * * *
5 17.1.168.54 (17.1.168.54) 29.036 ms 29.340 ms 30.100 ms
6 ://aaplimg.com (17.253.39.138) 27.750 ms !Z 27.900 ms !Z 27.672 ms !Z
Здесь картина становится еще более детальной. Мы получаем флаг !Z — «Communication administratively prohibited by filtering» (Доступ запрещен правилами фильтрации).
Это стопроцентная улика работы систем глубокого анализа пакетов (DPI) со стороны Роскомнадзора. Оборудование на стороне РФ распознает сигнатуру «тяжелого» шифрованного трафика стриминга (ошибочно путая его с VPN-протоколами) и принудительно дропает соединение на сетевом уровне.
Проверка соседнего IP-адреса из этой же подсети CDN Apple (17.253.39.13) показала аналогичный флаг !Z. Под веерную блокировку попал весь автономный пул адресов Apple CDN целиком.
Трассировка с ноутбука
Эпизод с «временной починкой» от инженеров
После того как я завалил поддержку «Дом.ру» этими логами, 16 июня технические специалисты провайдера явно что-то сделали (вероятно, временно перенаправили трафик Apple через альтернативный аплинк или пограничный стык, где настройки DPI мягче) и закрыли тикет. Результат был мгновенным: весь вечер 16 июня Apple TV работал идеально, без единого разрыва на протяжении двух часов. Однако радость была недолгой. На следующий вечер, 17 июня в 21:15, в часы пиковой нагрузки, автоматика фильтрации Роскомнадзора на сетях «Дом.ру» снова закрутила гайки. Спустя полчаса просмотра видео намертво легло с ошибкой «Невозможно воспроизвести контент», а в консоли снова вылетели «родные» флаги !Z.
28 июня после 22:00 смотреть Apple TV было практически невозможно. Ошибка стала появляться несколько раз за час. Apple Music периодически сыпет Cannot connect.
29 июня переоткрыл заявку в технической поддержи «Дом.ру», но мне сразу сказали, что "не может, так как на магистралях у них всё хорошо и повлиять ни на что они не могут".
Суть претензии
Роскомнадзор в ходе бездумной веерной борьбы с VPN-протоколами просто рубит трафик легитимных зарубежных CDN-сетей «ковром», вообще не разбираясь в последствиях. При этом данные сервисы официально продолжают работу в РФ, подписки оплачены, а со стороны Apple ограничений нет. В рамках этого исследования я локализовал пока только одну крупную подсеть CDN. Но учитывая масштаб проблем с iCloud и Apple Music, их явно гораздо больше.
Но больше всего возмущает позиция «Дом.ру». Вместо того чтобы защищать интересы своих абонентов, мониторить аномалии на ТСПУ и слать официальные рекламации в ГРЧЦ, оператор перекладывает обязанности инженеров NOC на клиентов, требуя собирать логи. У меня, как у работающего человека, на это нет ни времени, ни сил. А как программисту с 18-летним стажем, мне становится просто невозможно искать документацию, читать статьи и участвовать в видеоконференциях, когда под раздачу случайно попадает всё подряд.
Официальная жалоба в Управление Роскомнадзора по Тверской области уже направлена (обращение № 349835798 официально взято в работу в СЭД). Отрицать проблему, имея на руках логи с флагами !C и !Z, им будет тяжело.
Если «Дом.ру» и РКН продолжат присылать шаблонные отписки, перекидывая ответственность друг на друга, я намерен обращаться в судебные инстанции. Нам продают услугу связи ненадлежащего качества, искусственно ломая легитимные сервисы.
Информация для официального аккаунта «Дом.ру»
Номер договора: 690004469*** (полный номер договора и ФИО будут отправлены в личные сообщения по первому запросу представителя компании).
Связанные заявки техподдержки: открыты обращения от 14, 15 и 29 июня.
Дата и время последнего зафиксированного сбоя: 28 июня в 23:10.
Номер официального обращения в Роскомнадзор: № 349835798 (находится на рассмотрении Тверского управления).
Если «Дом.ру» продолжит занимать пассивную позицию, а Роскомнадзор пришлет шаблонную отписку, перекидывая ответственность на оператора, я намерен решать этот вопрос в правовом поле. Ответственность лежит на обеих сторонах: РКН обязан скорректировать ложноположительные алгоритмы фильтрации ТСПУ, а «Дом.ру» как исполнитель платных услуг связи обязан не просто разводить руками, а фиксировать технологические сбои из-за стороннего оборудования и направлять официальные рекламации в ГРЧЦ для защиты своих абонентов. Нам продают услугу связи ненадлежащего качества, и я намерен требовать восстановления корректной маршрутизации во всех доступных инстанциях.
ВАЖНЫЙ АПДЕЙТ от 29 июня (18:00). Капкан захлопнулся: поймал ТСПУ за руку в прямом эфире!
Коллеги, это технический нокаут для любых скептиков. По совету из комментариев я решил провести чистый эксперимент и поймать сырые пакеты сброса сессий на штатный трафик стриминга.
Для этого я зашёл по SSH на свой роутер ASUS BE86 и расширил правила iptables в цепочке FORWARD, принудительно логируя в syslog все входящие пакеты со включенным флагом RST (сброс сессии), летящие со всего интернета в сторону моей Apple TV (192.168.1.121).
После этого я полностью очистил системный лог командой dmesg -c, включил фильм и стал наблюдать. Прошло всего 2 минуты! Стрим на экране начал намертво зависать, а системный лог роутера выдал следующую картину:
[APPLE_BLOCK] IN=ppp0 OUT=br0 SRC=17.253.39.198 DST=192.168.1.121 PROTO=TCP SPT=443 DPT=50930 WINDOW=0 RST (серия из 9 идентичных пакетов подряд!)
[APPLE_BLOCK] IN=ppp0 OUT=br0 SRC=17.8.137.69 DST=192.168.1.121 PROTO=TCP SPT=443 DPT=43548 WINDOW=0 RST (серия из 9 идентичных пакетов подряд!)
[APPLE_BLOCK] IN=ppp0 OUT=br0 SRC=17.253.39.132 DST=192.168.1.121 PROTO=TCP SPT=443 DPT=50206 WINDOW=0 RST (серия из 9 идентичных пакетов подряд!)
[APPLE_BLOCK] IN=ppp0 OUT=br0 SRC=17.253.39.198 DST=192.168.1.121 PROTO=TCP SPT=443 DPT=43292 WINDOW=0 RST (серия из 9 идентичных пакетов подряд!)
Технический разбор абсолютной улики:
IP-адрес 17.253.39.198 — это официальный сервер Apple CDN. Логгер зафиксировал серии по 9 абсолютно идентичных поддельных пакетов RST с размером окна WINDOW=0 подряд, бьющих в каждый открывающийся порт приставки. Более того, когда приставка бросает расстрелянный порт 50930 и пытается уйти на чистый порт 49292, автоматика фильтрации на лету перехватывает новую сессию и всаживает туда очередные 9 фальшивых пакетов сброса!
Никакие серверы Apple и никакие операционные системы в мире не закрывают сессии сериями по 9 одинаковых пакетов. Это хрестоматийная атака TCP Reset Injection со стороны ТСПУ Роскомнадзора, установленных на инфраструктуре «Дом.ру». Оборудование DPI анализирует трафик, видит тяжелый медиапоток Apple и буквально заспамливает мой канал фальшивыми пакетами сброса от имени Apple, чтобы принудительно убить соединение. Второй IP в логе (8.6.112.0) — это европейский магистрал Level 3, через который идет медиатрафик Apple, его глушат точно так же.
ДОПОЛНЕНИЕ (29 июня, 19:40): Финальный капкан захлопнулся. Пулеметный спам TCP RST зафиксирован на скриншоте!
Коллеги, это технический нокаут для тех, кто думал, что «проблема на стороне Apple». Стрим на Apple TV ожидаемо начал ложиться, и я успел сделать чистый скриншот логов ядра (dmesg) со своего роутера ASUS BE86. Посмотрите на эту картину тотальной ковровой блокировки трафика:
Логи ресета пакетов
Технический разбор того, что вы видите на экране:
Роутер фиксирует жесткую атаку TCP Reset Injection со стороны черного ящика DPI (ТСПУ Роскомнадзора), установленного на инфраструктуре «Дом.ру». Вместо штатного закрытия сессий, автоматика фильтрации буквально спамит мой канал сериями по 9 абсолютно идентичных поддельных пакетов RST с WINDOW=0 подряд на каждый открываемый приставкой порт.
Под пулеметный расстрел попали сразу все фронты:
Собственные сервера Apple CDN (17.253.39.198, 17.253.39.132, 17.8.137.69). Обратите внимание: приставка пытается уйти от блокировки, бросает расстрелянный порт 59974 и открывает чистый порт 57628 к Apple. Но автоматика ТСПУ на лету перехватывает новую сессию и тут же всаживает в порт 57628 еще 9 фальшивых пакетов сброса!
Глобальный CDN-провайдер Akamai Technologies (2.23.88.174, 23.73.2.77, 23.215.2.12), мощности которого Apple арендует для раздачи тяжелого видео. Сессии к Akamai глушатся дуплетами.
Европейский магистральный гигант Tier-1 Level 3 Communications (8.6.112.0). ТСПУ шлет ресеты даже в транзитный европейский трафик оператора Level 3 (порт приставки 58286). Алгоритмы фильтрации полностью «слепы» — они уничтожают TCP-соединения на уровне целых транзитных магистралей.
Юридический статус дела:
На этом техническое расследование официально завершено со стопроцентным триумфом. Фальсификация трафика доказана на уровне ядра Linux маршрутизатора. Провайдер в чате технично слился, отказавшись комментировать логи, и отправил меня на официальный юридический трек.
Мной официально отправлена досудебная претензия и техническое требование на их официальную почту канцелярии help@domru.ru. В письме я подробно расписал все IP-адреса, прикрепил логи, скриншоты и уведомил, что вся переписка и их ответы ложатся в доказательную базу для последующего судебного разбирательства и Роспотребнадзора. Также напомнил им про открытую заявку в Тверском РКН (№ 349835798). Бумажный трек запущен, ждем от них официального ответа с синей печатью.
