tor-relays

tor-relays@lists.torproject.org

1 participants
4884 discussions

Maybe the next step in russian Tor discrimination
by Tor Relays 03 Jan '22

03 Jan '22

Hello, i have a relay at profitserver.ru at their Chelyabinsk location and recently the relay fell out of the consensus. I can ping all authorities with IPv4 and IPv6 and torproject.org is not blocked. I opened the ControlPort and tried to manually create circuits to the authorities. extendcircuit 0 authoritynickname getinfo circuit-status I observed that i can successfully create circuits to no more than three authorities and it seems to change to which authorities i can create circuits. The unsuccessful circuits stay in EXTENDED but never reach BUILT until Tor gives up eventually. Currently no other of my russian relays are affected. I am not an expert with the ControlPort but i hope this is proving what i tried to prove. Here is the conversation with the support: me: Hello, I am running a (non-exit) Tor relay on the VPS and it stopped working a few weeks ago. I can ping the Tor authorities IP addresses but when i try to manually create a Tor circuit it seems to timeout 6 out of 9 times which indicates some blocking attempts on your (or your upstream providers) side. I have a couple of other Tor relays in russia and i have never seen routinely failing manually created circuits to the Tor authorities. Do you block Tor or do you otherwise mess with Tor traffic? support agent: Hello, i can't say something about TOR network, now. We have black box from government, which can control traffic, and perhaps block TOR. Ourselves don't block TOR me: Thanks for your answer. The TSPU from Roskomnadzor that is doing Deep Packet Inspection? I feel with you and all the russian citizens... :( Good luck support agent: Maybe it's a black box If this is indeed their blackbox messing with Tor traffic then it is quite subtile because it does not block torproject.org and pings to the authorities are going through. The relay suddenly was online for one consensus in the last weeks and i can still use it when i manually set it as a Guard in my Tor client. So if you run a relay in russia and you experience weird stuff with it then you may not only want to check if you can reach the authorities by ping but you may want to try to manually craft a circuit to all of them. Hope that helps anyone Cheers

5 4

running a bridge
by carl box 02 Jan '22

02 Jan '22

4 3

Relay operators meetup @ rC3
by Stefan Leibfarth 29 Dec '21

29 Dec '21

Greetings relay operators, the annual Tor relay operators meetup will be tomorrow (28th) at 2200 UTC+1. No rC3 ticket required, I'll post the public link here as soon as it's available. Looking forward to meeting you Leibi

4 4

[Censorship in Russia] More of my bridges got blocked
by spaceoddity＠disroot.org 29 Dec '21

29 Dec '21

Hello Tor people, just me chipping in about recent event. Today, I discovered that somewhere around Dec, 22, all three of my recently launched bridges have been censored on at least one network (MegaFon Moscow AS25159). Metrics show a drastic traffic drop in the range of Dec, 21-23 for all three bridges. Investigating further, I discovered (using tcptraceroute/nc) that all three hosts started responding with RSTs to all of their open ports (not only bridge ports but SSH and other recently opened ports too). NATd source IP address was unchanged from my usual one in every case. One of the bridges had distribution method set to HTTPS, and the other two were distributed via Moat. All ran recent Tor 0.4.6.8 Docker image. NB: One of the bridges has incorrect 'First seen' date on the metrics portal - it displays '2021-12-25' despite being launched several days prior. To summarize: 1. Bridge blocking happens via the common 'fast RST' method 2. It happened relatively quickly (all bridges are less than 10 days uptime by now). 3. Somehow, all three of my recently launched bridges were blacklisted despite using different ASs/hosters/countries for each. Is it a coincidence, or it's because Moat prefers to hand out newer bridges first, or due to something else entirely? Also, I can not rule out that some step in my distribution chain was compromised -- I gave out these bridges privately to a few friends. -- Best regards, Space Oddity.

3 4

Incorrect "first seen" info
by a tor op 28 Dec '21

28 Dec '21

I notice that the "first seen" info on my obfs4 bridge status page on tor atlas / metrics all of a sudden is incorrect, by years. Not sure if it's something that introduced itself with latest update or what. The various graphs on traffic and users are still correct through. A tor op

3 3

[Censorship in Russia] Make HTTPS/Moat captcha more complex?
by spaceoddity＠disroot.org 27 Dec '21

27 Dec '21

Hi there. I was thinking, what could be the ways Russian authorities could get bridges to block. One of the obvious ways to do this is to grab bridges from Moat/HTTPS, but since that would require solving a captcha, this would indicate its strength is insufficient, or they are able to crowdsource/mass solve somehow. The other thought is an attack via email. Can we do something with it, what do you think? -- Best regards, Space Oddity.

8 10

Moving relay to other VPS
by bobby stickel 27 Dec '21

27 Dec '21

4 4

Re: [tor-relays] Fw: Re: Bridge distribution method stuck at "none"
by - 24 Dec '21

24 Dec '21

Hello again. I'm found it weird that all resources says that "Distribution mechanism" should change after a few days and mine was still "none". So now I'm trying torix's suggestion and deleted the keys and all the /var/lib/tor/ directory, changed nickname and started it again. The hashed fingerprint for my bridge is now: 3B5D1AE581EE4113610E094D5993D6299E64EDEF Its the same torrc file I shared before, just new nickname. This is the log of the last heartbeats is the following, minus timestamps (I will update after one week): /var/log/tor# cat notices.log.1 notices.log | grep Heart | grep -v Accounting [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've sent 1.89 MB and received 5.37 MB. I've received 38 connections on IPv4 and 38 on IPv6. I've made 26 connections with IPv4 and 0 with IPv6. [notice] Heartbeat: In the last 6 hours, I have seen 0 unique clients. [notice] Heartbeat: Tor's uptime is 12:00 hours, with 0 circuits open. I've sent 3.13 MB and received 9.85 MB. I've received 71 connections on IPv4 and 71 on IPv6. I've made 53 connections with IPv4 and 0 with IPv6. [notice] Heartbeat: In the last 6 hours, I have seen 0 unique clients. [notice] Heartbeat: Tor's uptime is 18:00 hours, with 10 circuits open. I've sent 5.93 MB and received 16.49 MB. I've received 141 connections on IPv4 and 140 on IPv6. I've made 85 connections with IPv4 and 0 with IPv6. [notice] Heartbeat: In the last 6 hours, I have seen 0 unique clients. [notice] Heartbeat: Tor's uptime is 1 day 0:00 hours, with 15 circuits open. I've sent 7.37 MB and received 21.77 MB. I've received 175 connections on IPv4 and 174 on IPv6. I've made 114 connections with IPv4 and 0 with IPv6. [notice] Heartbeat: In the last 6 hours, I have seen 0 unique clients. [notice] Heartbeat: Tor's uptime is 1 day 6:00 hours, with 14 circuits open. I've sent 8.46 MB and received 27.03 MB. I've received 194 connections on IPv4 and 193 on IPv6. I've made 136 connections with IPv4 and 0 with IPv6. [notice] Heartbeat: In the last 6 hours, I have seen 0 unique clients. [notice] Heartbeat: Tor's uptime is 1 day 12:00 hours, with 15 circuits open. I've sent 9.47 MB and received 31.66 MB. I've received 212 connections on IPv4 and 210 on IPv6. I've made 162 connections with IPv4 and 0 with IPv6. [notice] Heartbeat: In the last 6 hours, I have seen 1 unique clients. [notice] Heartbeat: Tor's uptime is 1 day 18:00 hours, with 15 circuits open. I've sent 10.64 MB and received 36.48 MB. I've received 229 connections on IPv4 and 227 on IPv6. I've made 181 connections with IPv4 and 0 with IPv6. [notice] Heartbeat: In the last 6 hours, I have seen 0 unique clients. I also added a IPv4 iptables rule just to count the traffic: # iptables -vnL|grep TOR 74451 14M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 6661:6662 /* TOR R */ # Is this ammount of connections/clients normal for the first day of a bridge? Thanks El mar, 21 dic 2021 a las 20:10, torix (<***>) escribió: > I'm writing you at gmail because I got a note from the list admin saying > they couldn't moderate my post because they couldn't decrypt it, so were > refusing it. However, you do seem to have seen my post, so I'm a bit > confused about posting to the list. > > Since you don't seem to be getting anyone connecting with your current > bridge and you are still stuck at "none", I'd think about just deleting the > keys directory: > /var/lib/tor/keys/ in linux > /var/db/tor/keys in freeBSD > This directory holds the actual identity of the tor relay, so if you > delete it and restart tor, it will make a new key and start as a completely > new relay, and give metrics a new chance to give you a bridge type. > The lifecycle of a new relay post which gives a month before it settles in > does not mean that you shouldn't be getting some connections in the first > few days. At least that has been my experience in the last few weeks > putting up a couple of bridges in response to the Tor Project's call. I > started getting 1-5 concurrent connections in the first day. I wish I'd > been paying more attention, but I certainly had a bridge type assigned in > the first or second day of running. > > Good Luck! > > --Torix > > Sent with ProtonMail <https://protonmail.com/> Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Tuesday, December 21st, 2021 at 4:03 PM, - <damisame(a)gmail.com> wrote: > > Hi. > Thanks for the suggestions. > I thought it will take a couple of days to show activity, not a couple of > months. > > This is my torrc: > ------------- > BridgeRelay 1 > BridgeDistribution any > PublishServerDescriptor 1 > Log notice file /dev/shm/tor-notices-bridge.log > RunAsDaemon 1 > RelayBandwidthRate 2000 KB > RelayBandwidthBurst 3000 KB > AccountingMax 5120 GB > AccountingStart month 1 00:00 > ORPort 6661 > ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy > ServerTransportListenAddr obfs4 0.0.0.0:6662 > ExtORPort auto > ContactInfo <address(a)email.com> > Nickname *(editted)* > ------------------ > > Ports 6661-2 are reachable externally. > > https://bridges.torproject.org/status says: > > * obfs4: functional > Last tested: 2021-12-21 04:39:48.514002439 +0000 UTC (11h19m41.110084213s ago) > > > Thanks > > El mar, 21 dic 2021 a las 16:57, <lists(a)for-privacy.net> escribió: > >> On Sunday, December 19, 2021 5:47:29 PM CET - wrote: >> >> > However I dont see practically any traffic besides when I'm using it, >> and >> > on "Relay Search" it shows as "Bridge distribution mechanism: None". >> > The bridge has been up and running for 10 days straigth. >> It can take many weeks or months before the first users start using the >> bridge. >> >> > At first I only had the line: "PublishServerDescriptor 1". >> This is default ... >> >> > After five days, I tried adding "BridgeRelay 1" >> ... if you set 'BridgeRelay 1' (this is absolutely necessary to be a >> bridge) >> >> > and "BridgeDistribution >> > moat", "https" and "any". >> AFAIK only none or any (default) can be set. BridgeDB then automatically >> assigns 'https, moat, Email or reseved' >> >> man torrc | grep Bridge >> BridgeDistribution string >> If set along with BridgeRelay, Tor will include a new line in its bridge >> descriptor which indicates to the BridgeDB service how it would like its >> bridge address to be given out. Set it to "none" if you want BridgeDB to >> avoid distributing your bridge address, or "any" to let BridgeDB decide. >> See https://bridges.torproject.org/info for a more up-to-date list of >> options. (Default: any) >> >> > Neither seems to have produced any change. >> > >> > Is this normal or could I have missed something on the configuration? >> Don't forget obfs4: >> >> ## obfs4 is used because it can do IPv4 and IPv6 connections >> simultaneously >> ## >> https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/README.md >> ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy >> >> ## The ServerTransportListenAddr line is dual stack friendly. >> ServerTransportListenAddr obfs4 [::]:443 >> >> > Thank you. >> If there are further problems, it is best to post your whole torrc: >> ~$ grep ^[^#] /etc/tor/torrc >> >> -- >> ╰_╯ Ciao Marco! >> >> Debian GNU/Linux >> >> It's free software and it gives you >> freedom!_______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > >

1 0

Bridge distribution method stuck at "none"
by - 21 Dec '21

21 Dec '21

Hello. I tried to set up a bridge on an Ubuntu server and it seems working fine. I can connect to it manually from different devices using the bridge address from obfs4_bridgeline.txt file. However I dont see practically any traffic besides when I'm using it, and on "Relay Search" it shows as "Bridge distribution mechanism: None". The bridge has been up and running for 10 days straigth. At first I only had the line: "PublishServerDescriptor 1". After five days, I tried adding "BridgeRelay 1" and "BridgeDistribution moat", "https" and "any". Neither seems to have produced any change. Is this normal or could I have missed something on the configuration? Thank you.

3 3

Tor Relay Operators Survey - Gamification Project - Miko
by Sukeshani Tayade 21 Dec '21

21 Dec '21

*Hello Tor Relay Operators!* My name is Miko and I am an intern via Outreachy.org. I am working on a project to understand Tor Relay Operators and incentivise your relay running experience. You can read more about this project here: https://gitlab.torproject.org/tpo/community/relays/-/issues/26 https://gitlab.torproject.org/tpo/community/relays/-/issues/27 We appreciate your contribution to the Tor Network and want to make your relay running experience better. We would like to hear from you directly. *Please answer the survey below* and be as detailed as you'd like. We're looking forward to your responses! They will be instrumental in directing our mission to serve you better. *SURVEY:* https://survey.torproject.org/index.php/459487

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays