There are some anomalies in OONI Tor Snowflake tests from various ASes in Russia since earlier this year. The suddenness of the failures makes it look like Snowflake has been blocked.
Блокируют входящийClientHello, генерируемый pion/dtls, в рамках WebRTC сессии (определяется по Binding Request).
В WebRTCClientHello всегда входящий, а число браузерных прокси меньше чем standalone. Поэтому тесты чаще показывают ошибку, а на практике может работать, зависит от типа NAT (ошибки определения).
В тестах OONI есть особенность, там некоторое время использовалась старая версия snowflake (c HelloVerify) которую новое правило уже не блокировало (тесты от 03/23), но при этом обновление ТСПУ могло где-то застрять. Поэтому в общей картине непонятно.
В тестах OONI есть особенность, там некоторое время использовалась старая версия snowflake (c HelloVerify) которую новое правило уже не блокировало (тесты от 03/23), но при этом обновление ТСПУ могло где-то застрять. Поэтому в общей картине непонятно.
спасибо, I wasn’t aware it was so out of date. I will follow up with OONI about the version of Snowflake and try to get it updated.
2023/09/11 15:56:24 Warning: NAT checking failed for server at stun.l.google.com:19302: NAT discovery feature not supported: attribute not found
2023/09/11 15:56:25 NAT Type: unrestricted
2023/09/11 16:09:33 Warning: NAT checking failed for server at stun.dus.net:3478: NAT discovery feature not supported: attribute not found
2023/09/11 16:09:33 NAT Type: unrestricted
2023/09/11 16:09:43 NAT Type: unrestricted
2023/09/11 16:09:43 Warning: NAT checking failed for server at stun.antisip.com:3478: Error retrieveing server response: timed out waiting for response
2023/09/11 16:09:43 Warning: NAT checking failed for server at stun.voys.nl:3478: NAT discovery feature not supported: attribute not found
2023/09/11 16:09:43 NAT Type: unrestricted
I took a look at some of the recent anomalies, and it does look like they were the result of an out-of-date probe-engine (v 3.16.5), that did not yet have the HelloVerify fix . The current version of OONI does have this fix, but there are many clients that have not updated to newer versions.
I was following up on a tip that Snowflake was being blocked by DTLS fingerprint but it’s possible this was just based on OONI test results. I haven’t seen any direct reports of recent blocking since the HelloVerify fix.
I see, I wasn’t aware that some proxies were being blocked still. Do you have packet captures of the DTLS handshake for blocked proxies? If it is due to the differences between browser proxies and standalone proxies, we should be able to fix that.
Если много блокируемых прокси будут ложно restricted именно они будут чаще подключаться к unrestricted клиенту. Шанс выбрать рабочий прокси будет выше с уменьшением ложных restricted.
Testing Snowflake Tor connection...
error: tor: error connecting to Tor: Failed to obtain exit circuit for ports [scrubbed]: Tried to find or build a circuit 5 times, but all attempts failed
Attempt 1: Unable to select a guard relay: No usable guards. Rejected 20/21 as down, then 0/1 as pending, then 1/1 as unsuitable to purpose, then 0/0 with filter.
Attempt 2: Problem opening a channel to [scrubbed]: Channel for [scrubbed] timed out
Attempt 3: Circuit we were waiting for failed to complete: Problem opening a channel to [scrubbed]: Channel for [scrubbed] timed out
Attempt 4: Unable to select a guard relay: No usable guards. Rejected 21/21 as down, then 0/0 as pending, then 0/0 as unsuitable to purpose, then 0/0 with filter.
Attempt 5: Spent too long trying to construct circuits for this request
Snowflake Tor connection FAILED
2023-09-13T14:42:51Z WARN tor_guardmgr::guard: Could not connect to guard [192.0.2.4:80 via snowflake ed25519:tO9nYvNCAdAh9lPoEEv2pZ9BJq+YzmPAMY6pxoFrLuk $8838024498816a039fcbbab14e6f40a0843051fa]. We'll retry later, and let you know if it succeeds.
2023-09-13T14:42:52Z INFO tor_ptmgr::ipc::sealed: [pt snowflake-client] offer created
2023-09-13T14:42:52Z INFO tor_ptmgr::ipc::sealed: [pt snowflake-client] trying a new proxy: timeout waiting for DataChannel.OnOpen
2023-09-13T14:42:52Z INFO tor_ptmgr::ipc::sealed: [pt snowflake-client] trying a new proxy: timeout waiting for DataChannel.OnOpen
2023-09-13T14:42:52Z INFO tor_ptmgr::ipc::sealed: [pt snowflake-client] broker rendezvous peer received
2023-09-13T14:43:02Z INFO tor_ptmgr::ipc::sealed: [pt snowflake-client] offer created
2023-09-13T14:43:02Z INFO tor_ptmgr::ipc::sealed: [pt snowflake-client] trying a new proxy: timeout waiting for DataChannel.OnOpen
2023-09-13T14:43:02Z INFO tor_ptmgr::ipc::sealed: [pt snowflake-client] broker rendezvous peer received
2023-09-13T14:43:12Z INFO tor_ptmgr::ipc::sealed: [pt snowflake-client] trying a new proxy: timeout waiting for DataChannel.OnOpen
В 2.6.1 регрессия, клиент опять шлет Hello Verify Request. Но работает не поэтому. Действующее правило блокирует раньше, если может в ожидание DTLS. Там что-то еще сломано. Что у вас с NAT по версии 2.6.1?
тут ошибка закралась. у меня несколько АРТИ билдов
работает == соединяется и открываются интернет сайты.
using runtime: Tokio Rustls Runtime { … }
optional features: static-sqlite
вроде как “работает” == соединяется судя по логам с snowflake. но curl то таймаут выдает то другие ошибки
using runtime: Tokio NativeTls Runtime { … }
optional features: static-sqlite, static-native-tls
2.6.1 + rustls == открываются сайты через ТОР
2023/09/13 20:37:02 Warning: NAT checking failed for server at stun.sonetel.com:3478: Error retrieveing server response: timed out waiting for response
2023/09/13 20:37:12 Warning: NAT checking failed for server at stun.altar.com.pl:3478: Error completing roundtrip map test: timed out waiting for response
2023/09/13 20:37:12 NAT Type: unrestricted
2023/09/13 20:37:22 Warning: NAT checking failed for server at stun.l.google.com:19302: NAT discovery feature not supported: attribute not found
2023/09/13 20:37:22 Warning: NAT checking failed for server at stun.sonetel.net:3478: Error retrieveing server response: timed out waiting for response
2023/09/13 20:37:23 NAT Type: unrestricted
2.6.1 + native-tls (windows10) иногда пишет что якобы находит мосты. но сайты через АРТИ не работают
2023/09/13 20:44:26 NAT Type: unrestricted
2023/09/13 20:44:26 NAT Type: unrestricted
2023/09/13 20:44:36 Warning: NAT checking failed for server at stun.dus.net:3478: NAT discovery feature not supported: attribute not found
2023/09/13 20:44:36 Warning: NAT checking failed for server at stun.voys.nl:3478: NAT discovery feature not supported: attribute not found
2023/09/13 20:44:36 NAT Type: unrestricted
2023/09/13 20:44:37 NAT Type: unrestricted
2023/09/13 20:44:46 NAT Type: unrestricted
2023/09/13 20:44:56 Warning: NAT checking failed for server at stun.l.google.com:19302: NAT discovery feature not supported: attribute not found
2023/09/13 20:45:06 Warning: NAT checking failed for server at stun.voipgate.com:3478: Error retrieveing server response: timed out waiting for response
2023/09/13 20:45:06 NAT Type: unrestricted
Три последних, известных, правила блокировки (финальное условие)
Feb, Hello Verify Request (в обе стороны?)
Mar, Server Hello (исходящий)
May, Client Hello (входящий)
Проверить применяемое правило (если это не новое и не трансграничный гибрид) можно, наблюдая за своим UDP трафиком в Wireshark.
Берете 2.6.0 и смотрите. Если прилетел Client Hello (137 байт, важно) это скорей всего НЕ 3 вариант, или ошибка блокиратора, лучше наблюдать подольше. Если связь с пиром застряла на посылаемых и принимаемых Binding Request, Binding Success Response это 3 вариант. Если видно много (больше трех) посылаемых Server Hello это 2 вариант. 1 вариант в 2.6.0 не случается.
Пиры могут сбоить сами по себе и напоминать 3 вариант. Диагностируется длительным наблюдением с выявлением повторяющихся сценариев.
Ваши логи содержат таймаут WebRTC сессии.
Между 2.6.0 и 2.6.1 нет различий в пакетах STUN, DTLS. Обе посылают Hello Verify Request, Server Hello идентичны.
