новый способ поддержки пользователей Tor – через Telegram
Команда по связям с общественностью проекта Tor рада объявить о запуске нового официального канала поддержки – в мессенджере Telegram: @TorProjectSupportBot. Этот способ поддержки добавлен в рамках усилий по борьбе с цензурой в отношении Tor в России.
Пользователи, у которых возникли проблемы с браузером Tor или которые не могут подключиться с помощью моста к Tor, могут связаться с нашей службой поддержки через Telegram. Этот новый экспериментальный канал поддержки ориентирован, в первую очередь, на помощь русскоязычным пользователям в подключении к сети Tor.
Поднятый в конце декабря этого года мост сначала перестал работать на мобильных операторах, сегодня отлетел и на проводном МГТС. Пингуется, но не более того.
Старый мост (три года) пока живет и здравствует.
Оба публичные, распространение через moat.
Вы правы и не правы одновременно. С одной стороны кажется, что meek больше не работает. Застревает на 20%
Feb 06 19:29:40.000 [notice] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
Feb 06 19:29:40.000 [notice] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
Feb 06 19:29:40.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Feb 06 19:29:52.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
Feb 06 19:29:59.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
Feb 06 19:29:59.000 [notice] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
Feb 06 19:31:00.000 [notice] No circuits are opened. Relaxed timeout for circuit 1 (a General-purpose client 1-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway.
Feb 06 19:35:27.000 [notice] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
Feb 06 19:45:27.000 (nothing)
В Wireshark красно-черные строчки. При этом коннект с cs22.wpc.v0cdn.net (155.199.19.160) по началу есть.
Один раз кое как добралось до 25% за 4 минуты в виде исключения.
Разбавление сторонней фоновой (обычно-браузерной) активностью не помогает.
Проверил 2-3 раза.
Провайдер мобильный.
snowflake работает.
Затем я переподключился к интернету и meek заработал.
Однако это довольно странно.
@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’у пакеты у хрома и лисы немного отличаются. Толи специально блочат, толи случайно.
Выключил мост, и где-то через месяц адрес вновь стал доступен. Получается, актуализируют список, в том числе и для удаления неактуальных записей. Странно, когда воевали с прокси для телеграма, насколько я знаю, с удалением никто не заморачивался.