My first steps as a bridge operator. Some questions

Support Relay Operator
1

Hi,

I have recently set up an obfs4 bridge. It’s operational and indicates both obfs4: functional and vanilla: functional.

Is it accurate that my bridge provides both obfs4 and vanilla, not exclusively obfs4?

I’ve configured a random high port as ORPort and port 443 as ServerTransportListenAddr obfs4, as clients will connect to my obfs4 port, correct? I’ve already used the bridge line with port 443 in my Tor browser, and it seemed to work well so far.

Since this is my first bridge relay, and I opted for FreeBSD, which I’m not as familiar with as Linux, I selected BridgeDistribution none to observe it over some time.

It’s now listed in relay search with a 16-hour uptime, displaying the flags Running, V2Dir, Valid, and ReachableIPv6, so I presume it’s functioning correctly.

If I wish to put it into “production” now, is it adequate to simply remove BridgeDistribution none and reload the process? Do I need to restart it?

Who then decides which distribution method is used? The authorities? Should I actively choose a method?

Final question: My VPS has a static IP address, but since bridges are eventually blocked by censors, should I migrate the relay to a new VPS after some time? I’ve rented the VPS for 12 months now. Would it be a prudent idea to “replace” the VPS every year to bring up the relay with a new IP address, or should I just let it continue running?

P.S:
I’m already running a guard relay for more then 10 years and two Snowflake proxies at different locations. So the decision to run a bridge now seemed like the next logical step to me.

2

Hi,

Fellow bridge operator here. Nice work! It all looks good to me.

As far as I know you needn’t remove ‘BridgeDistribution none’ if you send your bridgeline to frontdesk@torproject.org where they will distribute it to users.

This page has some useful tips about managing bridge distibution:

I imagine you’ll get some tips here on strategies for using a VPS with a static ip address. You might also post your questions on the matrix channel for Tor Relay Operators #tor-relays:matrix.org (either irc or a matrix client).

Best of luck!

3

Thanks for operating relay and bridges!

Is it accurate that my bridge provides both obfs4 and vanilla, not exclusively obfs4?

yes, though vanilla bridges are not very useful in practice. They are easy to detect, many censors, and some sufficiently smart firewalls, can block them right away.

I’ve configured a random high port as ORPort and port 443 as ServerTransportListenAddr obfs4, as clients will connect to my obfs4 port, correct?

As your bridge appear to be both vanilla and obfs4, you should expect connection to both, but mostly obfs4 as it’s used way more.

If I wish to put it into “production” now, is it adequate to simply remove BridgeDistribution none and reload the process? Do I need to restart it?

It’s enough to remove that line and reload tor.

Who then decides which distribution method is used? The authorities? Should I actively choose a method?

If you don’t specify a distribution mechanism, rdsys/bridgedb (the thing in charge of distributing bridges) will pick one at random, weighted on what might be more useful.

My VPS has a static IP address, but since bridges are eventually blocked by censors, should I migrate the relay to a new VPS after some time?

The answer is probably yes, but defining “some time” is not trivial. On one side, as you said, it’s likely your IP will get blocked by censors after some time. This means rotating IPs is probably a good idea. On the other side, when you change your bridge IP, users which knew about it no longer do (including users somewhere were censors block tor, but lack the capabilities to efficiently block bridges). Once all the bridge they have changed, they have to ask for more bridges, which to them is effectively as if their bridges got blocked.
I think 1 year is long enough that the benefit of changing IP (no longer be blocked by stronger censors) outweigh the cost of breaking a bridge that was working for other people.

Note that there seems to be a bug which causes bridge distribution to sometime get stuck as None on metrics.tpo. If your bridge looks like it’s working, that you get a nice obfs4: functional message from bridges.tpo, but that it’s still being shown as not distributed, the issue is probably not on your side.

1 Like
4

Thanks for your detailed answer!

So can I prevent my bridge from announcing itself as vanilla bridge? This is my config:

BridgeRelay 1
PublishServerDescriptor 1
BridgeDistribution none
ORPort <some-random-high-port>
ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy
ServerTransportListenAddr obfs4 <my-v4-ip>:443
ServerTransportListenAddr obfs4 [<my-v6-ip>]:443
ExtORPort auto
ControlPort 9051
CookieAuthentication 1
ContactInfo <my-email>
SOCKSPort 0
Nickname <name>

So is this a one-time decision or will I get assigned a new distribution mechanism when one becomes more useful than another? I guess I will just let bridgedb decide then.

That’s exactly what I was thinking about. So I might just rotate the server / ip address once a year.

5

Hey trinity-1686a, thanks for clarifying how BridgeDistribution works when you don’t specify a distribution mechanism. I was missing that bit. \o/

6

So what is the solution to configure bridges as obfs4 only and not as vanillla+obfs4 ?