Hi, Danny
Those theoretical concerns may or may not be valid as I don't have
enough expertise about how Tor operates under the hood to comment on it,
but I can tell you that currently there are a few different DDoS attacks
with different purposes but they don't seem to have the surgical
accuracy
> DDoS rate limit filters do not require an all or nothing approach,
> different source IPs can be handled differently
> see toralf's use of onionoo to feed ipsets as an example.
> I would recommend to use tor's controlport as a source of information instead
> though
> because onionoo is not
@Enkidu
As an user of your filtering script, I want to first say thank you for
maintaining the script!
> The idea that all relays must be able to connect to other relays any time
and in any shape or form they choose can not exist in real world of DDoS
mitigation.
I totally agree, however I want
On Wed, Feb 08, 2023 at 12:07:22AM +0100, nusenu wrote:
> I recall a gitlab.tpo issue that discussed the details of whether
> tor clients should change guards when their picked guard lost/gained flags.
> Maybe someone else could paste a link to it.
This might be the one you want:
Hi,
to reduce the risk that your multi-instance tor relay setup triggers
false-positive filter thresholds on other relays, I recommend you make use of
the
OutboundBindAddress (or OutboundBindAddressOR)
option and set it to the same IP as in the ORPort line.
This will ensure that the outbound
Even if that happens, why would a client connect
directly to an Exit and get the
Exit to connect to another relay or Guard using the Exit's IP address?
You mentioned the exit flag, but you didn't specify whether that relay also had
the guard flag.
Generally speaking it is correct, that if you
@nusenu
Thank you very much for taking the time to help me understand things
better. I can use all the help I can get.
> You can also not be sure whether it is an actual authenticated
relay to relay
> connection or a client to relay connection just by looking at the
source IP.
> In
