В этом скриншоте, на первый взгляд, нет ничего необычного — просто упал сайт. Но это не так…
Скриншот сделан вчера в далеком от Москвы офисе, который подключен к интернету через одного федерального провайдера. Обратите внимание, что доступ по 80 порту есть, проблема начинается только после переадресации на HTTPS.
В этот момент у меня была открыта консоль виртуального сервера от московского хостинг-провайдера: сайт был недоступен с другой ошибкой:
Connecting to www.nic.ru (www.nic.ru)|31.177.76.4|:443... failed: Unknown error.Тем не менее сайт был доступен при использовании VPN в браузера Opera, а также при подключении через других провайдеров.
Видимо, можно говорить о том, что мне повезло сразу обнаружить двух провайдеров, у которых была общая проблема. Но, гарантий, что они полностью независимы друг от друга — нет.
По крайней мере можно говорить о том, что это не локальная проблема провайдера, услугами которого я пользуюсь и дома, и на работе. Она может проявиться в любом населенном пункте и, возможно, у любого провайдера. А владельцы сайта узнать об этом могут только случайно.
И началось это не вчера
Поскольку я достаточно давно так или иначе связан с веб-разработкой, то меня не беспокоят упавшие сайты. Есть много причин, из-за которых сайт может не отвечать.
Но в прошлом месяце, при поиске решения какой-то проблемы, полезных ссылок было так мало, что мне очень захотелось попасть на статью в каком-то англоязычном блоге. Долго разбираться не пришлось — достаточно было включить VPN в браузере Opera.
Прошу обратить внимание, что никакой информации о том, что ресурс заблокирован не было.
В итоге за последний месяц мне пришлось воспользоваться VPN еще несколько раз. В основном это были малоизвестные (для меня) англоязычные IT-ресурсы. Но также среди них были:
- bitbucket.com — не сам сайт, только CDN, с которого загружалась пара каких-то файлов. Проблема продолжалась около двух часов.
- deb.nodesource.com — проблема была в один из праздничных дней в начале мая, продолжительность неизвестна.
Итого:
Информация была доведена до заинтересованных сторон, в одном из ответов была такая фраза:
В настоящее время в связи с некорректной работой системы блокировок сайтов Роскомнадзора, возможна недоступность сайта https://nic.ru ...
К сожалению, я сомневаюсь, что это можно считать официальным ответом, так как никаких пресс-релизов по этому поводу не обнаружено.
| 41% (58) |
Да |
| 59% (84) |
Нет |
Проголосовало 142 человека. Воздержалось 113 человек.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (24)
aronovp
16.05.2017 11:33+2«системы блокировок сайтов Роскомнадзора» — вот бы провайдеры реально предоставляли такую услугу.
KorDen32
16.05.2017 11:37А покажите-ка трассировку до IP? Есть в ней хопы transtelecom? Особенно интересует наличие bl-gw, blacklist-gw и filter-gw...
nelsh
16.05.2017 11:42Пожалуй всю портянку приводить не буду:
1) 289 ms * 23 ms bl-gw.transtelecom.net [188.43.29.58] 2) 23 ms 23 ms 23 ms bl-gw.transtelecom.net [188.43.29.49]
cjmaxik
16.05.2017 12:04Дальний Восток, ТТК. У меня такие же проблемы именно с этим гейтвеем. Техподдержка положила огроменный болт.
Akuma
16.05.2017 12:35Поддерживаю. ТТК Краснодар.
Какое-то время назад оооооооочень долго грузились (или вообще не грузились) CSS FontAwesome с их CDN, судя по трассировке как раз из этих bl-gw. В итоге многие сайты ну очень глючили.
Техподдержка возложила свой прибор на эту проблему.
Но на текущий момент все работает, кстати.
KorDen32
16.05.2017 12:14+1Ч.Т.Д.
https://geektimes.ru/post/287714/
https://geektimes.ru/post/287714/#comment_9985686
https://geektimes.ru/post/287418/#comment_9970944
Легко гуглится куча разрозненных тем по «filter-gw.transtelecom.net» (или «blacklist-gw.transtelecom.net»).
ТТК на магистральном уровне блочит рандомные не значащиеся в реестре IP (видно как раз потому, что детектят другие IP для заблоченных доменов, и кто-то троллит/или CDN).
В итоге не открываются рандомные сайты. Из последних крупных, что были замечены — сайты Uniquiti, служебные домены EVE Online, Ingress — правда все они на CDN сидят. Недавно пара IP Github.com была заблочена, со всеми вытекающими — гитхаб тупо не открывался несколько часов, но это было не сильно массово…
Блочится не у всех, кто ходит через ТТК, видимо зависит от особенностей стыка провайдера с ТТК. Сделайте трассировку до интересуюещего адреса. Если там будет хоп filter-gw.transtelecom.net, blacklist-gw.transtelecom.net, или bl-gw.transtelecom.net — это оно
POPSuL
17.05.2017 05:24Абсолютно такая же картина на ТТК Сахалин :)
Помимо nic.ru были еще проблемы с humblebundle.com несколькими днями ранее...
vasachi
16.05.2017 12:11+1Это происходит, когда блокировки SSL делают просто по IP, без сниффинга SNI.
Грубо говоря есть некий юрл в реестре типа https://some.domain/whatever. Допустим у some.domain прописан IP nic.ru (может даже уже некорректно, просто человек поставил чужой IP на дохлый домен). У оператора, естественно, нет возможности заблокировать непосредственно этот юрл (так как нельзя определить URL при работе с https). Однако, можно по SNI определить, что пользователь пытается установить сессию с some.domain и заблокировать её.
В случае вашего провайдера, скорее всего, стоит самописый блокировщик, который блокирует по домену или IP.
Другой вопрос, что я не вижу этих IP в реестре. Пишите письмо в РосКомНадзор, что провайдер некачественно предоставляет услуги. Они со своей стороны их вздрючат (если это не ростелеком, конечно).
chupasaurus
16.05.2017 16:55Всё хорошо, но, как показывает трассировка автором выше, доступ блокируется ТрансТелеКомом (мааааааленький такой магистральный провайдер), и есть уверенность, что в качестве адресата письма с жалобой можно указать Спортлото с таким же результатом.
vasachi
16.05.2017 17:12Ну на самом деле написать-то дел на пять минут. Просто писать провайдеру, если он уже эту проблему не решил, смысла особого нет. А ркн может и начать плешь проедать.
nelsh
17.05.2017 09:14Несмотря на то, что "104.31.75.222 в базе РКН" сайт www.abuseipdb.com недоступен только при подключении через ТТК.
Выглядит это так
~$ curl -I www.abuseipdb.com HTTP/1.1 301 Moved Permanently Date: Wed, 17 May 2017 05:20:00 GMT Set-Cookie: __cfduid=d5ecbfd3d5581299808e29b43b9f9c74c1494998400; expires=Thu, 17-May-18 05:20:00 GMT; path=/; domain=.abuseipdb.com; HttpOnly Cache-Control: max-age=3600 Expires: Wed, 17 May 2017 06:20:00 GMT Location: https://www.abuseipdb.com/ Server: cloudflare-nginx CF-RAY: 36042002b0ea4e84-DME X-Cache: MISS from blacklist.ttk.ru X-Cache-Lookup: MISS from blacklist.ttk.ru:3128 Via: 1.1 blacklist.ttk.ru (squid) Connection: keep-alive ~$ curl -I https://www.abuseipdb.com curl: (7) Failed to connect to www.abuseipdb.com port 443: Нет маршрута до узла ~$ wget www.abuseipdb.com --2017-05-17 13:23:46-- http://www.abuseipdb.com/ Распознаётся www.abuseipdb.com (www.abuseipdb.com)... 104.31.75.222, 104.31.74.222, 2400:cb00:2048:1::681f:4ade, ... Подключение к www.abuseipdb.com (www.abuseipdb.com)|104.31.75.222|:80... соединение установлено. HTTP-запрос отправлен. Ожидание ответа... 301 Moved Permanently Адрес: https://www.abuseipdb.com/ [переход] --2017-05-17 13:23:51-- https://www.abuseipdb.com/ Подключение к www.abuseipdb.com (www.abuseipdb.com)|104.31.75.222|:443... ошибка: Нет маршрута до узла. Подключение к www.abuseipdb.com (www.abuseipdb.com)|104.31.74.222|:443... ошибка: Нет маршрута до узла. Подключение к www.abuseipdb.com (www.abuseipdb.com)|2400:cb00:2048:1::681f:4ade|:443... ошибка: Сеть недоступна. Подключение к www.abuseipdb.com (www.abuseipdb.com)|2400:cb00:2048:1::681f:4bde|:443... ошибка: Сеть недоступна. Распознаётся www.abuseipdb.com (www.abuseipdb.com)... 104.31.74.222, 104.31.75.222, 2400:cb00:2048:1::681f:4bde, ... Подключение к www.abuseipdb.com (www.abuseipdb.com)|104.31.74.222|:443... ошибка: Нет маршрута до узла. Подключение к www.abuseipdb.com (www.abuseipdb.com)|104.31.75.222|:443... ошибка: Нет маршрута до узла. Подключение к www.abuseipdb.com (www.abuseipdb.com)|2400:cb00:2048:1::681f:4bde|:443... ошибка: Сеть недоступна. Подключение к www.abuseipdb.com (www.abuseipdb.com)|2400:cb00:2048:1::681f:4ade|:443... ошибка: Сеть недоступна.
Кто еще может подтвердить эту проблему?
Pakos
17.05.2017 11:11isup.me говорит "жив" очень быстро, через ТТК коннекта нет, рушится на blacklist-gw у ТТК.
POPSuL
17.05.2017 16:10PS C:\WINDOWS\system32> .\TRACERT.EXE www.abuseipdb.com
Трассировка маршрута к www.abuseipdb.com [104.31.75.222]
с максимальным числом прыжков 30:
1 <1 мс <1 мс <1 мс 192.168.88.1
2 <1 мс <1 мс <1 мс bras.ysk.sakhttk.ru [188.168.168.1]
3 <1 мс <1 мс <1 мс 188.168.64.6.static.sakhttk.ru [188.168.64.6]
4 <1 мс <1 мс <1 мс kna06.transtelecom.net [217.150.48.134]
5 * * * Превышен интервал ожидания для запроса.
6 64 ms 64 ms * BL-gw.transtelecom.net [188.43.29.58]
7 BL-gw.transtelecom.net [188.43.29.58] сообщает: Заданный узел недоступен.
Трассировка завершена.
archimed7592
17.05.2017 15:19У меня подобная проблема с https различных сайтов на провайдере Qwerty.
Причём ip соответствующего доменного имени (как и само доменное имя) ни в каких реестрах не значатся.
К сожалению, руки не доходили сообщить в Qwerty.
POPSuL
17.05.2017 16:06В общем, надоели мне эти проблемы. Взял себе дроплет в DO, вкорячил туда CHR, поднял EoIP туннель между CHR и своим микротиком, и завернул весь HTTPS трафик через европу...
Ну вдруг у кого-то микротик и кому надоСтавим CHR в DO по мануалу https://habrahabr.ru/post/312292/
На CHR:
/interface eoip add !keepalive local-address=192.168.88.200 name=eoip remote-address=YOUR_IP tunnel-id=151
/ip firewall nat add action=masquerade chain=srcnat out-interface=ether1
На своем микротике:
/interface eoip add !keepalive name=eoip remote-address=CHR_IP tunnel-id=151
/ip firewall mangle add action=mark-routing chain=prerouting dst-port=443 new-routing-mark=https passthrough=yes protocol=tcp
/ip route add check-gateway=ping distance=1 gateway=192.168.88.200 routing-mark=https
Где
CHR_IP— IP-адрес вашего дроплета в DO, аYOUR_IP— IP-адрес вашего роутера.
192.168.88.200можно заменить на любой другой адрес, хоть 1.1.1.1/1.1.1.2, дело вкуса.
Да и EoIP можно заменить на L2TP/OVPN/PPTP, но лично для себя я решил использовать EoIP.
Главная проблема с которой я столкнулся — ограничение в 1Mbit на free лицензии, но никто не мешает получить триал на P1, который, вероятно, можно использовать бесконечно ;)
kemko
18.05.2017 08:04Хе-хе. Меня для того, чтобы нормально открывались нужные мне сайты, использующие CloudFront, приходится держать в /etc/hosts следующую простыню:
xxx.xxx.xxx.xxx a.trellocdn.com s.theoldreader.com d2iks1dkcwqcbx.cloudfront.net dqw8nmjcqpjn7.cloudfront.net media.molcdn.com connect.soundcloud.com duo.com hello.myfonts.net krypt.co rexify.org www.rexify.org docs.docker.com download.docker.com
Время от времени и до xxx.xxx.xxx.xxx добирается По провайдера, и тогда приходится искать очередной пока ещё незаблокированный адрес. Когда-нибудь надоест и придётся всё-таки заниматься организацией VPN.
ColdPhoenix
иногда бывает.
такое ощущение что это все связано с тем что многие провайдеры не реализуют блокировку сами, а покупают решение.
kemko
Тут цепочка причин.
РКН навязывает всем провайдерам систему "Ревизор". Эта система автоматически проверяет, открываются ли сайты из списка блокировок в сети провайдера, генерирует репорты о нарушениях и РКН в случае чего чуть ли не в автоматическом режиме высказывает своё недовольство провайдерам на основании этих репортов. Недовольство может быть эскалировано в том числе и до наложения штрафов.
В методичке РКН чуть ли не прямым текстом дана рекомендация провайдерам самим резолвить домены из запретного списка и обновлять полученными IP свои листы блокировки. "Ревизор", видимо, об этой методичке знает, поэтому для проверки надёжности блокировок резолвит домены через DNS-ы (и через те, которые предоставляет провайдер, и, для контрольных проверок, через публичные). Смог открыть сайт — грустьпечаль, скриншот уходит в РКН.
Как-то так.