@wikusya Спасибо за команду. Пока что все работает с ней и без нее, но по разному. Понаблюдаю еще. Хочу заметить, что реализаций meek клиентов существует несколько.
Такой вопрос. Когда провайдеры (разных стран) блокируют доступ к запрещенным IP, они это делают только для исходящих соединений или для всех? То есть и для входящих незапрошенных?
Например, NordVPN заблокирован в России. Пользователь из Франции (с более свободным интернетом) подключается к NordVPN (чтобы не пришла жалоба от правообладателя) и запускает торрент клиент. Пользователь из России тоже запускает торрент клиент, но на провайдеровском IP. Французский пользователь хочет скачать раздачу с русского пользователя. Могут ли они соединиться (по торрент протоколу)? То есть, для русского пользователя соединение с запрещенным VPN будет входящим.
Я думаю, что если провайдер настраивает блокировки через iptables, то там будет только OUTPUT. А если какой-нибудь коммерческий файервол или железка, то кто знает.
Я вот тоже думаю, что раз у клиента “входящие незапрошенные” и “входящие ответные” по разному обрабатываются (первые не всегда доступны, хотя, здесь дело в NAT), то может быть “исходящие инициализированные” и “исходящие ответные” будут по разному обрабатываться файерволом провайдера. Например, сам ты инициализировать исходящее соединение с впновским ip не сможешь, но если на тебя свалится входящее от него, может быть тогда ответить и взаимодействовать будет позволено (когда инициатор не ты). Извиняюсь за свою терминологию.
В home интернете “входящие незапрошенные” это довольно экзотическое явление (в отличии от серверной среды, сервер без них жить не может). В home среде белый/внешний ip провайдер не обязан предоставлять и в большинстве случаев домашний пользователь без него обойдется.
Но как я говорил, различия во входящем трафике связаны с NAT, а в исходящем в блокировщике провайдера (который может вообще не разделять тип исходящего или это в принципе невозможно). Этот экзотический случай мало кто изучал, я думаю.
Вот, у тора раньше был мост flashproxy, где входная нода сама соединялась с юзером (по TCP протоколу на 9000 порту). Но сейчас на смену пришел более продвинутый snowflake, где используется WebRTC и можно даже обходить NAT + получение моста через meek, а не email.
Но мне кажется старые транспорты типа fte все еще представляют интерес (если самому развернуть мост на них). Ведь современный DPI специализируется совсем не на них (они как неуловимый Джо). Если только все старые наработки в DPI не забиты.
теперь часто в логах попадаются сообщения вида Tor WARN: Proxy Client: unable to connect OR connection (handshaking (proxy)) на разных этапах подключения к тору, при чем иногда не смотря на это получается подключиться а иногда нет используя один и тот же мост. какая то хитрая тактика от ростелекома?
Уже 3-й день как бьюсь над проблемой с неработающим webrtc (стрим с камеры на сервак) через хромоподобные браузеры.
Недолетает DTLS пакет с ClientHello. Однако в Firefox проблемы не наблюдается. Судя по Wireshark’у пакеты у хрома и лисы немного отличаются. Толи специально блочат, толи случайно.
Выключил мост, и где-то через месяц адрес вновь стал доступен. Получается, актуализируют список, в том числе и для удаления неактуальных записей. Странно, когда воевали с прокси для телеграма, насколько я знаю, с удалением никто не заморачивался.
On December 1, 2021, the Tor network was blocked, without warning, in many ISPs in Russia [99]. This was around the time the US released intelligence on anticipated conflict [32]. Blocking Tor comprehensively is an involved task. The Tor network consists of thousands of servers at well-known addresses (relays and directory authorities) that communicate using a TLS-based protocol [18], as well as thousands of secret “bridges” and circumvention protocols (pluggable transports) that disguise the use of Tor. The blocking action in December 2021 was extraordinary in its comprehensiveness, affecting, for at least a short time and a subset of ISPs, all the common ways of accessing Tor. Table 2 is a summary.
Table 2: Summary of blocking events related to Tor.
Protocol
Blocking characteristics
Directory authorities
All 10 blocked by IP address, starting December 1.
Public relays
Largely blocked, by IP address, with the blocklist being updated to include new relays.
Default obfs4 bridges
All 16 blocked by IP address.
Non-default obfs4 bridges
Progressively discovered and the bridges blocked by IP address.
meek bridge
Blocked, but only on an even smaller subset of ISPs (in Moscow and Saint Petersburg), until December 13.
Snowflake bridge
Blocked by protocol signature until a new software release on December 14.
Blocked by ISPs (not TSPU) beginning December 7. Unblocked on July 14, then blocked again on July 28.
The directory authorities are servers at static IP addresses that maintain a consensus of the state of the network. All directory authorities were blocked on December 1. The majority of public relays were blocked at the same time, and the blocks were updated over time to include new relays.
Not only public relays, but also secret bridges and pluggable transports were targeted. The obfs4 pluggable transport re-encrypts Tor traffic so that it no longer resembles Tor TLS. All the “default” obfs4 bridges, whose addresses are not secret, were blocked on December 1. Non-default obfs4 bridges were also targeted; though because of their secret addresses they were better able to resist blocking, and usage of obfs4 actually increased following the onset of general Tor blocking.
The meek pluggable transport tunnels traffic through a CDN edge server over HTTPS. The censors in Russia briefly blocked the IP address of the CDN edge server used by meek—a drastic step because it also affected non-Tor traffic. The block of meek affected fewer networks than the other Tor-related blocks, a few ISPs in Moscow and Saint Petersburg only. The IP address block was removed on December 13.
The Snowflake pluggable transport [81], which uses temporary peer-to-peer WebRTC proxies, was blocked on December 1. The censors used a distinctive feature in Snowflake’s implementation of WebRTC to detect and block connections. Tor developers released a new version of Snowflake on December 14 to fix the WebRTC fingerprinting flaw [90], and Snowflake began working again. The number of users of Snowflake in Russia thereafter increased; in May 2022 users from Russia constituted about 70% of Snowflake users.
The Tor Project’s website was blocked on December 7. Unlike the network blocks, the website block was acknowledged by Roskomnadzor. It was implemented by the familiar method [71] of ISPs enforcing a shared blocklist, and affected a greater number of ISPs than the Tor network blocks.
Figure 11 shows estimated user counts before and after the invasion. The number of relay users dropped by about two thirds. (The fact that it did not go to zero reflects that not every ISP was affected.) The number of bridge and pluggable transport users increased, but not by an equal amount.
У меня персональная входная нода, сегодня (Владивосток, Ростелеком) перестала соединяться с релеями, вообще глухо. Запустил Tor как просто клиента, тоже никак ни через какие мосты (obfs4 и snowflake). Намертво заблокировали?
Небось после таких сообщений на рутрекере зашевелились. Они его мониторят. Просто конспирология. Я как-то там написал, что meek работает, вскоре перестал.
snowflake 2.7.0 последний попробовать
а вместо obfs4 пробовать https://torscan-ru.ntc.party/
еще пока что ARTI не забанили. но не знаю как оно как сервер/релай. вроде еще не доделали (только как клиент работает)
