I have seen x unique clients

Support Relay Operator
1

What does it mean?

journalctl -e -u tor@default

shows:

I have seen 0 unique clients.

Rather seldom it shows it would have seen 1 client. But never more than 0 or 1.

Is it good, or is it bad, if no or only one client has being seen?

2

Hello @facebita,

It shows the number of clients that have used your bridge to connect to Tor.

This number varies depending on the distribution method that has been chosen or selected for your bridge.

You can read on this page the different methods : BridgeDB
The most popular is moat. Then you have https, email and reserved.

You can view which distribution method your bridge is currently using by typing the fingerprint on the relay search page : Relay Search

If you want to manually edit the distribution method, use this documentation : How do I change my bridge distribution method? | Tor Project | Support

Thanks for running a bridge for the tor network !

1 Like
3

[quote=“Superpaul209, post:2, topic:2755”]
It shows the number of clients that have used your bridge to connect to Tor.[/quote]

How can I increase the number of clients? My bridge is already online for rather a week. But mostly no client was being seen, best case only one single client. That’s not really a lot I think

Is it right to write moat in lower case in torrc? In https://metrics.torproject.org it is written with upper case M.

I wonder what there is meant by »Transport protocols none«

4

Your bridge should gets a lot of clients every 6 hour in a normal situation (for moat distribution). It varies from 10 to more than 250 depending on the location and bandwidth.

If you choose the moat distribution, yes you can write this setting BridgeDistribution moat into the torrc file.
After applied, you need to restart the tor service and wait one day before seeing it on the relay search page. Its written with upper M on the relay search page.

Distribution mecanism none means that the bridge isn’t sent into the BridgeDB to tor users. It is mainly for testing or private use, it is not recommended because the bridge is not used publicly.

I recommend that you apply moat distribution to your bridge, this is what people in Russia use to get around the censorship now.

5

Obviously, my bridge is not in a confidence-inspiring condition or is completely desolate. As long as my bridge is online I never saw more than maximum one single client within six hours, mostly none.

How can I find what is causing this problem?

6

Can you send which bridge distribution mecanism is actually working on your bridge please ? You can view it on the relay metrics page by typing your bridge’s fingerprint on it.

You could also send the hashed fingerprint in private to help you more.

7

https://metrics.torproject.org is reporting:

Configuration

Nickname

my nickname

OR Addresses

IPv4

Advertised Bandwidth

53 KiB/s

Properties

Hashed Fingerprint

my fingerprint

Uptime

1 day 22 hours 1 minutes and 33 seconds

Flags

Running V2Dir Valid

Additional Flags

none

First Seen

2022-03-24 09:16:14

Last Restarted

2022-03-28 20:17:23

Platform

Tor 0.4.5.10 on Linux

Transport protocols

none

Bridge distribution mechanism

Moat

8

I think I’ve figured out what’s wrong. By rereading the configuration and your previous message I understand better.

Bridge distribution mecanism is correct but the transport protocols none means your bridge couldn’t transport the traffic into tor.
You should have the transport protocol to “obfs4” on your bridge.

obfs4 makes Tor traffic look random, and also prevents censors from finding bridges by Internet scanning. CIRCUMVENTION | Tor Project | Tor Browser Manual

To install this transport protocol, you have to install the package “obfs4proxy” from the official debian repository. They have recently released a new version much more secure which is only on debian backports (its not in the stable repository), for that it is very simple here are the steps:

  1. Add those new sources into the file /etc/apt/sources.list. Dont remove other sources already there, only append these 2 new lines at the end of the file.
deb http://deb.debian.org/debian bullseye-backports main contrib non-free
deb-src http://deb.debian.org/debian bullseye-backports main contrib non-free

  1. sudo apt update

  2. sudo apt -t bullseye-backports install obfs4proxy
    This command will install the latest version of the package with security fixes. Its highly recommend to update it from the backports repository.

  3. Add this config into the torrc file :
    ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
    This line will tell your bridge to execute the transport protocol obfs4

  4. Make sure that you have setup the obfs4 listening port, we recommend that you put port 443 for the obfs4 protocol. It will helps to bypass restrictive firewalls since 443 is allowed everywhere most of the time :

# This port must be externally reachable and must be different from the one specified for ORPort.
# Avoid port 9001 because it's commonly associated with Tor and censors may be scanning the Internet for this port.
ServerTransportListenAddr obfs4 0.0.0.0:TODO2
  1. After everything is done, allow this new port in your router and firewall to your bridge then restart the tor service. You will need to wait between 2 and 24 hours before changes appear on the relay metrics page.

If you need more information, you can read the official documentation : Tor Project | Debian / Ubuntu

I hope everything is clear, I do my best to explain properly. I wait your feedback :slight_smile:

9

Hmm. I think I exactly have followed your instruction. But as far as I can see nothins has changed regarding the number of clients that have being seen, respectivly have not being seen. May be the following to lines can tell you something about what is going wrong:

Server managed proxy encountered a method error. (obfs4 listen tcp 0.0.0.0:443: bind: permission denied)
Managed proxy at '/usr/bin/obfs4proxy' failed the configuration protocol and will be destroyed.

These lines appear approximately 30 seconds after:

sudo service tor restart

when I have entered

journalctl -e -u tor@default
10

It seems there are some problems with permissions, you can try this command to allow binding obfs4 below ports 1024.

sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy

The next thing you have to check is the binary file of the package /usr/bin/obfs4proxy, permissions by default should be 755 (rwxr-xr-x). It means readable and executable by everyone. You can view permissions by doing the command ls -la /usr/bin/obfs4proxy
If permissions are wrong, you can do this command to set the right permissions on the file :

sudo chmod 755 /usr/bin/obfs4proxy

Then restart the tor service and check the logs again to see if its working :+1:

11

The permissions of /usr/bin/obfs4proxy are 755.

I already have executed setcap in the past again and again and restarted the tor service as well.

I have now set the obfs port to a value much more higher than 1024 So - as far as I understand - Tor now not longer can use the most common port 443. But probably I can determine whether the problem is related with using a port below 1024.

I’ll report.

12

Setcap command couldn’t be enough for your OS, you can try to set NoNewPrivileges=no in /lib/systemd/system/tor@default.service and /lib/systemd/system/tor@.service and then run systemctl daemon-reload. Restart the tor service also.

Verify that the setcap has correctly setup the permissions to bind below 1024 by typing the command getcap /usr/bin/obfs4proxy, it will output /usr/bin/obfs4proxy cap_net_bind_service=ep.

When both steps are good, the obfs4proxy will be able to bind to port 443 successfully.

1 Like
13

Eleven clients! I think, now my bridge carries over raging censors. Thank you very much for your patient support!

1 Like