Сначала я грешил на скорость 3G, браузер, ОС и т.д. и т.п., но как оказалось все не то.
А проблема в том, что HTTPS-сайты через 3G модем Билайн вдруг практически перестали открываться. Все уже привыкли к «фокусам» Билайна с вмешательством в HTTP и добавлением своего кода на страницы, со «сливом» данных пользователей для активации платных подписок кликом на сайте и.т.д. А теперь тренировка с HTTPS?
Про проблему с HTTPS я не сразу догадался конечно. Сначала я грешил на качество связи, вспомнил молодость, когда «картинки не прогружались» из-за низкой скорости. Ну и проверил скорость на популярных ресурсах speedtest.net и internet.yandex.ru. И спидтест и яндекс выдавали примерно одинаковую скорость, 3-10Мбит. Что вполне нормально, учитывая, что покрытия 4G у нас в дачном поселке нет, но с 3G все отлично, модем работает в режиме DC-HSPA+ и показывает «все палки».
Попробовал открывать разные другие сайты, некоторые открывались, некоторые нет, некоторые были «рваными», или открывались очень долго. Я даже проверил скорость с помощью iperf с ноута на даче до сервера в городе, скорость была похожа на то, что выдавал Яндекс и спидтест.
Я уже начал подозревать, что проблема в HTTPS, но почему не работает именно HTTPS, а остальное работает? Бред же?
Что еще я попробовал? Для начала отключил adblock/ublock. Не помогло. Вместо любимого файрфокса запустил IE. Не помогло. Загрузился в Ubuntu, там в файрфоксе ровно те же самые проблемы, сайты открываются с тормозами. Взял другой ноут, подключил модем туда — на другом ноуте тоже проблемы.
Вернулся на свой ноут в файрфокс, запустил панель разработчика и стал методично открывать сайты и смотреть процесс загрузки на таймлайне.
Во-первых, сразу стало понятно, почему сайт drom.ru «порвало»:
Оказывается, если смотреть сайт без https, то картинки все равно грузятся (то есть в моем случае — НЕ грузятся) с https-сервера.
Во-вторых, я действительно убедился, что проблема в HTTPS. Для этого открыл сайт http:// 4pda.ru и https:// 4pda.ru, и вот что получилось:
Сайт с https не то чтобы совсем не грузится. Он грузится, но… код страницы загружается 40 секунд, а вся страницы целиком с картинками и скриптами — 8 минут! Причем та же самая страница без SSL загружается 0.5 сек код и полная загрузка за 12 секунд. Разница во времени загрузки в 40, а местами в 80 раз!
Тут стало понятно про «тормоза» остальных сайтов. Они нет-нет и все имеют вставочки js с https-серверов. Ведь https сейчас модно, недорого, и вообще мастхэв (а браузеры уже начинают ругаться на не-https сайты)
Ладно, то что проблема с HTTPS — разобрались. Но кто виноват? Отключаю модем от компьютера, включаю точку доступа на телефоне (провайдер — тоже Билайн) и… ура! Все работает без проблем. Хм, проблема в самом модеме?
Хорошо, вынимаю симку с телефона, вставляю в модем. Модем в компьютер. И ура! Все работает без проблем!
Вставляю симку «модемную» обратно в модем, и все возвращается — HTTPS тормозит просто адски.
Для чистоты эксперимента вставляю модем с «модемовской симкой билайн» в wifi-роутер, подключаюсь к нему с телефона — HTTP на телефоне работает, HTTPS — нет. Отключаю WIFI, через «телефонную симку билайн» интернет на телефоне есть.
Какие выводы промежуточные? Проблема НЕ в: компьютере, ОС, модеме, браузере. Она привязана к SIM-карте. С этой симкой HTTPS работает неадекватно.
Тут стоит заметить, что не весь HTTPS работает неадекватно, что сразу отвлекало меня от правильного пути. А именно: сайты https:// google.com, https:// gmail.com, https:// youtube.com (и все ролики с него, в HD качестве) и https:// yandex.ru работали отлично. И личный кабинет билайна работал по https (но с ним непонятно, он и в лучшие свои времена тормозной какой-то) А вот https:// ya.ru уже нет (yandex.ru работал)! А так же не работали: https:// lenta.ru https:// 4pda.ru https:// spec.drom.ru https:// ngs.ru/
Обратился я конечно в техподдержку Билайна, описав проблему. На что мне с ходу ответили (цитирую): "Данная ситуация никак не может быть связана с нами, мы просто предоставляем вам интернет. Попробуйте зайти через другой браузер". Конечно оператора не остановило то, что я сообщил в заявке, что «пробовал другой браузер, другую ОС и вообще другой компьютер».
В итоге я снял дамп HTTPS-соединения с сайтом с помощью wireshark, но так и не понял, что там происходит. Может шейпер/полисинг, а может MitM, или вообще что-то другое (но смущает постоянный реордер пакетов):
Кстати, TOR-браузер вообще не запускается (не может загрузить состояние сети). У кого какие идеи, зачем Билайн лезет в HTTPS-трафик?
P.S. и да, с дачи я так и не смог попасть на Хабр/ГТ, даже просто почитать. Не всегда принудительный HTTPS оказывается полезен.
UPD: Если кто-то захочет поковыряться в дампе, то вот ссылка yadi.sk/d/Gg8IJ1PC3JpQAS Вырезал обмен с IP 4pda, думаю достаточно будет?
Комментарии (128)
vanichp
04.06.2017 22:26+1Точно такая же ситуация и с проводным интернетом от Билайна. После подключения услуги фиксированный IP перестали даже пинговаться некоторые сайты. Например пинг до ya.ru идет, а до yandex.ru нет, ну и жуткие тормоза прилагались. После переподключения услуги (сменился IP), все пришло в норму.
mystique_man
05.06.2017 09:53может один из серверов у них кривой?
у них ведь в своё время была какая-то проблема, если при подключении получаешь ip из какого-то диапазона, то 100% отвратительный инет будет со всевозможными проблемами. Помню даже люди скрипт писали для роутера, чтобы он переподключался пока не уйдет с с этого сервера.
p.s. лично я доволен билайном проводным, 4 года уже, 100 мегабит за 295 без каких либо проблем. два раза кабель перебивали на чердаке, делали в течение 2-3 дней.trublast
05.06.2017 09:56Может и так. Но эксперименты показали, что переподключение не решает проблемы. Возможно для каждой сим-карты выдается теперь IP один и тот же. А для другой сим-карты — из другого диапазона.
То есть «сервер может и кривой», но что с этим делать пока непонятно (ну кроме как приобрести другую SIM)
beer8man
07.06.2017 18:42у них ведь в своё время была какая-то проблема, если при подключении получаешь ip из какого-то диапазона, то 100% отвратительный инет будет со всевозможными проблемами
Лично сталкивался с такой проблемой с проводным билайном пару лет назад. ТП ничего не делали и не пытались, сначала не признавая сам факт проблемы (с тупыми советами: попробуй другой роутер/комп/телефон/бубен), а потом признали проблему, но опять ничего не делали, сославшись на то, что там что-то где-то уровнем выше легло. При подключении к сети по l2tp, если выданный ip был из определённого диапазона, часть сайтов выглядела как у автора статьи. Ещё часть адресов не ресольвилась. Проблема частично решалась использованием OpenDNS, и полностью пропадала после десятка-двух переподключений l2tp, когда выпадал ip из другого диапазона. Проблема решилась (явно не силами билайна) месяца через 3.
ABrandt
05.06.2017 14:17Провайдер ДОМ.РУ. Ситуация 1 в 1 была 2 дня назад. Продолжалось 10-15 минут ночью.
Doctor5772
07.06.2017 18:41Проверяйте свой IP, сам абонент и знаю по опыту, при пуле 100.* могут быть проблемы со скоростью, ещё иногда криво работает IPv6, так что его отключение тоже может помочь. Можно так же в такой ситуации собрать трассировку, пинги до разных ресурсов, замеры и скинуть в форму обратной связи. Если не помогает отключение IPv6 и смена IP адреса, то как вариант, когда я обращался в ТП дом.ру, использовал их утилиту test.exe. Её можно запустить заранее, проведёт замеры скорости, трассировку, а после сразу звонить в ТП, "по горячим" следам быстрее разберутся.
wrewolf
07.06.2017 11:28Коллега недавно решал проблему. Отсутствовала маршрутизация внутри сети самого билайна. 3 месяца, пока не дошел до старшего руководства. Были стандартные отписки стандартных обезьянок. (больше всего радовали советы от 2й линии поддержки разбератся с Лос Анжелесом, адрес 10.0.0.0/24 по вхуйсу там, но читать большой текст тем спецам влом (это не считая, что это нужно просто знать))
Dmitri-D
04.06.2017 22:53проверьте свой IP по URLBL листам
Например, тут http:// www.anti-abuse.org/multi-rbl-check/
Скорее всего дело в этом. На вашу симку распределили IP, который раньше был у спамераtrublast
04.06.2017 23:00+4Не совсем уверен, что дело в выдаваемом IP. Сейчас проверить возможности уже нет (выходные закончились, а модем на даче остался в роутере торчать), но мне кажется адрес должен быть динамический. И еще, вероятно, один белый IP будет не только у меня, а у нескольких абонентов Билайн, вряд ли они NAT-ят один к одному.
Опять же, я не смог зайти по HTTPS даже на свой личный сайт, а у меня там никаких blacklist не настроено.
Хотя идея интересная конечно, нужно будет посмотреть, как там IP выделяются.
webkumo
05.06.2017 10:41А кто мешает по маске банить? Там целая подсеть провайдера может в блеклисте сидеть… из которой вам на ту симку и выдаётся IP...
Justlexa
05.06.2017 12:12Очень даже может быть дело в IP. РТК в моём регионе с некоторых пор стал снова NAT'ить ADSL'щиков, причём выходной шлюз может быть в Ярославле, Костроме, Туле и ещё в куче других городов (города из моего региона ещё ни разу не видел). Так вот с некоторыми из внешних IP тот же гугль во время поиска часто просит ввести свою гугло-капчу, объясняя это тем, что с «моего» IP (внешнего) замечен подозрительный трафик. В моём случае переподключение помогает.
PS: забавно ещё и то, что владельцы подключения по FTTx, в отличие от ADSL, получают «белые» IP с привязкой к своему региону.
MrClon
06.06.2017 16:16Сайты проверяют блеклисты при каждом запросе (включая запросы статических изображений), а не только при действиях вроде написания комментария или попытки логина?
Сайты затормаживает запросы с блеклистовых IP, а не дают им отлуп?
Сайты делают всё это для запросов по https, но не делают для запросов по http?
Идентичным образом ведут себя различные сайты, включая собственный сайт автора поста, не смотря на то что он утверждает что ничего подобного его сайт делать вроде бы не должен?
Такой сценарий кажется вам вероятным? Более вероятным чем некоторый сбой в той части провайдерского DPI которая обрабатывает https запросы?
impetus
04.06.2017 22:56+8Как предположение — ваша та симка где тормозит — попала в какой-нибудь чей-то список «на карандаш», в т.ч. возможно вовсе не билайну. Соотв они весь ваш секъюрный трафик заворачивают через какой-нибудь «нашингтон» (даже не на расшифровку, а так, на хранение — постепенный такой ввод в действие закона Яровой)
trublast
04.06.2017 23:07+3Думал об этом. Симка у меня года два. Сначала год торчала в андроид-магнитоле в авто, показывала яндекс-пробки. Потом летом пользовался интернетом на даче, все было нормально. Зиму пролежал модем в рюкзаке «на всякий случай», но кажется так ни разу им и не воспользовался. А этим летом такая вот проблема. Если «прослушивают» старого владельца, то как-то «позднее зажигание». А если меня прослушивают, то почему не «основную» симку, а из автомагнитолы? Там ничего сложнее яндекс-навигатора не работало, вряд ли это показалось кому-то подозрительным.
zartarn
04.06.2017 22:57-3Касперский периодически сообщает о подмене корневого сертефиката на мтсе (проводной).
kapuletti
05.06.2017 07:06+8Касперский и сам сертификат подменяет для "защиты" :)
zartarn
05.06.2017 07:20Что делает Касперский я более менее представляю, и раз он стоит — я готов этим жертвовать, а вот когда непонятно кто и непонятно зачем лезет в трафик, это уже совсем другой разговор.
artyums
05.06.2017 21:00Хм, а Вы могли бы рассказать (или дать ссылочку где почитать), как может Касперский прозрачно подменять сертификат, чтобы пользователь (= браузер) этого не заметили?
sumanai
05.06.2017 22:52+6Зачем тут ссылки? Он просто берёт, добавляет свой сертификат в хранилище ОС и подписывает им весь перехватываемый трафик. Иначе он работать не может.
Vilgelm
07.06.2017 08:41И порой это срабатывает достаточно коряво и все https сайты перестают работать. Причем в KES такого нет, только в «домашних» версиях.
icCE
05.06.2017 22:55В общем и целом nod32 имеет так же свой самоподписанный сертификат
Как оно в реале работает не разбирался, ибо сразу отключил в почте и web.
Вообще такой ум, начинает раздражать.
zIs
05.06.2017 14:55-1Я не очень хорошо знаю эту кухню, но скорее всего, сейчас все провайдеры подменяют корневой сертификат.
Насколько я понимаю, без подмены и анализа https-трафика они вынуждены банить неугодные РКН сайты по IP.
Мой маленький местечковый провайдер долго так и делал, поэтому у меня не открывались https-сайты logitech, slack, appleinsider, bower.io и ещё много других, в то время как у крупных провайдеров, включая Ростелеком, с этим проблем не было.sumanai
05.06.2017 15:55+3Насколько я понимаю, без подмены и анализа https-трафика они вынуждены банить неугодные РКН сайты по IP.
SNI.zIs
05.06.2017 17:20А от сервера это зависит? Мой провайдер говорит мне, что они могут отследить обращение только к некоторым адресам по протоколу https, а остальные блокируют целиком по IP
ivan386
05.06.2017 18:12Да. Сервер может не поддерживать SNI.
sumanai
05.06.2017 20:06+1От этого не зависит, будет ли клиент посылать заголовок SNI. Да и серверов таких в дикой природе не осталось, как и клиентов.
blind_oracle
06.06.2017 09:48+2Только вот в работе драфт TLSv1.3 где предлагают SNI зашифровать...
sumanai
07.06.2017 15:45Давно пора, правда не представляю, как это сделать без дополнительного обмена пакетами, и, соответственно, замедления установки соединения.
blind_oracle
08.06.2017 20:47В 1.3 вроде как хотят уменьшить количество шагов хендшейка, популярно описано например тут: https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/
Но про SNI пока непонятно.sumanai
08.06.2017 23:46Вот и получается, что с одной стороны число шагов будут уменьшать, а с другой шифрование SNI иначе как добавлением ещё одного обмена пакетами не реализовать, или по крайней мере лично я не могу выдумать схему с нулевыми накладными расходами.
sumanai
05.06.2017 19:43По ссылке пробовали сходить? От клиента конечно же. Ваш провайдер, а точнее некоторые люди из техподдержки, как всегда некомпетентны.
TaHKucT
04.06.2017 23:01+1Дамп то трафика из wireshark остался? Выложите куда-нить посмотреть
trublast
04.06.2017 23:19добавил ссылку на дамп
TaHKucT
05.06.2017 00:57+15ну как минимум я вижу что сертификаты 4pda вам прилетают правильные (точно такие же как и мне), а потом от сервер не получает от вас подтверждения получения пакетов (то есть ACKки вы ему отправляете, а он вам в большом количестве Retransmissions присылает (то есть постоянно повторяет одни и те же данные, как будто ваши ACKки до него не доходят)). Скорей всего тут не вмешательство в https, а некая ошибка в конфигурировании сети от вас до сервера и скорей всего она непреднамеренная (ну либо с целью «выгнать пользователей к конкурентам»). То, что на одной симке проблема наблюдается, а на другой нет скорей всего объясняется тем, что разные симки ходят через разные NAT\Bras\etc (не знаю как мобильные операторы строят свои сети в общем случае и как билайн в частности).
Варианта развития как мне кажется 2: либо проблему заметят и исправят без вашего дальнейшего участия (по системе мониторинга, по куче однотипных заявок, по этому топику в конце концов), либо придется общаться с саппортом, но не по телефону, а текстом, прикладывать дампы трафика и призывать инженеров в тикет
OnlySlon
05.06.2017 04:52Выглядит как будто для https трафика на вход (к клиенту) стоит шейпер. Хорошо видно на Time/Sequence диаграмме — сервер пытается вам наваливать входящего трафика (первые 12-13 секунд сессии) согласно открытому окну, но видимо что-то его режет — наблюдаются дропы-реордеринг пакетов. Затем congestion control понимает что что-то не то с каналом и начинает дозировать трафик по чайной ложечке. Отсюда и Скорость.
trublast
05.06.2017 09:20Я тоже больше склоняюсь к тому, что это шейпер.
Непонятна его избирательность, а именно:
1) режет только HTTPS (в первом приближении остальное работало нормально), но при этом не любой, некоторые сайты функционируют нормально.
2) проблема наблюдается на конкретной симкарте ( скорее всего на тарифе, а не симкарте, потому что на одной карте обычный «телефонный» тариф, а на другой, проблемной, «интернетный»)
Исходя из этого непонятен сам смысл такого шейпера. Ладно бы шейпили торренты там, или что-то такое. Да я и не «вредный» клиент, чтобы меня поджимать, купил пакет 15Гб/мес, а за 20 дней потратил всего 2.5Гб.
Так что такой шейпинг для экономии полосы для оператора бесполезный. Скорее всего ошибка, или https льется в отдельный DPI, который не справляется. Или скорее на пул DPI, и тот что привязан к моей симке — не справляется/некорректно работает, а остальные нормально работают.
EvilNW
04.06.2017 23:19Спасибо за информацию. Как раз хотел летом на дачу купить 3G-модем на дачу. Теперь буду очень внимателен с выбором оператора.
trublast
04.06.2017 23:24Тут все относительно. К примеру, в прошлом году у МТС был Безлимитище, а на даче у нас ловил 4G МТС. Соседи пользовались. А теперь не Безлимитища нет, и 4G куда-то пропал, нет покрытия. Проверял Мегафон — работает 3G, но хуже Билайна по скорости 1-2мбит на том же оборудовании (пчелки 3-10мбит). Плюс к тому Билайн в нашем регионе еще и самый дешевый получается, если сравнивать с МТС и Мегафоном.
Но вот такого прикола с HTTPS конечно не ожидал я. На крайняк выкину симку и новую возьму. С другой-то работает нормально.
Dimon2005
04.06.2017 23:26-1У меня та-же фигня плюс ещё и качество голосового соединения гавно, постоянно слова глотает. А в тех поддержке билайн мозги компосируют типа все нормально по вам ограничений никаких нет. Нервы сдают перехожу нс другого оператора а этот билайн пошел в… со своими говно спецами.
TheAlien
04.06.2017 23:32+1Слушайте, а это никак не связано с недавними событиями про фейл РКН? У меня так мой сайт с https в отвале уже 2й день (юзаю cloudflare). Вчера не работали госуслуги, потом отпустило. Сегодня не работал ВК полдня (через Сумтел).
Я про https://zona.media/news/2017/06/02/vkya
Причем все, что не пашет, через vpn (оперы) работает.
(провайдеры Спарк(ттк) и Сумтел; Ростов-на-Дону)trublast
04.06.2017 23:39+1Да, письмо мне такое тоже приходило по работе (рассылка всем операторам связи была). Про фейл я конечно посмеялся про себя. Но это, и проблемы с HTTPS никак связать не могу, маловероятно что они связаны, на мой взгляд.
nelsh
05.06.2017 07:18Скорее всего из-за провайдера (ттк). Я об этом полмесяца назад на хабре писал.
lobzanoff
04.06.2017 23:34+7Несколько лет назад, когда я еще сидел на ростелекомовском ADSL, внезапно перестали открываться, или открывались вот так же криво, некоторые сайты. Точно так же не сразу, но понял — проблемы с HTTPS. Обращение в ТП ничего не дало, по моему, они даже не поняли, о чем речь. Все твердили, что «это с вашим компьютером что-то». Мои уверения в том, что опробовано 2 разных компьютера, 3 разных ОС, включая линукс — как горох об стенку. Писал и на местный форум, где паслись технари провайдера, но был только обсмеян, типа зачем нам фильтровать ваш трафик HTTPS.Однако после неофициального задействования проф. знакомств все-таки обещали посмотреть. И чудесным образом все заработало, а мне потом так же неофициально сообщили, что проблемы имели место быть, но вина в них как бы не совсем провайдера — понимайте как хотите.
Dmitry88
04.06.2017 23:41У меня на работе служба безопасности подменяет сертификаты на лету и хосты https то открываются, то нет.
Но, если организации — это простительно, они вправе устанавливать свои правила контроля, то в вашем случае — это без комментариев. Но — это только версияtrublast
04.06.2017 23:50+2Насколько я понимаю, для этого нужно установить на компьютере сертификат удостоверяющего центра (или как там его зовут). Этот сертификат можно поставить через групповую политику, если компьютер в домене. Тогда им можно подписывать любые сертификаты, и ваш компьютер будет «верить» таким сертификатам. И то не факт, что будет работать во всех браузерах, они вроде как свою базу корневых центров содержат.
Ну и в любом случае не мой вариант, я пробовал на разных ОС и на разных компьютерах, не доменных.
Хо ходят слухи (не достоверные, но… якобы кто-то даже видел как работает) что наши специальные органы имеют возможность делать MitM, подсовывая подписанный «валидный» сертификат. Тут я же не знаю, можно ли дальше писать про вещи, которые «нельзя называть», или я уже и так понаписал лишнего :) Если надо — удалят наверное. Из под моего же аккаунта :)TaHKucT
05.06.2017 01:16+2проблемы «генерировать валидный сертификат на лету» нет, есть есть доступ сертификату удостоверяющего центра которому вы (ваше ПО) доверяет. Есть проблема «не палится генерируя левые сертификаты», ибо есть certificate-transparency.org и DNS CAA (они конечно пока только набирают обороты, но со временем надеюсь будут полностью решать проблему «плохие парни получили корневой сертификат и генерят что хотят»)
vsb
11.06.2017 21:31+2> Хо ходят слухи (не достоверные, но… якобы кто-то даже видел как работает) что наши специальные органы имеют возможность делать MitM, подсовывая подписанный «валидный» сертификат. Тут я же не знаю, можно ли дальше писать про вещи, которые «нельзя называть», или я уже и так понаписал лишнего :) Если надо — удалят наверное. Из под моего же аккаунта :)
Такая возможность очень ценная и её очень легко потерять по простой причине — пользователь, которому вы будете делать MitM может посмотреть цепочку сертификатов и сравнить её с цепочкой на другом компьютере, увидеть разницу, забить тревогу и после этого есть большая вероятность того, что УЦ с треском вылетит из всех браузеров и MitM работать перестанет (ну и попутно бизнес этого УЦ накроется медным тазиком). Поэтому если такое и есть, есть такое и делается, то совсем не в масштабах и очень таргетированно, на тех, кто представляет очень большой интерес, чтобы рисковать таким сертификатом.
Если ваш кто-то ещё раз увидит, как работает, пускай сохраняет сертификаты и рассказывает миру, интернет станет немножко безопасней.
Хотя скорее всего перепутали с обычным корпоративным MitM.
shifttstas
04.06.2017 23:54+15Господа, оставить панику, тут виноват недавний фейл РКН — когда через уже заблокированный домен положили много обычных сайтов, там в списке был:
1tv.ru
badoo.com
pikabu.ru
ok.ru
nic.ru
rzd.ru
atlas ripe
ocsp.comodoca.ru (OCSP-респондер CA)
rtcomm.nag.ru
mail.ru
rbc.ru
booking.com
skbkontur.ru
vasexperts.ru
ntv.ru
vk.com
office 365
facebook.com
reg.ru
sipnet.ru
rfc-revizor.ru
Недавно раздали список всех свободных доменов которые под блокировкой, такие случаи будут повсеместны, подробно инцедент впервые описали тутtrublast
05.06.2017 00:05+1Отчасти да, похоже на объяснение. Например drom.ru и 4pda.ru имеют сертификаты COMODO
Но непонятно 3 вещи
1) https:// yandex.ru открывался, а https:// ya.ru нет, а у них CA один, Yandex LLC
2) разве при недоступности ocsp.comodoca.ru сайты с их сертификатом будут открываться, но при этом тормозить? Мне думалось вообще не будут работать
3) почему при смене симки то начинало работать, то «ломалось», причем на одном компе? Выше было мнение, что может быть из-за IP, привязанного к SIMshifttstas
05.06.2017 00:14+81) Кто-то другой прописал IP от ЦА яндекса
2) смотря какой браузер Safari вообще не даст открыть, у других надо смотреть
3) Вы попадали на DPI который еще не подгрузил новый список блокировок но потом он его подгружал и всё ломалось
Еще раз — на том канале были выложены целый список свободных для регистрации но УЖЕ заблокированных доменов, их вроде бы почти все уже купили следовательно каждый купивший по своему желанию может убивать любой сайт какой захочет.
РКН по этому поводу выпускали экстренный документ о внесении IP он вконтакте в «белый список».tyamgin
05.06.2017 12:25+1А что мешает сначала зарегистрировать домен, и уже потом намеренно спровоцировать блокировку?
ivan386
05.06.2017 12:49-2Административная и уголовная ответственность.
amarao
07.06.2017 13:34+1Ответственность за что? За блокировку?
ivan386
07.06.2017 14:19За контент который спровоцировал блокировку.
AquiHostStrider
07.06.2017 16:49Отвечать будет, наверное, некий Анонимъ с ником «Жопау Педрозу» и аргентинским IP, из-под которого добавлена ссылка на порнуху в немодерируемой гостевухе?
ivan386
07.06.2017 17:06За ссылки вроде ещё не блокируют. Вот если картинки или видео встроит тогда да. Или текст на блокируемые темы.
AquiHostStrider
07.06.2017 23:10+1Мы вообще рассуждаем о блокировке или об уголовной ответственности?
Можно сваять на коленке сайт, прицепить к нему дырявый форум, спамеры сами набегут и сделают всё что надо. Сверху на форуме налепить дисклэймер о том, что дорогая редакция ответственности ни за что не несёт, все сообщения размещаются пользователями ресурса, и наркота, суицид, ЦП, призывы к поруганию действующего президента запрещены, сообщения будут удаляться, пишите на почту, стучите в рельсу если увидите.
И спокойно дожидаться блокировки. Можно даже анонимно самому на себя кляузу накатать в РКН ради ускорения процесса. Уголовка Неуловимому Джо вряд ли светит.
Ну и главное, чтобы движок форума правильно интерпретировал конструкцию<img src="http://порносайт/ЦП.jpg">
amarao
07.06.2017 16:57А у нас полагается уголовная ответственность за попадание в списки роскомнадзора?
trublast
07.06.2017 17:00Ответственность не за попадание в списки, а за нарушение закона. Одним из следствий нарушения является блокировка ресурса, содержимое которого нарушает законодательство. А другим — наказание распространителя (если оного обнаружат)
amarao
07.06.2017 17:12Для попадания в списки роскомнадзора нарушать закон не требуется, достаточно не понравится роскомнадзору. Есть масса случаев досудебной блокировки.
trublast
07.06.2017 17:20Досудебной — да. А вот чтобы по инициативе Роскомнадзора — таких не припомню. Обычно суд, ФНС, ФСКН, Роспоребнадзор и т.д. Можно примерчик, чтобы Роскомнадзор сам блокировал? Даже интересно стало, что за ресурс.
amarao
07.06.2017 17:22Простите, вы не слышали в новостях о массовой блокировке ресурсов недавно? Включая телеграм и кучу других случайных сайтов?
trublast
07.06.2017 17:31+1Слышал. То что я слышал об этом — говорило об уязвимости используемой системы блокировки. А не о том, что «Роскомнадзор по своему усмотрению блокирует случайные сайты». Тут в комментах есть информация по этому поводу.
Саму блокировку выполняют провайдеры.
А распоряжение о блокировке Роскомнадзору выдает «суд, ФСКН, ФНС, etc»
Роскомнадзор не принимает решения о блокировке, они ведут реестр ресурсов и контролируют, чтобы блокировка провайдерами выполнялась.
По моему, эта система работает именно так. Разве нет?
ivan386
07.06.2017 17:26За хентай РКН банит без суда и следствия.
https://hentaihere.com/trublast
07.06.2017 17:36И правда. Не замечал, что такое тоже бывает :)
Сделал grep, оказывается около 7000 ресурсов таких есть, заблокированных РКН (что составляет около 10%)
trublast
05.06.2017 13:12Наверное можно, но домен не в зоне ru, а какой-нибудь com или вроде того. И провоцировать блокировку видимо желательно по причине, за которую нет ответственности в той стране, где будете хостить сайт (его надо будет сделать, чтобы получить блокировку). Чтобы «там» было можно такой сайт, а «тут» нельзя.
jaguarrus
05.06.2017 00:14+4Действительно, никакой паники. Всё нормально. Вазелин в профкоме выдадут.
shifttstas
05.06.2017 00:15+4Я имел ввиду, что это не проблемма конкретного оператора а эта глобальная проблема которую сделал РКН для всех и паниковать нужно не только абонентам полосатово а всем вместе...
tandzan
05.06.2017 00:48humblebundle.com тоже РКН заблочил? Он у меня теперь только через Тор открывается.
nelsh
05.06.2017 07:19Провайдер ТТК? Если да, то чуть выше прокомментировал
Ссылкаhttps://geektimes.ru/post/289787/#comment_10112341TheAlien
05.06.2017 07:05О, ну тогда это объясняет и проблемы у моего сайта, https у которого идет через cloudfare, а у последнего сертификат от COMODO.
bydunai
05.06.2017 07:25+1Не думаю, что билайн блокирует по ip.
Если бы он это делал, тогда вообще не загружалось бы ничего.
Возможно, причина — да, описанная выше, но из-за несколько других последствий:
система, занимающаяся фильтрация для проблемной симки оказалась перегружена.
ExplosiveZ
05.06.2017 10:22Кто это сделал? Чувак, если ты это читаешь — ты мой герой! Нужно больше создавать такого, чтобы весь рунет перебанило!
Spym
05.06.2017 02:05TOR-браузер вообще не запускается (не может загрузить состояние сети).
У меня на домашнем Билайн (Москва) не работают соединения с entry nodes TOR уже примерно месяц как, приходится использовать bridges (и те регулярно отваливаются, приходится менять, но тут проблема может быть и не только в провайдере).
SLY_G
12.06.2017 18:16-1Хмм, а у меня на домашнем билайне в Москве всё работает без проблем. ip динамический. Роутер билайновский.
Jef239
05.06.2017 02:36+1я видел подобное при неверной настройке MTU на ADSL.
trublast
05.06.2017 09:24На MTU я первым делом подумал и попробовал -j TCPMSS --set-mss 1200 и -j TCPMSS --set-mss 500
Ситуация не поменялась, при этом у не HTTPS-соединений с MTU проблем не было, и я отмел это как вероятную причинуюicCE
05.06.2017 11:16Для этого можно просто запустить ping
ping -f -l 1492 любой_рабочий_адрес
trublast
05.06.2017 11:29Согласен, но для чистоты эксперимента я пробовал непосредственно с TCP-трафиком. Сталкивался с ситуациями, когда разные протоколы роутились по разным маршрутам, а там и MTU могло по дороге быть другим.
Яркий пример из начала 2000-х: http/s (а так же pop3 и что-то еще по мелочи) в тоннель через спутник, остальное «по земле». Как раз на http/s получалась инкапсуляция, и уменьшался MTU, а пинги ходили по земле, и спокойно пролазили.
Но в любом случае, проблема в статье связана не с MTU/MSSicCE
05.06.2017 23:14>но для чистоты эксперимента я пробовал непосредственно с TCP-трафиком
?
TCP у вас инкапсулируется в ip и идет фрагментация именно ip пакетов.
По сути TCP у вас это некий поток, постоянный — транспортный уровень. IP же это сетевой уровень.
Понятно, что оно не относится к данной проблеме и я указал простой способ проверки фрагментации пакетов, что бы не заниматься ерундой с iptables.trublast
06.06.2017 13:12Я вроде привел адекватный пример, где видно, что IP пакеты, в которые инкапусулирован icmp (как вы предлагаете) будут проходить, а пакеты, в которые инкапсулирован TCP — не будут.
Поэтому проверить MTU ICMP-пакетами можно, но результат может быть недостоверным. Так что насчет «занятий ерундой» не соглашусь.
Так-то можно сказать: раз HTTP трафик (внутри TCP/IP) проходит, то HTTPS (внутри TCP/IP) тоже должен проходить. Ан нет, не работает же (статья об этом). А на HTTP и HTTPS MTU влияет одинаково в 99% случаев (если только не получать отдельным соединением по HTTP файлики меньше примерно 1кб)icCE
06.06.2017 23:27-2http в tcp,tcp в ip — ip фрагментируется.
icmp в ip — ip фрагментируется.
Поэтому пингами вполне можно все проверить.
Можно задать Размер буфера отправки итд.
При этом не долбить один Ip, а пробовать разные и в итоге подобрать оптимальный MTU.mayorovp
07.06.2017 08:30+1Вы не можете проверить пингами MTU в некотором канале, если пинги идут в обход этого канала.
icCE
07.06.2017 19:37-1Вы не можете проверить http/https так как в некотором канале он может быть идти через другой канал. ping и tracert это первое, что надо делать и это первое показывает, когда у вас что-то не так или не так где-то еще. Столько раз видел на магистралях петли итд.
Ну и то, о чем вы говорите — это TCP MSS.
Но он то как раз и получается, что TCM MSS = (IP MTU – [IPHDR + TCPHDR])
То, что есть дятлы админы которые закрывают полностью ICMP беда компании.
Поэтому в общем и был придуман MTU Discovery Black Hole — https://tools.ietf.org/html/rfc2923
к https://tools.ietf.org/html/rfc1191.
Поэтому зная это все и понимая это все, достаточно команды ping, что бы проверить MTU и сделать вывод о MSS.
Еще можно вспомнить про MPLS MTU, о котором в общем редко кто вспоминает, а он в общем есть.
catharsis
07.06.2017 16:07+1можно еще tcptraceroute сравнить на 80, 443 и какой-нибудь еще порт.
обычным traceroute как-то так:
traceroute -T -p 80 ya.ru
lzb_j77
05.06.2017 05:44У меня аналогичная проблема на работе с сайтом st.com. Кому он нужен, чтоб вносить его в непонятные списки РКН?
То загружается, то нет, то не загружается какая-то одна конкретная страница, то загружаются любые ссылки…
А на соседней тачке всё идеально работает… Наш консилиум так ничего и не решил :)
muzhig
05.06.2017 09:04+2У вас (точнее у провайдера) в вашем расположении проблемы с настройками сети (на что реордер намекает как раз). Ваш хттпс в безопасности, чтобы в него влезть, нужно, помимо того, что быть провайдером, еще и владеть CA сертификатом, которому ваш браузер доверяет. Более того, существует обратная проблема- когда вполне легитимный сертификат не принимается браузером (я с этим сталкиваюсь на встроенных браузерах старых андроидов)
Mi7teR
06.06.2017 13:13старые андроиды могут не поддерживать tls 1.1 и tls 1.2, проблема не с сертификатом.
catharsis
07.06.2017 16:12А старые нокии похоже не поддерживают даже SHA256 и ECDH.
Всегда интересно, что в старой технике перестанет работать первым.
zanac
09.06.2017 19:07Tls 1.0. Встроенный браузер и опера 10.5 некоторые https сайты не открывает. Со временем может начать открывать. Одно время была такая фигня с гитхабом.
Помогает ли установка новых корневых сертификатов — не знаю. Но симба реже стала ругаться на неизвестные сертификаты, да.
unclechu
05.06.2017 18:38С тех пор как мне во мгновение без всяких подтверждений оформилась платная подписка по клику на кнопку на ноунеймовом сайте, — я пользуюсь мобильным интернетом исключительно через Tor (см. Orbot).
unclechu
05.06.2017 22:19+1Забыл заметить, что это был не билайн, эта бацила (и родственные ей по сути) инфицировала уже всех операторов. Было бы неплохо, если вместо всяких «кульков яровой» эффективно бы работала некая система, которая бы удебительно карала провайдеров за подобную мерзкую наглость.
edogs
05.06.2017 22:06+1Вам билайн случайно услугу «файрволл» не подключил?
У нас многое перестало работать с билайна Н-ное количество времени назад, уже все перебрали как варианты, и железо, и софт, и вирусы… зашли в ЛК билайна пополнить баланс — оппа — услуга файрвол включена, да еще на «высоких настройках» с урезанием до фига чего.
Ладно хоть бесплатная, но нервов попортило. При чем после отключения только через 24 часа все заработало.
keldar
06.06.2017 13:14Забавно, имею секс 2 дня с этой проблемой, одолели клиенты… проблема с ок.ru… при чем проявляется забавно… те кто идут тунелем pppoe все пучком, те кто в открытую, все, превед… при это тунель то всего через дслам и пару коммутаторов. жаль коммутаторы я не контролирую, думаю проблема там… По вайршарку примерно то же что и у автора. явно херятся пакеты. Проблема отчасти похожа на mtu, но явно в чем то ином. принцип по которому некоторые сайты работают а некоторые нет, не уловил. Интересные свежие внятные идеи ит инженеров, а не школьников любителей. Вот реально можно подумать, что кто-то пытается вклиниться в трафик от чего сервак начинает левые пакеты и вести себя странно. И проблема не только у билайна! Весткол так имеет проблему. Только инженеры там такие, которым на хрен ничего не надо. За то манагеры очень ушлые! и отжать бизнес им не западло. Но это иная история.
sump
06.06.2017 13:14-1мне билайн присылал смс что я должен якобы заплатить подарок на новый год, потом исчезли деньги и подарка не было соответственно.
exia
06.06.2017 13:14+4- отсутствует Server Key Exchange и Server Hello Done в хендшейке
- неверный номер пакета идущего от сервера после отправки сертификата
Так, сервер отправляет три ответа для установки сессионного ключа — это Certificate, Server Key Exchange, Server Hello Done. Двух последних в сессии нет.
Последний ответ сервера: сертификат. Воспользуемся тем что TCP маркирует пакеты чтобы получать подтверждения о доставке, маркер называется Sequence number.
Sequence number следующего пакета = Sequence number текущего + длинна TCP Segment текущего
- Sequence number[Server Key Exchange] = Sequence number[Certificate] + TCP Segment length[Certificate] = 4261 + 944 = 5205
Т.е. Sequence number следующего после сертификата пакета должен быть 5205, а у нас 5463. Значит сервер отправлял необходимые пакеты, но они не дошли.
Как удобно, отсутствует всего один ответ, но это не дает завершиться протоколу обмена ключами.
Дальше всё просто, сервер не получает подтверждения получения всех пакетов хендшейка, т.к. часть не дошла, и отправляет их заново, но они не доходят. Всё завершается сбросом соединения[TCP RST].
Для того чтобы сделать выводы, нужно несколько дампов.
Если во всех дампах будет отсутствовать Server Hello Done, то это сигнатурный анализ с последующий дропом пакета. В простонародье DPI. Никакие шейперы, натЫ и фаерволла не могут дропнуть один пакет из хендшейка и не давать переслать его заново, а сигнатурный анализ может.catharsis
07.06.2017 16:19Или PMTU blackhole в направлении «к клиенту», только Reorder при этом нигде не должно быть.
Сомнительно умышленно дропать Key Exchange или Server Hello Done, это сложно.
Проще было бы дропать Certificate с «недоверенными» Subject/Altname или просто все соединение.
Китайский файрвол просто шлет RST клиенту, когда DPI не нравится TLS-сессия (например когда там openvpn вместо https).
На всякий случай, для хорошего анализа ситуации нужен полный дамп соединения, то есть запустили tcpdump или wireshark, сделали curl -v https://ya.ru/, дождались пока он закончится, закончили писать дамп.exia
07.06.2017 17:28Почему именно эти пакеты? А почему нет?)
Сложности в этом нет, я даже на микротике такое настраивал. База сигнатур есть.
Об этом надо думать как об особенности реализации.
К тому же сервер пытался переслать пакеты повторно т.к. не получил ACK, но они по прежнему не доходили и сессия всё больше сегментирвалась. Один случайность, два закономерность.
Небольшая догадка, пакеты с цепочкой сертификатов весят много больше чем хилые пакеты c hello done состоящие из пары байт.
Соответственно, чем меньше весит пакет тем меньше времени и памяти уйдет на его анализ, если у вас тысячи клиентов, то время и память ключевые параметры.
Как я и сказал, нужно несколько дампов, чтобы сказать наверняка.
trublast
07.06.2017 17:46Эта версия правда не объясняет, почему в итоге «страница таки загружалась». Да — долго, да — не с первого раза. Но загружалась.
Может там конечно пул из DPI-железок, и иногда пакеты направлялись в другую железку?
Других дампов к сожалению нет, и раньше выходных они вряд ли появятся. А к тому времени может и исправят все.exia
08.06.2017 05:33-1Ну как, браузер отчаянно пытался получить контент по https, ждал когда закончится обмен ключами. А DPI всё дропал server hello done. В итоге браузер сдавался и работал по http.
Этого в дампе нет, просто догадка.
RedElf
07.06.2017 18:42У нашего местечкового провайдера внезапно отвалился cdn jquery.com с аналогичными симптомами
icCE
10.06.2017 02:06+1Это уже относится к блокировкам сайтов. Домены освободились, их вновь зарегистрировали, внесли в днс списки рабочие ip. Сегодня сбербанк и втб лежали по этой причине.
Leo5700
08.06.2017 16:48Я недавно отказался от Билайна — техподдержка ниже всякой критики. Билайн упрямо твердил, будто обрывы и тормоза из-за роутера, я сменил провайдера — всё заработало.
tua-Mascot
09.06.2017 19:08На что сменили, если не секрет? А то тоже подумываю над этим.
Тех. поддержка действительно очень не очень у них стала. Работают медленно. В спорт чате ничего кроме перезагрузки роутера посоветовать и не могут, а на форуме очень уж медленно отвечают и очень часто игнорят пока не начнёшь бочку катить на них. Много уже пережил с билайном (начинал ещё с корбины. потом её выкупил билайн), но сейчас серьёзно задумался о переходе.Leo5700
09.06.2017 19:33+1На ростелекомовский онлайм. Сначала опросил народ в районной фейсбучной группе — у кого какой интернет.
icCE
10.06.2017 02:09я давно на 2kom свалил. Начинал я конечно не с корбины, но корбина была и beeline в итоге. Но в один прекрасный момент достало.
vsb
11.06.2017 11:59Моя версия — срабатывает VPN-детектор. Некоторые мобильные операторы хотят резать торрент-трафик. Хитрые юзеры начинают качать торренты через VPN, чтобы DPI не срабатывал. Соответственно следующее действие — операторы режут скорость VPN. Т.к. многие VPN невозможно легко определить, тот же OpenVPN, насколько я знаю, может работать через 443 порт и внешне его не отличить от HTTPS, они пытаются детектировать VPN по статистике входящего-исходящего трафика и при срабатывании помечают адрес, как чёрный и жёстко режут трафик к нему.
Сам сталкивался с подобным безобразием, не на билайне, правда.icCE
11.06.2017 13:15+1Определяем пользователей VPN (и их настройки!) и прокси со стороны сайта
https://habrahabr.ru/post/216295/
http://witch.valdikss.org.ru/
Mishania1979
11.06.2017 14:03-3Читал-читал… и никто не написал про проблеммы сотовых операторов. На сколько я помню в 3G технологии на данные используются 2 потока, а на голос 1! Следовательно используя сим карту для модема Вы используете для передачи данных 2 потока, а используя симку для телефона-3. Кстати, с этим связана разная цена на трафик для модема и для телефона. Так-же скорость, качество подключения, скорость загрузки сайтов зависит от количества абанентов в данном секторе покрытия базовой станции, количества трафика от них… и т.д.
xilix
Чебурнет все ближе…