Комментарии 116
В России с декабря прошлого года самые различные блокировки случаются так часто, что о каждом инциденте новостей не напишешь.
Адреса Cloudflare блокируют еще с середины апреля. Проблема затрагивает часть DNS-резолверов, для которых NS Cloudflare чаще всего отдаёт «плохие» адреса. Pikabu, например, из-за этого отказался от услуг Cloudflare вообще. [1], [2].
Блокируют протокол QUIC (HTTP/3), причём современные версии, которые используются в браузерах, блокируют полностью, а версии постарше расшифровывают и инспектируют SNI. Если пакет похож на QUIC, но не поддаётся расшифровке, то он блокируется.
Блокируют протокол WebRTC DTLS, по крайней мере, характерные признаки библиотеки Pino для golang, что нарушает работоспособность конференций при использовании некоторого софта.
Ранее блокировали Google Cloud Functions и Google Firebase, разблокировали только недавно.
Прямо сейчас сообщают о шейпинге YouTube-видео до 128 кбит/с в ЛДНР.
Потребительский интернет в России давно перешел стадию, когда пользоваться им без дополнительного туннелирования в более стабильные каналы затруднительно.
По моим ощущениям, это самая массовая веерная блокировка со времен блокировки Телеграмма. Но может так выглядит с моей колокольни и я не прав и этот рядовое событие.
Но в целом да, я бы даже сказал "интернет в России перешел в стадию, когда пользоваться им затруднительно."
PS: комментарий, как часто бывает содержательнее новости, и тянет на статью "обзор работы интернета в России". :)
ещё в марте интернет в России перешел на ту стадию, что я арендовал сервак в Нидерландах и настроил на всех устройствах pac-скрипт на него по списку заблокированных сайтов
Не проще просто vpn поднять?
Наверное, проще. Но не быстрее в контексте использования интернета. Заметил, что 90% интернета, которым я пользуюсь - не заблокированные ресурсы. Большая часть из них находится в России. Поэтому, использование PAC-файла просто позволяет без задержек заходить на российские сайты и зарубежные, не задумываясь о необходимости переключения на «полный» VPN. Но честности ради, иногда включаю VPN, когда лень добавлять в PAC файл сайт, на который не планирую заходить в дальнейшем.
не задумываясь о необходимости переключения на «полный» VPN
Об этом не надо задумываться, если использовать «полный» vpn на постоянной основе. Почему-то многие упорно не хотят этого делать, а предпочитают мучиться со всякими списками, проксями, которые, к слову, не спасают от кривых ручонок ркн, из за которых почтоянно что-то то тут, то там, отваливается.
Да, есть такое. И приходится настраивать уже списки для прямого доступа не через vpn. Но по моему это все равно проще, чем постоянно натыкаться на рандомно заблокирвоанные сайты и протоколы.
Если выбирать не из самых крупных и известных хостеров, обычно проблем с капчей нет.
Недавно столкнулся с еще большим цирком. Надо было через интернет (e-mail) отправить документы на регистрацию нового счетчика расхода воды. Неожиданно оказалось, что ни с outlook.com ни с gmail.com местный Водоканал почему-то письма не принимает. По какому-то наитию попробовал отправить с yandex.ru - и все нормально прошло.
А чисто так теоретически — НЕ отправка документа чем грозит?
А попытка отправки, получение лога что они сами отказываются принимать(outlook.com разве что bounce даст — не факт что там будет нужное) и тыкание им этим логом в ответ на все вопросы почему не отправлено?
НЕ отправка документа чем грозит?
Тем, что либо понесешь его туда ногами, либо будешь платить за водоснабжение не по счетчику, а по социальной норме.
И к сожалению проще отказаться от gmail.com, чем убедить поставщиков сменить адрес рабочей почты.
Здравствуйте. Пожалуйста, расскажите подробно, какие трудности с письмами с нашего сервиса у вас возникли, через эту форму: https://help.mail.ru/surveys/claims
Сотрудники службы поддержки проверят ситуацию.
Имхо, это уже извраты на местах.
Я с таким поведением столкнулся еще в 2008 году, когда главный инженер у провайдера не мог получить от меня письмо.
Потом оказалось, что он только с *.ru принимает, а с *.com и пр. - нет, "а чо такова?".
На днях заблокировали aol.com. Теперь без VPN я свою почту и забрать не могу.
да даже rzd или какой-нибудь koltsovo.aero недоступны из-за рубежа.
Когда скорость канала в интернет доходит до гигабита как-то очень уж не хочется абсолютно весь траффик заворачивать в впн и довольствоваться в лучшем случае 10% от скорости канала. А если еще и в онлайн игры играть, то впн вообще не вариант. Белые списки - ну такое, уж очень много геморроя искать какие там диапазоны ip у гугла, стима, серваков 20 разных игр (если mmo - вообще тушите свет), каким-то образом торренты исключать из впн.
А от кривых ручонок ркн в принципе спасают правильно настроенные динамические списки. У меня микротик смотрит SNI хост и автоматически пихает нужные хосты в впн. До этого просто домены висели в address list'ах, но на сайтах с агрессивной балансировкой трафика типа twitter'а не работает. Можно еще сильнее автоматизировать и какой-нибудь mitm прокси поднять и все что редиректит на заглушку провайдера кидать в впн, но у меня такой необходимости не было.
У меня микротик смотрит SNI хост и автоматически пихает нужные хосты в впн
А можно подробнее как это сделано? Именно динамическая часть.
Вешание маркировки (либо вообще добавление в address list который автоматом вешает) уже есть.
Ну как пример для твиттера mangle правила такие:
3 ;;; add twitter.com to addr list
chain=prerouting action=add-dst-to-address-list protocol=tcp
address-list=Адрес-лист address-list-timeout=none-dynamic
in-interface=!ИнтерфейсVPN log=no log-prefix="" tls-host=twitter.com
4 ;;; add mobile.twitter.com to addr list
chain=prerouting action=add-dst-to-address-list protocol=tcp
address-list=Адрес-лист address-list-timeout=none-dynamic
in-interface=!ИнтерфейсVPN log=no log-prefix="" tls-host=mobile.twitter.com
5 ;;; add api.twitter.com to addr list
chain=prerouting action=add-dst-to-address-list protocol=tcp
address-list=Адрес-лист address-list-timeout=none-dynamic
in-interface=!ИнтерфейсVPN log=no log-prefix="" tls-host=api.twitter.com
6 ;;; add *.twimg.com to addr list
chain=prerouting action=add-dst-to-address-list protocol=tcp
address-list=Адрес-лист address-list-timeout=none-dynamic
in-interface=!ИнтерфейсVPN log=no log-prefix="" tls-host=*.twimg.com
7 ;;; add t.co to addr list
chain=prerouting action=add-dst-to-address-list protocol=tcp
address-list=Адрес-лист address-list-timeout=none-dynamic
in-interface=!ИнтерфейсVPN log=no log-prefix="" tls-host=t.co
Каждый раз когда адрес резолвится в новый ip он уходит в address list до следующей перезагрузки роутера. Пока address list не набьется возможно легкое подтупливание, которое решается перезагрузкой страницы.
Первое соединение к заблокированному сайту всегда «виснет» или разрывается, только со второго раза сработает? А с ресурсами, которые блокируют по IP-адресу, и к которым соединение не установится и до передачи SNI процесс не дойдёт, как обстоят дела? Или вы применили какой-то дополнительный хак?
У меня у провайдера весь https отваливается через PR_CONNECT_RESET_ERROR. Mangle правил хватает для такого случая чтобы с первого раза все отрезолвить и прогрузить корректно. По моему только с twitter были какие-то проблемы, но я предполагаю что либо на стороне самого twitter какая-то балансировка трафика странная, либо что когда я настраивал правила у меня уже висели соединения не через vpn.
Кроме mangle и doh через cloudflare больше ничего не делал.
Если нужно проверить какие-то конкретные примеры то можете написать и я посмотрю как оно себя вести будет.
Вы только что включили маршрутизатор, все таблицы пустые.
Вы открываете twitter.com, происходит резолвинг DNS, браузер устанавливает соединение на IP-адрес, маршрутизатор маршрутизирует его через вашего обычного провайдера;
Происходит TCP handshake (с IP-адреса вашего провайдера), браузер отправляет TLS ClientHello, маршрутизатор считывает SNI, добавляет адрес в таблицу маршрутизации через VPN;
Пакет TLS ClientHello маршрутизируется через интерфейс VPN. В зависимости от настроек маршрутизации и NAT, либо это происходит с правильным IP, тогда пакет доходит до Twitter и отбрасывается с RST (произошла смена source ip на адрес VPN-сервера, Twitter знает только о соединении с исходящим IP-адресом вашего провайдера, а не VPN-сервера), либо уходит с неправильным адресом (NAT не подхватывает правило уже установленного соединения, у которого внезапно изменился интерфейс с необходимостью еще одной подмены адреса), тогда пакет уходит в VPN, и VPN-сервер его (с большой вероятностью) отбрасывает, т.к. source address клиента не совпадает с сетью VPN.
Итого: первое соединение либо разрывается из-за несовпадения адресов, вызванных внезапной сменой маршрута, либо «зависает», по аналогичной причине.
Последующие соединения (если IP-адрес тот же) будут устанавливаться успешно. Если у домена несколько адресов, аналогичные проблемы будут для каждого адреса.
Либо я не понимаю вашей настройки, либо в Mikrotik можно применять дополнительные меры по решению этой проблемы. Как её решаете вы?
Я не могу сказать какие манипуляции с пакетами микротик делает под капотом или насколько криво у моего провайдера работает/подключен ТСПУ.
Описанная проблема с отбрасыванием пакетов у меня была когда я вместо добавления в address list сразу вешал routing mark на пакеты. Больше никаких действий по решению данной проблемы я не предпринимал.
Для чистоты эксперимента я отключил mangle правила, перезагрузил роутер и включил их снова. Прогружается все с первого раза, без сброса соединения. Скриншот из дебагера браузера:
Единственное на что обратил внимание - instagram абсолютно дохлый, видимо бан по ip. Facebook, twitter, yt3.ggpht.com отрезолвились нормально.
Браузер может быть достаточно умным, чтобы прозрачно переподключиться, либо это может сделать serviceworker twitter'а, сгладив проблему.
Я не могу придумать вменяемых способов решения описанной проблемы, которые можно было бы внедрить в маршрутизатор уровня Mikrotik.
Да, действительно, браузер слишком умный. Но для меня такое решение все еще более надежное, чем powertunnel на котором постоянно отваливалась подгрузка картинок в твиттере.
user@srv:~$ curl -o - -I https://yt3.ggpht.com/someurl
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to yt3.ggpht.com:443
user@srv:~$ curl -o - -I https://yt3.ggpht.com/someurl
HTTP/2 200
access-control-expose-headers: Content-Length
content-disposition: inline;filename="unnamed.jpg"
vary: Origin
access-control-allow-origin: *
timing-allow-origin: *
x-content-type-options: nosniff
server: fife
content-length: 61464
x-xss-protection: 0
date: Sun, 22 May 2022 18:58:24 GMT
expires: Wed, 18 May 2022 01:31:14 GMT
cache-control: public, max-age=86400, no-transform
age: 9918
etag: "v1"
content-type: image/jpeg
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
user@srv:~$ curl -o - -I https://facebook.com
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to facebook.com:443
user@srv:~$ curl -o - -I https://facebook.com
HTTP/2 301
location: https://www.facebook.com/
access-control-expose-headers: X-FB-Debug, X-Loader-Length
access-control-allow-methods: OPTIONS
access-control-allow-credentials: true
access-control-allow-origin: https://facebook.com
vary: Origin
strict-transport-security: max-age=15552000; preload
content-type: text/html; charset="utf-8"
content-length: 0
date: Sun, 22 May 2022 21:44:19 GMT
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
См. правильную реализацию: https://bitbucket.org/anticensority/antizapret-vpn-container/src/
А дальше что с этим списком делать? Можно более полную инструкцию? Заранее спасибо
https://koobik.net/mikrotik-obhod-blokirovok-rkn/
Дальше открыть терминал микротика и ввести
/ip firewall mangle add chain=prerouting action=add-dst-to-address-list protocol=tcp address-list=Адрес-лист address-list-timeout=none-dynamic in-interface=!ИнтерфейсVPN log=no log-prefix="" tls-host=twitter.com
/ip firewall mangle add chain=prerouting action=add-dst-to-address-list protocol=tcp address-list=Адрес-лист address-list-timeout=none-dynamic in-interface=!ИнтерфейсVPN log=no log-prefix="" tls-host=mobile.twitter.com
/ip firewall mangle add chain=prerouting action=add-dst-to-address-list protocol=tcp address-list=Адрес-лист address-list-timeout=none-dynamic in-interface=!ИнтерфейсVPN log=no log-prefix="" tls-host=api.twitter.com
/ip firewall mangle add chain=prerouting action=add-dst-to-address-list protocol=tcp address-list=Адрес-лист address-list-timeout=none-dynamic in-interface=!ИнтерфейсVPN log=no log-prefix="" tls-host=*.twimg.com
/ip firewall mangle add chain=prerouting action=add-dst-to-address-list protocol=tcp address-list=Адрес-лист address-list-timeout=none-dynamic in-interface=!ИнтерфейсVPN log=no log-prefix="" tls-host=t.co Не забыв поменять Адрес-лист и ИнтерфейсVPN на свои имена. Восклицательный знак в интерфейсе впн обязателен.
Для надежности потом зайти в ip -> firewall -> mangle и перетащить созданные правила чтобы они были над правилом, которое маркирует пакеты.
Я так же настраивал микротик, гонял адреса. Потом понял что все что нужно от заблокированного проще использовать на другом браузере. Есть хостинг в Германии, там доступна авторизация по ssh. Пытался на микротике поднять SOCKS5 сервер для перенаправления портов, неудача постигла меня. Помогло решение с использование bitvise ssh client, он позволяет поднять прокси SOCKS5 через тунель ssh, второй браузер для запрещенки настраиваю для работы через прокси и профит. Быстро просто, автоматом, цена порядка 28 евро за хостинг за год + впн получается бесплатно. Хостера публиковать не буду, а то прочитают еще и отрубят. Для моих задач хватает с головой, скачать торренты, почитать посмотреть. А максимальная скорость провайдер для торрента сохраняется.
Ну проще ж это делается (ну имхо, проще).
Тоже VPS в Германии. Между МТ (RB4011IGS+5HACQ2HND-IN) и VPS WG туннель. На VPS стоит bird2 (bgp демон). Ему по крону раз в 3 часа скармливается файл с подсетями (скрипт дергает с антизапрета ipresolve.lst, это список с 377к сетей /32, и также список подсетей DigitalOcean, в связи с последними событиями по блоку 443 порта DO, собирает эти два списка в формат для bird2).
Ну и между VPS и MT поднята bgp-сессия, в туннеле, чтоб пров не заблокировал. Всё. Скрипт отработал, собрал файлик для bird, дернул его (reconfigure), роуты "залились" в МТ. И больше никаких телодвижений.
Я сделал так: порты 80, 8080, 8888, 443 tcp и 443 udp для всех адресов, кроме ru, направил в впн. Можно ещё icmp добавить, чтобы корректно работал traceroute. Список ru подсетей берётся тут https://stat.ripe.net/data/country-resource-list/data.json?resource=RU и обновляется периодически по крону. Конкретная реализация - openwrt, wireguard, mwan3, ipset. Спокойно работает на обычном домашнем роутере.
Красиво! Подскажите, куда почитать чтобы такое сделать?
Вот эта статья вроде бы выглядит как что-то плюс-минус похожее на то что я сделал: https://koobik.net/mikrotik-obhod-blokirovok-rkn/, решение с автоматическим забиванием адресов в address-list я чуть выше опубликовал.
Не то же самое, но вот: https://bitbucket.org/anticensority/antizapret-vpn-container/src/
Присоеденяюсь к @vikarti Если не сложно, опишите как делали?
Когда скорость канала в интернет доходит до гигабита как-то очень уж не хочется абсолютно весь траффик заворачивать в впн и довольствоваться в лучшем случае 10% от скорости канала.
У меня канал 100М (по тарифу, реально где-то 90-95), через впн проходит в районе от 60 до 80 с копейками (аплод еще выше, до 85-90 доходит).
Какие 10%?
10% от 700-1000мбит как раз укладывается в ту скорость которую вы получаете. :)
10% от 100мбит — это 10мбит вообще-то.
У меня в лучшем случае выходит до ~85% от ширины канала. Возможно и можно выжать еще больше (поиграть с шифрованием и тп), но мне лень.
Вы меня совсем не поняли. Я в изначальном комментарии говорил про 10% от моего канала в интернет. То что вы можете выжать условные 60-90% от своего 100мбит канала не значит что вы столько же выжмите на гигабитном канале. Особенно если у вас какой-нибудь дешевый VPS сервер как у меня, а не коммерческий VPN.
Хотя и на коммерческих VPN тоже выбор не велик, из топ 5 более-менее на слуху только 2 провайдера, остальные какие-то (по крайней мере для меня) noname сервисы. Ну а все что ниже топ-5 как раз в 10-30% от гигабитного канала попадают.
То что вы можете выжать условные 60-90% от своего 100мбит канала не значит что вы столько же выжмите на гигабитном канале. Особенно если у вас какой-нибудь дешевый VPS сервер как у меня, а не коммерческий VPN.
У меня нет гигабитного канала для теста. Поднимать туннель между двумя серверами в одном ДЦ на полторы минуты для теста мне, честно говоря, лень. Но вот сейчас, на моем vpn сервере при максимальной утилизации канала загрузка по cpu порядка 10-15 процентов. И я не думаю, что он приляжет если я гигабит туда гнать начну. Все может упереться в сетевую инфраструктуру в ДЦ, но провайдер обещает как раз 1Gbps.
На смарте вообще не выключаю
Есть сайты которые не любят зарубежные IP. (госуслуги, авито, платежные системы некоторые)
Есть задачи где нужна вся доступная полоса канала а на блокировки — наплевать (торренты те же).
А еще есть всякие Steam, GOG, EGS и прочие сервисы, которые совсем не обрадуются включенному VPN соединению и через какое-то время (особенно, если покупки через него совершить) еще и забанят вместе со всей библиотекой. При этом, обойти впн при использовании этих сервисов (т.е. написать правило, чтобы трафик шел напрямую через провайдера) довольно сложно, ибо там очень много сетей и очень много способов, которыми они пытаются определить используется ли VPN/Proxy/etc.
Я использую впн на постоянной основе и получается, как на картинке ниже:
Блокируют протокол QUIC (HTTP/3), причём современные версии, которые используются в браузерах, блокируют полностью, а версии постарше расшифровывают и инспектируют SNI. Если пакет похож на QUIC, но не поддаётся расшифровке, то он блокируется.
Так вот, почему у меня уже который день релеи Syncthing отвалились.
А как определять, с чьей стороны блокировка идёт? Примерно столько же времени назад я открыл для себя, что xiaomi.eu и upgrades.syncthing.net/meta.json (Syncthing туда стучится за обновлениями) открываются только через VPN (без — получаю ERR_CONNECTION_TIMED_OUT).
А как определять, с чьей стороны блокировка идёт?
Например, можно выполнить traceroute (стандартный ICMP или же более точный TCP). В случае с xiaomi.eu, пакеты с некоторых операторов доходят достаточно далеко, но не далее 62.128.210.209 (AS20860 IOMART CLOUD SERVICES LIMITED) в моём случае, поэтому полагаю, что это блокировка со стороны сайта (но могут быть и какие-то сетевые проблемы).
А upgrades.syncthing.net хостится на Digitalocean, см. новость.
Интересно, есть ли надежда что блокировку снимут? Такая удобная програмулина :(
Да, я как раз сегодня копал в эту сторону. Если явно прописывать (на телефоне) адрес и порт компа - работает. А вот без указания адреса, но через собственный релей (его тоже прописал и на компе, и на тел по док-и) - не работает.. Может, конечно, оно пытается через релей публиковать ВНЕШНИЙ адрес, а ком и тел оба во внутренних сетях (разных, так что локальный поиск не работает тоже)
Прямо сейчас сообщают о шейпинге YouTube-видео до 128 кбит/с в ЛДНР.
За все ЛДНР не скажу, но ДНР все в порядке с ютубом, также без сбоев работает free vpn от cloudflare WARP. Но вот cloudflare WARP сдал менее отзывчивым и то по вечерам.
Я из ЛНР, интернет Matrix Алчевск.
Действительно Ютуб очень сильно глючит, видео воспроизводится максимум в 120р и то с жуткими загрузками.
С чем это связано наш провайдер пока не знает.
Сейчас вот попинговал вроде все норм и скорость согласно тарифу 100 туда обратно.(хоть на Москву, хоть на Прагу) Ютуб работает на ура, укр сайты только через впн.
upd новостные укр сайты
По поводу ютуба добавлю - уже пару месяцев наблюдаю то что в мобильном приложении с трудом грузятся shorts и не прогружаются аватары и картинки в постах.
Домен, с которого загружаются аватары и картинки, заблокирован через Реестр: https://reestr.rublacklist.net/record/4285828/
О, такая же картина и в NewPipe на Андроиде. Спасибо за статистику.
>Потребительский интернет в России давно перешел стадию
Режут ведь на последней миле, чисто хомяков.
Почти от всех блокировок помогает прокси в большом ЦОДе РФ, т.е. зарубежный VPS нафиг не нужен.
Если пакет похож на QUIC, но не поддаётся расшифровке, то он блокируется.
Фигась. Всё-таки внедряют эту китайскую практику. Дальше внедрят connection probing?
Connection probing был еще 4 года назад. Не онлайн-версия, конечно, но был:
https://github.com/darkk/rkn-git-flow
https://usher2.club/articles/mt-free-pre-block/
https://www.the-village.ru/city/news/326087-maxima-vs-telegram
curl -v -x http://*** https://scontent-hou1-1.cdninstagram.com
* Trying ***...
* Connected to *** port *** (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to scontent-hou1-1.cdninstagram.com:443
* Proxy auth using Basic with user '***'
> CONNECT scontent-hou1-1.cdninstagram.com:443 HTTP/1.1
> Host: scontent-hou1-1.cdninstagram.com:443
> Proxy-Authorization: Basic ***
> User-Agent: curl/7.81.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL connection timeout
* Closing connection 0
curl: (28) SSL connection timeoutcurl -v -x http://*** https://scontent-hou1-1.cdninstagram.com
* Trying ***...
* TCP_NODELAY set
* Connected to *** port *** (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to scontent-hou1-1.cdninstagram.com:443
* Proxy auth using Basic with user '***'
> CONNECT scontent-hou1-1.cdninstagram.com:443 HTTP/1.1
> Host: scontent-hou1-1.cdninstagram.com:443
> Proxy-Authorization: Basic ***
> User-Agent: curl/7.68.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CONNECT phase completed!
* CONNECT phase completed!
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=Menlo Park; O=Facebook, Inc.; CN=*.instagram.com
* start date: Mar 1 00:00:00 2022 GMT
* expire date: May 30 23:59:59 2022 GMT
* subjectAltName: host "scontent-hou1-1.cdninstagram.com" matched cert's "*.cdninstagram.com"
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55e4f93f7d80)
> GET / HTTP/2
> Host: scontent-hou1-1.cdninstagram.com
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 204
< cache-control: max-age=86400, must-revalidate
< cross-origin-resource-policy: cross-origin
< content-type: text/plain
< server: proxygen-bolt
< x-fb-trip-id: 1679558926
< date: Mon, 23 May 2022 11:59:27 GMT
< alt-svc: h3=":443"; ma=86400,h3-29=":443"; ma=86400
<
* Connection #0 to host *** left intactНе подскажете куда копать? Или в Instagram теперь ходим через VPN?
Подтверждаю, проблемы у 15% процентов юзеров из России с 20 числа. Тоже додебажили до блока 443 порта, могу даже постмортемом поделиться
Вы бы могли объяснить, что в этом контексте значит "пост мортем"? Так вы называете логи программного обеспечения, в которых была зафиксирована проблема с доступом к порту 443?
Это такой процесс, когда создаётся документ/страничка с инфой об инциденте затрагивающей прод/конечных юзеров. Что произошло, как дебажили, к чему пришли, как решили проблему и как избежать в будущем. В данном случае логов никаких и нет. Мы просто увидели падение трафика из РФ на 15 процентов, пошли жалобы пользователей, и была произведена работа по поиску и решению проблемы. Решение в нашем случае поднимать окружение без использования диджитал оушен и клаудфлеир
Использовали Cloudflare, но после публикации на каком-то сайте сообщения типа "Бешеный принтер и сбивать спутники SpaceX" и этот сайт размещен в США и РКН его заблокировал (ip сайта был Cloudflare) это было 16 апреля начались проблемы у разных удаленных сотрудников работающих через разных провайдеров, притом получалось что нельзя получить данные с одного сайта , а остальные работают, хотя физически все сайты находятся на одном сервере имеющий один ip. Отказались от защиты Cloudflare.
Но в комментарии выше проблема описана днем ранее, 15 апреля.
как же заколебали эти долбоклюи из РКН
все их действия за всё время существования прекрасно подходят под экстремизм и терроризм, но что-то я не вижу новостей о том что роскомпозор сел на бутылрку в полном составе
никогда не поверю что судебная система в россии работает пока не увижу их всех за решёткой
Зря не верите, она работает, просто вы не совсем понимаете, как и с какой целью она работает. Хотите потестить - выйдите погулять с антивоенным плакатом, например.
Печально что для большинства это всего лишь тема для шуток..
Минусов в карму интересно накидали за что, неужто все тут так любят ркн..
На хабре как все-таки русскоязычной платформе кроме небольшого числа идейных "патриотов", подозреваю, в тенях шастуют штатные хунвейбины, которые по-мелкому, но массово сливают карму всем недовольным смутьянам. С учетом "гражданских ограничений, что следует за этим, это работает вполне эффективно - недовольные затыкаются и изгоняются, прямо модель нашего обшества!
С чего вы решили, что я шучу? Я абсолютно серьёзен - российская судебная система, как и государственная система вообще, прекрасно выполняет задачи, заложенные в неё её создателями в текущем виде. Басманный суд не даст соврать. Просто эти задачи не совпадают с теми, которых вы от неё хотите.
Хабр не является площадкой для политических дискуссий. Тут теперь можно дискутировать только об узкопрофильных проблеммах, например - разводить холивар о вредности оператора ГоТо. Или о том, насколько классные бургеры будут в "новом ***дональдсе" (применительно к труду IT-шников). А если структуры наедут на очередного "дурова/сысоева", то "сообщество" ограничится новостью. Так как коммерческое предприятие может существовать в (любом) государстве только в тех рамках, в которых ему будет это позволено делать. Ну, Вы всё поняли, да?..
Короче,- аминь!
PS Ну и риторика была слишком жосткой в комментарии. Хотя РКН и всю остальную братию тут мнооооогие не любят ;) ...
PPS Удачи! И плюсов в карму... :)
Это не работает.
Если часы показывают верное время 2 раза в день, никто не говорит, что по ним можно время сверять.
Интересно, сайт билайна они же поломали?
Если раньше (полу)госконторы могли "на голубом глазу" отвечать - "у нас лисичка не работает" (имелась в виду реальная или мнимая нерабоспособность софта на Visual Fox Pro), то теперь добавится "вы наверное через VPN пытаетесь..."
Походу взялись за облачные VPN, потому что Lantern отвалился тоже 20 числа... Совпадение? Не думаю...
да, из мгтс(Москва) не отвечает DO Container registry во "FRA"
Cloudflare и Digital Ocean? Так там же дофига российских сайтов хостится. У нас теперь любой забугорный хостинг может попасть под блок, правильно?
Подтверждаю проблему, хостимся на DO и с пятницы возникла эта проблема, все сводится к блокировке доступа по https, а http работает нормально. Правда не все IP блокируются, один сайт продолжает работать по https, хотя тоже находится на DO. Будем пробовать проксировать через сервера в облаке от Яндекса.
Всеми силами пытаются удержать IT-специалистов в стране, но получается наоборот
Интересно, MELPA (репозиторий пакетов для Emacs) по той же причине недоступен?
Сайт MongoDB тоже недоступен.
Трассировка mtr --tcp --port=443 speedtest-fra1.digitalocean.com
И Амстердам, и Сингапур, и другие затыкаются на bogon IP адресе.
Провайдер таттелеком и домру. Причём с мобильного устройства работает, с проводного у того же провайдера не работает.
Если tcp убрать трассировка доходит, с tcp и другим портом тоже работает.
Другие новости
В России блокируют доступ к сетям Cloudflare и Digital Ocean