Не так давно заметил что в Билайне заблокированы часть подсетей предоставляемых CDN-сервисом CloudFlare. Причем блокировка ведется именно по IP, т.е. ни по HTTP, ни по HTTPS часть ресурсов, которые в своей работе используют CloudFlare. Под катом, если кому-то интересно примеры и некоторый анализ ситуации.
Началось все с того что одним прекрасным утром я не смог зайти на форум forum.gsmhosting.com, не то чтобы этот ресурс был особенно полезным для меня, но иногда читаю там какие-то новости и просматриваю девелоперские разделы, поэтому факт того что ресурс не открывается для меня стал небольшим сюрпризом. Возможно временные технические проблемы, подумал я, но проверив доступность ресурса вечером — увидел что ничего не поменялось. Тогда я решил попробовать разобраться в чем же дело. В месте подключения заведено два провайдера Билайн (L2TP) и Ростелеком (PPPoE), все это «сведено» через Mikrotik, т.е. используется балансировка нагрузки, попеременный выбор маршрута и т.п. подобные полезные вещи, однако, HTTP и HTTPS открываются именно через Билайн. Посмотрев nslookup'ом A-записи для forum.gsmhosting.com я получил следующее:
Addresses: 104.27.158.203
104.27.159.203
Как видно оба данных адреса принадлежат CloudFlare, настроив маршрутизацию этих IP через Ростелеком — я обнаружил что ресурс вполне работоспособен. Что же произошло?
На странице http://moskva.beeline.ru/customers/help/safe-beeline/ugrozy-v-internete/zablokirovannye-resursy/ у Билайна можно получить информацию о том что оба этих IP адреса действительно попадают в список заблокированных ресурсов:
При этом попытка найти само постановление ФНС 2-6-27/ 2016-06-29-51-АИ успехом не увенчалась. Также, IP-адрес и доменное имя форума были проверены на предмет присутствия в списке заблокированных ресурсов здесь:
Однако и там и там на момент проверки значилось что данные IP адреса или доменное имя не значатся в реестре.
Следующим шагом было обращение в техподдержку Билайна с подробным описанием ситуации, на что был получен следующий ответ:
Заблокирована подсеть 104.27.159.203/32, которая имела отношение к ресурсу marathonbet.cc, доступ к которому был заблокирован по решению ФНС.
Ip 104.27.159.203 на данный момент за ресурсом forum.gsmhosting.com
Обращений в Федеральный Центр Мониторинга от владельцев ресурса не поступало.
Но факт в том, что у другого провайдера — Ростелеком, который также исполняет требования 149-ФЗ forum.gsmhosting.com открывался, а вот заблокированный marathonbet.cc нет, о чем и было сообщено в ответном письме представителям провайдера:
Данная подсеть относится к пулу адресов https://www.cloudflare.com/, если вы понимаете о чем идет речь. Сайтов использующих CDN от CloudFlare не одна тысяча как вы понимаете, поэтому из-за блокировки marathonbet.cc могут пострадать вполне легитимные ресурсы. Данную ситуацию можно сравнить с недавней блокировкой сервисов Amazon S3. Что же касается обращения от владельцев ресурса forum.gsmhosting.com и других «пострадавших» в Федеральный Центр Мониторинга, то здесь как раз все понятно, подобного обращения и не будет, т.к. в Европе просто не в курсе о существовании подобного центра и блокировках чего-либо в России.
Тем неменее у Ростелекома данная блокировка реализована корректно, при попытке открыть marathonbet.cc пользователь автоматом редиректится на страницу заглушку http://warning.rt.ru/?id=13&st=0&dt=104.27.159.203&rs=marathonbet.cc/ с помощью 302 редиректа. Другие сайты расположенные на этом IP по HTTP открываются вполне корректно.
В Билайне же все «интереснее». При открытии что marathonbet.cc, что forum.gsmhosting.com заглушки http://blackhole.beeline.ru/ не выходит, соединение просто режется на стороне Билайна. Из всех возможных решений по реализации блокировки в данном случае, к сожалению, Билайн выбрал самое некорректное.
Надеюсь мне удалось привлечь внимание к существующей проблеме, хотя бы на уровне «конкуренты исполняют требования 149-ФЗ лучше» и в будущем можно будет надеяться на ее разрешение.
p.s. Решением проблемы может быть блокировка указанных IP по HTTPS, при этом при доступе по HTTP провайдеру ничего не мешает анализировать поле Host в заголовке HTTP протокола. В Ростелекоме именно так и происходит.
Однако в ответ я получил простую отписку:
Блокировка такого рода ресурсов производится именно по всей подсети 104.27.159.203/32.
Владельцам ресурсов, не имеющих отношения к ресурсу marathonbet.cc, необходимо обратиться в ФНС, с просьбой снять блокировку, или же обратится к провайдеру, который предоставляет им адреса из подсети 104.27.159.203/32, с просьбой выдать корректный адрес.
Комментарии про реализацию аналогичной блокировки у конкурентов, естественно, во внимание не приняли, да и судя по всему отвечал обычный сотрудник ТП первого уровня, у которых на любой типовой запрос есть соответствующие инструкции. Других причин именовать один единственный IP адрес 104.27.159.203/32 целой подсетью по-крайней мере я не вижу ;)
Что же мы имеем в итоге? Множество ресурсов так или иначе пользуется CDN-сервисом от CloudFlare, реализация блокировок у некоторых провайдеров (тот же Билайн) в этом случае реализована по IP, т.е. любые HTTP и HTTPS обращения к заблокированным IP просто «режутся» firewall'ом на стороне провайдера, без какого-либо дополнительного информирования абонента. С другой стороны, некоторые (Ростелеком) реализуют более правильный подход к реализации подобных блокировок, так, например, у них блокировка IP происходит только при попытке обращения по HTTPS, при использовании HTTP другие ресурсы не страдают, т.к. анализируется поле Host в заголовке запроса.
Последующие проверки на тему «как обстоят дела в Билайне» показали что со стороны провайдера заблокированы и некоторые другие ресурсы, A-записи которых принадлежат пулу Cloudflare, причем полностью по IP.
Автор: Decker
