Via @gus, OONI reports in a limited number of ASes in Russia show Tor blocking (blocking of all directory authorities and default obfs4 bridges) since 2021-12-01. This is unusual—the measurements from the days before do not show signs of Tor blocking.
Here are all the ASes in the past 2 days that show anomalous measurements: 0/15 Tor Browser Bridges, 0/10 Tor Directory Authorities. (Select “Status: Anomalies” in the OONI Explorer to see.)
Here is a sampling of ASes (not all of them) that had normal measurements: 13/15 Tor Browser Bridges, 10/10 Tor Directory Authorities.
Note that AS 12389 of Rostelecom is in the above blocked list, but that AS and other ASes of Rostelecom are also in the below unblocked list. Also note that AS 16345 is in both lists—there was one normal measurement for this AS, but about 30 blocked ones.
Tele2 Saint Petersburg SIM (as12958). Tor does not connect in any mode.
All tests were performed using Tor Browser 11.0.1.
Regular (unobfuscated) connection: no response to TCP SYN from multiple IPv4s.
obfs4 connection: no response to TCP SYN from multiple IPv4s.
snowflake: the connection never establishes in full and breaks after several kilobytes transferred.
meek-asure: no response to TCP SYN on default Meek fronting domain ajax.aspnetcdn.com:443 (yes, really, also tested with curl. Domain resolves to 152.199.19.160.).
obfs4 bridges requested from Tor Browser: no successful connection with 176.170.168.5, 213.135.244.242, 82.65.171.173. This is the only bridge set which Torproject returned, I’ve tried to request multiple times and also disconnected and connected again to the cellular network to change my IP.
What worked:
obfs4 bridges requested from bridges.torproject.org: the connection establishes successfully!
obfs4 bridges requested via email: the connection establishes successfully!
My own obfs4 bridge in Russia: the connection establishes successfully!
At least in a single case ajax.aspnetcdn.com is blocked with DPI.
Direct HTTP/HTTPS connections to its 40.118.185.161 and 152.199.19.160 addresses generally work fine, according to ping-admin points.
Globalcheck.net test result. I’m not confident in it — it reports that ajax.aspnetcdn.com is not accessible from cellular Beeline, MTS, MegaFon, Yota (all Moscow), and accessible only from Rostelecom.
However, I’ve performed tests to other known-working hostnames and it lists them as accessible. Strange.
I am scared( It will not stoppng
What can I do to save the freedom? I am a simple man. I am even cannot programming.
VPN services are not usefull for me, as I think. I want to separate the traffic.
Добрый день. У меня на корпоративном тарифе в Ростелекоме ещё с лета стал пропадал доступ к входным нодам тора. Выглядело это так: в промежутке между 11 часами утра по московскому времени и до 13 часов 1-2 раза на 15-40 минут могли быть недоступны адреса входных узлов. Netcat не мог установить соединение и ping не проходил. С любыми другими адресами, в том числе и с соседствующими с недоступными, соединения устанавливались. Проверять все входные ноды я не пробовал, однако по логу тора в этот промежуток времени не было ни одного успешного соедиения. Затем все адреса снова становились доступны. Такое могло происходить каждый день, а могло и неделями не случаться.
@ValdikSS только что протестировал на домру и теле2 Волгоград. На домру все работает идеально, ни одной проблемы. Через теле2 не отвечает вообще НИ ОДИН мост тора.
На теле2 стоит ТСПУ, так что есть предположение, что дело именно в нём и блокируют централизованно, но пока просто тестируют, как это было во время выборов с DoH.
My guess is that Snowflake blocking is being done by fingerprinting and blocking DTLS Server Hello. In 03.Dec.2021.tele2-snowflake.pcapng, we see that HTTPS communication with the Snowflake broker is successful, as are the STUN negotiations with proxies. Then there are several exchanges of:
with different proxy IP addresses. It is as if the Server Hello is never reaching the client. Then, there is an exchange in the opposite direction, where a proxy tries to send a Client Hello to the Snowflake client. In this case, the Snowflake client sends multiple Server Hello, but the proxy does not respond to them:
Client Hello <- proxy
client -> Hello Verify Request
client -> Hello Verify Request
Client Hello <- proxy
client -> Server Hello
client -> Server Hello
client -> Server Hello
client -> Server Hello
client -> Server Hello
client -> Server Hello
client -> Server Hello
client -> Server Hello
client -> Server Hello
client -> Server Hello
Summary: All TCP traffic towards IP addresses of Tor nodes and ajax.aspnetcdn.com is blocked on router (SYN receive no reply regardless of TTL). UDP and ICMP traffic is not blocked.
If we tcp-ping a very close neighbor IP address 154.35.175.224, it pings.
traceroute --tcp --port=443 154.35.175.224
$ sudo traceroute --tcp --port=443 154.35.175.224
traceroute to 154.35.175.224 (154.35.175.224), 30 hops max, 60 byte packets
1 _gateway (192.168.14.1) 1.089 ms 3.542 ms 3.513 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 37.29.105.81 (37.29.105.81) 74.553 ms 86.881 ms 61.471 ms
11 83.169.204.112 (83.169.204.112) 135.780 ms 115.363 ms 83.169.204.116 (83.169.204.116) 94.330 ms
12 83.169.204.70 (83.169.204.70) 86.984 ms 79.724 ms 64.736 ms
13 war-b3-link.ip.twelve99.net (195.12.255.204) 75.706 ms 83.467 ms 88.466 ms
14 hbg-bb4-link.ip.twelve99.net (62.115.118.40) 87.974 ms 100.923 ms 107.544 ms
15 ddf-b2-link.ip.twelve99.net (62.115.115.51) 72.799 ms 70.355 ms 73.094 ms
16 gtt-ic340298-ddf-b2.ip.twelve99-cust.net (62.115.169.81) 73.945 ms 74.145 ms 80.880 ms
17 ae36.cr1-chi1.ip4.gtt.net (89.149.141.165) 181.282 ms 185.423 ms 193.968 ms
…
UDP and ICMP is not blocked.
traceroute --udp --port=443 154.35.175.225
$ sudo traceroute --udp --port=443 154.35.175.225
traceroute to 154.35.175.225 (154.35.175.225), 30 hops max, 60 byte packets
1 _gateway (192.168.14.1) 0.720 ms 1.747 ms 1.724 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 37.29.105.81 (37.29.105.81) 64.332 ms 88.765 ms 74.867 ms
11 83.169.204.112 (83.169.204.112) 113.846 ms 134.836 ms 83.169.204.116 (83.169.204.116) 92.758 ms
12 83.169.204.74 (83.169.204.74) 95.115 ms 83.169.204.70 (83.169.204.70) 80.697 ms 65.303 ms
13 war-b3-link.ip.twelve99.net (195.12.255.204) 72.108 ms 77.991 ms 81.949 ms
14 hbg-bb4-link.ip.twelve99.net (62.115.118.40) 88.956 ms 99.532 ms 101.905 ms
15 ddf-b2-link.ip.twelve99.net (62.115.115.51) 66.823 ms 68.714 ms 70.443 ms
16 gtt-ic340298-ddf-b2.ip.twelve99-cust.net (62.115.169.81) 74.701 ms 74.677 ms 75.864 ms
17 ae36.cr1-chi1.ip4.gtt.net (89.149.141.165) 180.778 ms 185.716 ms 164.883 ms
18 as14987.xe-3-0-0.ar1.ord6.us.as4436.gtt.net (69.31.110.70) 169.592 ms 174.838 ms 168.728 ms
…
TELE2
Exactly the same as on Yota: TCP is filtered, UDP and ICMP works.
$ sudo traceroute --udp 154.35.175.225
traceroute to 154.35.175.225 (154.35.175.225), 30 hops max, 60 byte packets
1 _gateway (192.168.43.209) 2.146 ms 2.106 ms 2.987 ms
2 * * *
3 10.221.3.197 (10.221.3.197) 35.789 ms 38.249 ms 36.699 ms
4 10.221.7.113 (10.221.7.113) 33.829 ms 33.811 ms 33.799 ms
5 10.221.7.126 (10.221.7.126) 38.176 ms 38.163 ms 38.145 ms
6 10.221.66.142 (10.221.66.142) 34.101 ms 28.898 ms 28.865 ms
7 * * *
8 broadband-90-154-105-25.ip.moscow.rt.ru (90.154.105.25) 39.224 ms 39.213 ms 42.975 ms
9 87.226.133.75 (87.226.133.75) 60.395 ms 185.140.148.27 (185.140.148.27) 58.617 ms 57.688 ms
10 ae1-500.cr1-stk3.ip4.gtt.net (77.67.90.96) 79.596 ms 79.577 ms 77.837 ms
11 ae36.cr1-chi1.ip4.gtt.net (89.149.141.165) 183.412 ms 187.280 ms 178.787 ms
12 as14987.xe-3-0-0.ar1.ord6.us.as4436.gtt.net (69.31.110.70) 175.081 ms 161.543 ms 161.505 ms
traceroute --tcp --port=443 154.35.175.224
$ sudo traceroute --tcp --port=443 154.35.175.224
traceroute to 154.35.175.224 (154.35.175.224), 30 hops max, 60 byte packets
1 _gateway (192.168.43.209) 11.726 ms 11.792 ms 11.916 ms
2 * * *
3 10.221.2.197 (10.221.2.197) 55.413 ms 56.740 ms 56.729 ms
4 10.221.7.113 (10.221.7.113) 53.513 ms 53.502 ms 53.590 ms
5 10.221.7.122 (10.221.7.122) 54.237 ms 54.355 ms 55.188 ms
6 * * *
7 * * *
8 broadband-90-154-105-25.ip.moscow.rt.ru (90.154.105.25) 30.587 ms 29.964 ms 29.957 ms
9 185.140.148.27 (185.140.148.27) 51.525 ms 51.471 ms 50.032 ms
10 ae1-500.cr1-stk3.ip4.gtt.net (77.67.90.96) 75.430 ms 64.510 ms 70.755 ms
11 ae36.cr1-chi1.ip4.gtt.net (89.149.141.165) 169.236 ms 160.956 ms 169.096 ms
…
If it still work in browser, then the fingerprint being recognized is the pion WebRTC library, not WebRTC as a whole. It would be possible to evade this blocking by using a browser to forward the traffic.