Connecting to xxx.xxx.xx.xxx:443… failed: Unknown error или предупрежден — значит вооружен


    В этом скриншоте, на первый взгляд, нет ничего необычного — просто упал сайт. Но это не так…


    Скриншот сделан вчера в далеком от Москвы офисе, который подключен к интернету через одного федерального провайдера. Обратите внимание, что доступ по 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 ...

    К сожалению, я сомневаюсь, что это можно считать официальным ответом, так как никаких пресс-релизов по этому поводу не обнаружено.

    Only registered users can participate in poll. Log in, please.

    Вы сталкивались с похожей проблемой?

    • 40.8%Да58
    • 59.1%Нет84
    Share post

    Comments 24

      0

      иногда бывает.
      такое ощущение что это все связано с тем что многие провайдеры не реализуют блокировку сами, а покупают решение.

        0

        Тут цепочка причин.


        • РКН навязывает всем провайдерам систему "Ревизор". Эта система автоматически проверяет, открываются ли сайты из списка блокировок в сети провайдера, генерирует репорты о нарушениях и РКН в случае чего чуть ли не в автоматическом режиме высказывает своё недовольство провайдерам на основании этих репортов. Недовольство может быть эскалировано в том числе и до наложения штрафов.


        • В методичке РКН чуть ли не прямым текстом дана рекомендация провайдерам самим резолвить домены из запретного списка и обновлять полученными IP свои листы блокировки. "Ревизор", видимо, об этой методичке знает, поэтому для проверки надёжности блокировок резолвит домены через DNS-ы (и через те, которые предоставляет провайдер, и, для контрольных проверок, через публичные). Смог открыть сайт — грустьпечаль, скриншот уходит в РКН.


        • Чтобы не получать штрафы и прочую головную боль от РКН, провайдеры используют (или пилят сами) комплексы для осуществления блокировок, которые в том числе резолвят заблокированные домены для пополнения списка IP.

        Как-то так.

        +2
        «системы блокировок сайтов Роскомнадзора» — вот бы провайдеры реально предоставляли такую услугу.
          0

          А покажите-ка трассировку до IP? Есть в ней хопы transtelecom? Особенно интересует наличие bl-gw, blacklist-gw и filter-gw...

            0

            Пожалуй всю портянку приводить не буду:


              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]
              0
              Дальний Восток, ТТК. У меня такие же проблемы именно с этим гейтвеем. Техподдержка положила огроменный болт.
                0
                Поддерживаю. ТТК Краснодар.
                Какое-то время назад оооооооочень долго грузились (или вообще не грузились) CSS FontAwesome с их CDN, судя по трассировке как раз из этих bl-gw. В итоге многие сайты ну очень глючили.
                Техподдержка возложила свой прибор на эту проблему.
                Но на текущий момент все работает, кстати.
                +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 — это оно
                  +1

                  А, у вас похоже сам TTK… Тогда все проще, они совсем не умеют в SNI

                    0

                    Абсолютно такая же картина на ТТК Сахалин :)
                    Помимо nic.ru были еще проблемы с humblebundle.com несколькими днями ранее...

                  +1
                  Это происходит, когда блокировки SSL делают просто по IP, без сниффинга SNI.

                  Грубо говоря есть некий юрл в реестре типа https://some.domain/whatever. Допустим у some.domain прописан IP nic.ru (может даже уже некорректно, просто человек поставил чужой IP на дохлый домен). У оператора, естественно, нет возможности заблокировать непосредственно этот юрл (так как нельзя определить URL при работе с https). Однако, можно по SNI определить, что пользователь пытается установить сессию с some.domain и заблокировать её.

                  В случае вашего провайдера, скорее всего, стоит самописый блокировщик, который блокирует по домену или IP.

                  Другой вопрос, что я не вижу этих IP в реестре. Пишите письмо в РосКомНадзор, что провайдер некачественно предоставляет услуги. Они со своей стороны их вздрючат (если это не ростелеком, конечно).
                    0
                    Всё хорошо, но, как показывает трассировка автором выше, доступ блокируется ТрансТелеКомом (мааааааленький такой магистральный провайдер), и есть уверенность, что в качестве адресата письма с жалобой можно указать Спортлото с таким же результатом.
                      0
                      Ну на самом деле написать-то дел на пять минут. Просто писать провайдеру, если он уже эту проблему не решил, смысла особого нет. А ркн может и начать плешь проедать.
                        +1
                        написать всегда есть смысл — затрат мало.
                      0
                      В браузере Opera нет VPN. Там банальные прокси
                        0

                        Прямо сейчас проблема с www.abuseipdb.com


                        UPDATE: 104.31.75.222 в базе РКН

                          0

                          Несмотря на то, что "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... ошибка: Сеть недоступна.

                          Кто еще может подтвердить эту проблему?

                            0

                            isup.me говорит "жив" очень быстро, через ТТК коннекта нет, рушится на blacklist-gw у ТТК.

                              0
                              PS 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] сообщает: Заданный узел недоступен.

                              Трассировка завершена.
                              0
                              У меня подобная проблема с https различных сайтов на провайдере Qwerty.
                              Причём ip соответствующего доменного имени (как и само доменное имя) ни в каких реестрах не значатся.
                              К сожалению, руки не доходили сообщить в Qwerty.
                                0

                                В общем, надоели мне эти проблемы. Взял себе дроплет в 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, который, вероятно, можно использовать бесконечно ;)

                                  0

                                  Зачем CHR на виртуалке, зачем EoIP? Есть же IP-туннели (IPIP), штатно работающие в линуксе...


                                  Вот вам DO:
                                  image

                                    0
                                    Ну, CHR мне нужен для своих личных целей (в основном всякие эксперименты всякие разные).
                                    Ну а EoIP… Ну, как один из кучи возможных вариантов.
                                  0

                                  Хе-хе. Меня для того, чтобы нормально открывались нужные мне сайты, использующие 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.

                                  Only users with full accounts can post comments. Log in, please.