On Tue, Feb 21, 2023 at 1:29 AM trinity pointard <trinity.pointard@gmail.com> wrote:

> 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 <keifer.bly@gmail.com> 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 <trinity.pointard@gmail.com> 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 <keifer.bly@gmail.com> 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 <lists@for-privacy.net> 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
>> >> tor-relays@lists.torproject.org
>> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>> >
>> > _______________________________________________
>> > tor-relays mailing list
>> > tor-relays@lists.torproject.org
>> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>> _______________________________________________
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
> _______________________________________________
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays