> And the reason why it's on port 443 is so as to be on a port that's not > likely blocked by network administrators.
That might be useful for the ORPort of a relay, and for the obfs4 port of a bridge, but not for the ORPort of a bridge. Clients are not supposed to connect to it. The only reason it's exposed is because the bridge authority still requires it to verify the bridge is reachable. See https://gitlab.torproject.org/tpo/core/tor/-/issues/7349. You are better of using 443 for the ServerTransportListenAddr, and some high port for ORPort. On Tue, 21 Feb 2023 at 03:05, Keifer Bly <[email protected]> wrote: > > Well, > > So I just changed my torrc to this: > > Nickname gbridge > ORPort 443 > SocksPort 0 > BridgeRelay 1 > PublishServerDescriptor bridge > BridgeDistribution email > ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy > ServerTransportListenAddr obfs4 0.0.0.0:8080 > ExtOrPort auto > Log notice file /var/log/tor/notices.log > ExitPolicy reject *:* > AccountingMax 50 GB > ContactInfo keiferdodderblyyatgmaildoddercom > > Trying to avoid being charged a huge amount for traffic as these VPS > providers can be ridiculous when it comes to that, which is why it was set to > so little. Ran killall -HUP tor to reload it and see that happens in the next > day or so. And the reason why it's on port 443 is so as to be on a port > that's not likely blocked by network administrators. Thank you. > --Keifer > > > On Mon, Feb 20, 2023 at 2:23 PM trinity pointard <[email protected]> > wrote: >> >> Hi, >> >> Your torrc is correct wrt to distribution mechanism (your bridge is >> indicating "bridge-distribution-request any" in the descriptor it >> sends), but for the record, the line would have been >> "BridgeDistribution any". >> A bridge uses less bandwidth than a relay, but it's still a proxy. At >> 5GB per month, you'd be providing a steady 16kbps over the month, or a >> single mbps for little over 11 hours. That's very little, if you can't >> have more bandwidth (by using a provider with no bandwidth accounting, >> or one that gives better pricing per bandwidth), I fear your bridge >> won't be very useful at all. Mine consumes between a few hundred GB >> and a few TB depending on the distribution mechanism. >> >> Are you sure your bridge is reachable? Bridgestrap reports suggest it isn't. >> As the bridge operator, you should know its bridge line. Can you test >> it with Tor Browser to make sure? >> Given your accounting limits, it could be unreachable because >> currently hibernating. Or you could have a firewall issue, or >> something else. >> I believe not passing bridgestrap can explain not being assigned a >> distribution mechanism. >> >> It might also explain why it would be considered blocked in Russia: if >> it's not reachable from anywhere, it's not reachable from Russia. An >> other possibility, given you use 443 for your ORPort, is that your >> bridge was indeed detected by just scanning the whole internet. The >> ORPort is very recognizable (enough that some of my former bridges >> ended up tagged "tor" on Shodan) so it should be put on a port that's >> less likely to be scanned. >> >> Regards, >> trinity-1686a >> >> On Mon, 20 Feb 2023 at 21:29, Keifer Bly <[email protected]> wrote: >> > >> > Where in the torrc file would I set it to any? I am looking for a way to >> > run a bridge without being charged a huge amount of money for it, and I >> > was curious how it would have been detected by Russia if noone had used >> > the bridge there? Thanks. >> > --Keifer >> > >> > >> > On Mon, Feb 20, 2023 at 8:45 AM <[email protected]> wrote: >> >> >> >> On Samstag, 18. Februar 2023 18:56:00 CET Keifer Bly wrote: >> >> > Ok. Here is the torrc file: >> >> > >> >> > GNU nano 3.2 /etc/tor/torrc >> >> > >> >> > >> >> > Nickname gbridge >> >> > ORPort 443 >> >> > SocksPort 0 >> >> > BridgeRelay 1 >> >> > PublishServerDescriptor bridge >> >> > ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy >> >> > ServerTransportListenAddr obfs4 0.0.0.0:8080 >> >> > ExtOrPort auto >> >> > Log notice file /var/log/tor/notices.log >> >> > ExitPolicy reject *:* >> >> > AccountingMax 5 GB >> >> > ContactInfo keiferdodderblyyatgmaildoddercom >> >> > >> >> > >> >> > Where in this torrc file is that configured? >> >> Then set it to 'any' and wait 24-48 hours to see what happens. Maybe >> >> there was >> >> an error in the db. >> >> >> >> If your bridge is still not distributed, it could be due to the outdated >> >> obfs4proxy or because of 'AccountingMax 5 GB'. >> >> Sorry but, 5 GB is a 'fart in the wind' the accounting period would only >> >> be a >> >> few hours a month. It's not even worth distributing them because it would >> >> only >> >> frustrate the users. >> >> >> >> > And how would it be blocked in >> >> > Russia already if it hasn't even been used? >> >> Why should this new feature of the bridgedb, more precisely the rdsys >> >> backend, >> >> have anything to do with whether someone uses a bridge? This is a bridgedb >> >> distribution method introduced by meskio. >> >> >> >> >> >> -- >> >> ╰_╯ Ciao Marco! >> >> >> >> Debian GNU/Linux >> >> >> >> It's free software and it gives you >> >> freedom!_______________________________________________ >> >> tor-relays mailing list >> >> [email protected] >> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > >> > _______________________________________________ >> > tor-relays mailing list >> > [email protected] >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> _______________________________________________ >> tor-relays mailing list >> [email protected] >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > _______________________________________________ > tor-relays mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
