Вы только что включили маршрутизатор, все таблицы пустые.
Вы открываете 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 можно применять дополнительные меры по решению этой проблемы. Как её решаете вы?
Первое соединение к заблокированному сайту всегда «виснет» или разрывается, только со второго раза сработает? А с ресурсами, которые блокируют по IP-адресу, и к которым соединение не установится и до передачи SNI процесс не дойдёт, как обстоят дела? Или вы применили какой-то дополнительный хак?
Например, можно выполнить traceroute (стандартный ICMP или же более точный TCP). В случае с xiaomi.eu, пакеты с некоторых операторов доходят достаточно далеко, но не далее 62.128.210.209 (AS20860 IOMART CLOUD SERVICES LIMITED) в моём случае, поэтому полагаю, что это блокировка со стороны сайта (но могут быть и какие-то сетевые проблемы).
А upgrades.syncthing.net хостится на Digitalocean, см. новость.
В России с декабря прошлого года самые различные блокировки случаются так часто, что о каждом инциденте новостей не напишешь.
Адреса Cloudflare блокируют еще с середины апреля. Проблема затрагивает часть DNS-резолверов, для которых NS Cloudflare чаще всего отдаёт «плохие» адреса. Pikabu, например, из-за этого отказался от услуг Cloudflare вообще. [1], [2].
Блокируют протокол QUIC (HTTP/3), причём современные версии, которые используются в браузерах, блокируют полностью, а версии постарше расшифровывают и инспектируют SNI. Если пакет похож на QUIC, но не поддаётся расшифровке, то он блокируется.
Блокируют протокол WebRTC DTLS, по крайней мере, характерные признаки библиотеки Pino для golang, что нарушает работоспособность конференций при использовании некоторого софта.
Прямо сейчас сообщают о шейпинге YouTube-видео до 128 кбит/с в ЛДНР.
Потребительский интернет в России давно перешел стадию, когда пользоваться им без дополнительного туннелирования в более стабильные каналы затруднительно.
Мероприятие отчасти для сплочения тех, кто (вынужденно) уехал, но душой всё ещё с Россией, но не ограничивается этим: будут доклады и от многих местных сообществ, посвященных интернет-безопасности и технологиям.
Самая хорошая «альтернатива» VNC — Thinlinc. Это комбайн из TigerVNC/noVNC/VirtualGL. Пробрасывает звук, 3D, работает с принтерами, возможно подключаться из браузера.
Вообще говоря, Teamviewer тоже поддерживает работу без интернета, по прямому IP-адресу. Почти что уверен, что в таком режиме он продолжит работу на российских компьютерах.
Кому интересно, в этом блоге можно почитать о внутреннем устройстве современных (относительно того, что выпускала VIA) процессоров Centaur CHA — подразделения VIA, которое было продано Intel в конце 2021.
Кому интересно, в этом блоге можно почитать о внутреннем устройстве современных (относительно того, что выпускала VIA) процессоров Centaur CHA — подразделения VIA, которое было продано Intel в конце 2021.
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
См. правильную реализацию: https://bitbucket.org/anticensority/antizapret-vpn-container/src/
Браузер может быть достаточно умным, чтобы прозрачно переподключиться, либо это может сделать serviceworker twitter'а, сгладив проблему.
Я не могу придумать вменяемых способов решения описанной проблемы, которые можно было бы внедрить в маршрутизатор уровня Mikrotik.
Вы только что включили маршрутизатор, все таблицы пустые.
Вы открываете 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 можно применять дополнительные меры по решению этой проблемы. Как её решаете вы?
Первое соединение к заблокированному сайту всегда «виснет» или разрывается, только со второго раза сработает? А с ресурсами, которые блокируют по IP-адресу, и к которым соединение не установится и до передачи SNI процесс не дойдёт, как обстоят дела? Или вы применили какой-то дополнительный хак?
Не то же самое, но вот: https://bitbucket.org/anticensority/antizapret-vpn-container/src/
Например, можно выполнить traceroute (стандартный ICMP или же более точный TCP). В случае с xiaomi.eu, пакеты с некоторых операторов доходят достаточно далеко, но не далее 62.128.210.209 (AS20860 IOMART CLOUD SERVICES LIMITED) в моём случае, поэтому полагаю, что это блокировка со стороны сайта (но могут быть и какие-то сетевые проблемы).
А upgrades.syncthing.net хостится на Digitalocean, см. новость.
Какую-то часть фильтруют и на транзите. Транзитные блокировки точно есть у Билайна, МТС, ТТК.
Домен, с которого загружаются аватары и картинки, заблокирован через Реестр: https://reestr.rublacklist.net/record/4285828/
В России с декабря прошлого года самые различные блокировки случаются так часто, что о каждом инциденте новостей не напишешь.
Адреса Cloudflare блокируют еще с середины апреля. Проблема затрагивает часть DNS-резолверов, для которых NS Cloudflare чаще всего отдаёт «плохие» адреса. Pikabu, например, из-за этого отказался от услуг Cloudflare вообще. [1], [2].
Блокируют протокол QUIC (HTTP/3), причём современные версии, которые используются в браузерах, блокируют полностью, а версии постарше расшифровывают и инспектируют SNI. Если пакет похож на QUIC, но не поддаётся расшифровке, то он блокируется.
Блокируют протокол WebRTC DTLS, по крайней мере, характерные признаки библиотеки Pino для golang, что нарушает работоспособность конференций при использовании некоторого софта.
Ранее блокировали Google Cloud Functions и Google Firebase, разблокировали только недавно.
Прямо сейчас сообщают о шейпинге YouTube-видео до 128 кбит/с в ЛДНР.
Потребительский интернет в России давно перешел стадию, когда пользоваться им без дополнительного туннелирования в более стабильные каналы затруднительно.
Мероприятие отчасти для сплочения тех, кто (вынужденно) уехал, но душой всё ещё с Россией, но не ограничивается этим: будут доклады и от многих местных сообществ, посвященных интернет-безопасности и технологиям.
Да, только оффлайн.
Примерно так. Мероприятие с большим количеством экспатов.
Самая хорошая «альтернатива» VNC — Thinlinc. Это комбайн из TigerVNC/noVNC/VirtualGL. Пробрасывает звук, 3D, работает с принтерами, возможно подключаться из браузера.
Вообще говоря, Teamviewer тоже поддерживает работу без интернета, по прямому IP-адресу. Почти что уверен, что в таком режиме он продолжит работу на российских компьютерах.
А вот статья про Zhaoxin Lujiazui
https://chipsandcheese.com/2021/09/22/the-weird-and-wacky-world-of-via-part-2-zhaoxins-not-quite-electric-boogaloo/
А вот статья про Zhaoxin Lujiazui
https://chipsandcheese.com/2021/09/22/the-weird-and-wacky-world-of-via-part-2-zhaoxins-not-quite-electric-boogaloo/
Кому интересно, в этом блоге можно почитать о внутреннем устройстве современных (относительно того, что выпускала VIA) процессоров Centaur CHA — подразделения VIA, которое было продано Intel в конце 2021.
https://chipsandcheese.com/
Кому интересно, в этом блоге можно почитать о внутреннем устройстве современных (относительно того, что выпускала VIA) процессоров Centaur CHA — подразделения VIA, которое было продано Intel в конце 2021.
https://chipsandcheese.com/
Прочтите концепцию https://bitbucket.org/anticensority/antizapret-vpn-container/src/