I spent some time looking for the cause of high rates of anomalies in OONI's torsf test: https://explorer.ooni.org/chart/circumvention?since=2022-04-06&until=202... I looked at the recently available (https://github.com/ooni/backend/issues/573) stunreachability measurements, to test whether the Snowflake connections were failing at the STUN phase.
In summary, 3 of the pool of 12 STUN servers are inaccessible in Russia. One of them is blocked by censorship in Russia, and the other two look like geoblocking of Russian clients by the STUN service. I don't think the loss of 3 STUN servers is likely to be a cause of many connection failures; therefore I think the explanation lies elsewhere.
Here are the charts: https://explorer.ooni.org/chart/mat?probe_cc=RU&test_name=stunreachabili...
stun.voip.blackberry.com and the IP address 178.239.90.248 are on the unified register of blocked sites, the entry dated 2017-04-28: https://reestr.rublacklist.net/record/530002/ Here's a measurement showing the test timing out: https://explorer.ooni.org/measurement/20220224T192519Z_stunreachability_RU_1...
stun.stunprotocol.org is not on the unified register as far as I can tell, nor are its IP addresses 18.191.223.12 and 2600:1f16:8c5:101::108. This domain resolves to 127.0.0.1 or ::1 for requesters located in Russia. Here's a sample measurement: https://explorer.ooni.org/measurement/20220224T111232Z_stunreachability_RU_3... Using ooni-sync, we can see that the domain resolves incorrectly only in Russia and Ukraine: $ ./ooni-sync -directory stunreachability test_name=stunreachability since=2022-05-18 until=2022-05-19 $ jq -r 'select(.test_keys.endpoint=="stun.stunprotocol.org:3478")|[.probe_cc,(.test_keys.queries[].answers[]?|(.ipv4? // .ipv6?)),.probe_network_name,.test_keys.failure]|@tsv' stunreachability/* | sort ... IT 18.191.223.12 2600:1f16:8c5:101::108 Vodafone Italia S.p.A. IT 18.191.223.12 2600:1f16:8c5:101::108 Vodafone Italia S.p.A. KZ 18.191.223.12 Kar-Tel LLC LK 18.191.223.12 2600:1f16:8c5:101::108 Mobitel Pvt Ltd LT 18.191.223.12 2600:1f16:8c5:101::108 Telia Lietuva, AB MX 18.191.223.12 2600:1f16:8c5:101::108 Mega Cable, S.A. de C.V. MX 18.191.223.12 Mega Cable, S.A. de C.V. NL 18.191.223.12 2600:1f16:8c5:101::108 T-Mobile Thuis BV RU 127.0.0.1 ::1 Cloudflare, Inc. generic_timeout_error RU 127.0.0.1 ::1 Iskratelecom CJSC generic_timeout_error RU 127.0.0.1 ::1 JSC "ER-Telecom Holding" generic_timeout_error RU 127.0.0.1 ::1 JSC "ER-Telecom Holding" generic_timeout_error RU 127.0.0.1 ::1 JSC "ER-Telecom Holding" generic_timeout_error RU 127.0.0.1 ::1 Novotelecom Ltd generic_timeout_error RU 18.191.223.12 PJSC "Bashinformsvyaz" SE 18.191.223.12 2600:1f16:8c5:101::108 Telia Company AB SE 18.191.223.12 Vetenskapsradet / SUNET SG 18.191.223.12 2600:1f16:8c5:101::108 Leaseweb Asia Pacific pte. ltd. TW 18.191.223.12 2600:1f16:8c5:101::108 <unknown> TW 18.191.223.12 2600:1f16:8c5:101::108 <unknown> UA 127.0.0.1 ::1 Virtual Systems LLC generic_timeout_error US 18.191.223.12 2600:1f16:8c5:101::108 AT&T Services, Inc. US 18.191.223.12 2600:1f16:8c5:101::108 AT&T Services, Inc. US 18.191.223.12 2600:1f16:8c5:101::108 CABLE ONE, INC. ...
stun.altar.com.pl is not on the unified register, nor is its IP address 176.119.42.11. Its failures only start on 2022-03-09. Its domain usually resolves correctly, but in Russia the actual STUN phase usually results in a timeout: $ jq -r 'select(.test_keys.endpoint=="stun.altar.com.pl:3478")|[.probe_cc,(.test_keys.queries[].answers[]?|(.ipv4? // .ipv6?)),.probe_network_name,.test_keys.failure]|@tsv' stunreachability/* | sort | grep RU RU 176.119.42.11 Cloudflare, Inc. RU 176.119.42.11 Iskratelecom CJSC generic_timeout_error RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error RU 176.119.42.11 Novotelecom Ltd generic_timeout_error RU 176.119.42.11 PJSC "Bashinformsvyaz" generic_timeout_error But there are also errors for networks in Spain, Hong Kong, Indonesia, and the United States: $ jq -r 'select(.test_keys.endpoint=="stun.altar.com.pl:3478")|[.probe_cc,(.test_keys.queries[].answers[]?|(.ipv4? // .ipv6?)),.probe_network_name,.test_keys.failure]|@tsv' stunreachability/* | sort | grep error ES 176.119.42.11 Orange Espagne SA generic_timeout_error HK Hong Kong University of Science and Technology generic_timeout_error ID Telekomunikasi Indonesia (PT) generic_timeout_error RU 176.119.42.11 Iskratelecom CJSC generic_timeout_error RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error RU 176.119.42.11 JSC "ER-Telecom Holding" generic_timeout_error RU 176.119.42.11 Novotelecom Ltd generic_timeout_error RU 176.119.42.11 PJSC "Bashinformsvyaz" generic_timeout_error US 176.119.42.11 2607:7700:0:18::b077:2a0b T-Mobile USA, Inc. generic_timeout_error US 176.119.42.11 2607:7700:0:1f:0:1:b077:2a0b T-Mobile USA, Inc. generic_timeout_error US 176.119.42.11 2607:7700:0:7::b077:2a0b T-Mobile USA, Inc. generic_timeout_error US 176.119.42.11 T-Mobile USA, Inc. generic_timeout_error US 176.119.42.11 T-Mobile USA, Inc. generic_timeout_error To me this looks like selective denial of service to certain client networks.
Last weeks discussion on this topic: http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-05-12-15.58.log....