Re: [tor-relays] General overload -> DNS timeouts
nusenu: To stop confusing operators it would make sense to remove the "This relay is overloaded since" banner from Relay Search for all tor versions prior to 0.4.6.9 and 0.4.7.3-alpha, no? Well, not all potential overload is DNS related overload. There are a bunch of different criteria for emitting a general overload warning. Onionoo and this relay search have a hard time differentiating between DNS related (general) overload and other (general) overload. Thus, I don't think this change is easily to make. I think the best option here is to upgrade swiftly to 0.4.6.9/0.4.7.3-alpha. That said, we should update our documentation accordingly. I've filed a ticket for that.[1] Georg [1] https://gitlab.torproject.org/tpo/web/support/-/issues/279 OpenPGP_signature Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Old question
These responses were automatic. We didn't mention anything about video call. We understand we maybe emailed to a wrong address regarding our issue but why are you purposely making things more complicated for us? Please tell us where we can ask about our issue? Should we open a new issue on Github? maybe you can ask Gus to check his mailbox manually On Thu, Dec 16, 2021 at 10:01 AM Georg Koppen wrote: > Qimam Fellowship: > > What does that mean got blocked? How can we fix it? > > Talking to us (Gus in this case) is a right step in that direction. > > > We emailed to g...@torproject.org and got automatic responses about video > > calls. How can we talk to a live person about our issue? > > Those were no automatic responses. Gus send them and he is pretty much a > live person as any of us. I've met him in real life before the pandemic > for whatever that's worth. > > So, again, hopping on that video call and talking to us is the right and > only way forward. > > Hope this helps, > Georg > > > On Thu, Dec 16, 2021 at 8:16 AM Georg Koppen wrote: > > > >> Qimam Fellowship: > >>> Hello, the Torproject. We launched relays and bridges 3 days ago, today > >> we > >>> received a few emails from nore...@torweather.org saying that our > relays > >>> are down. Your metrics website says our relays are offline, but in fact > >> our > >>> VPS are online and tor daemon is running. The status of our bridges is > >>> displayed as online. > >>> We attached tor daemon log from one of our relays and list of our > relays > >>> and bridges fingerprint. > >>> Is this an error on your metrics website and Tor Weather bot or we > >>> misconfigured something? > >> > >> Neither. Your relays got blocked for the time being and Gus reached out > >> to you to get that sorted out. Please follow-up with him and keep the > >> bad-relays@ list in Cc where the related conversation started. > >> > >> Georg > >> ___ > >> 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
Re: [tor-relays] IPv6
> however I have now noticed a number of malicious login attempts Using a non standard ssh port and blocking power 22 should reduce the bot login attempts. (If you’re running a VPS be sure to test your custom port before blocking 22) I don’t see a relationship between IPv6 and login attempts though. You could have entered your IP on malicious site to test IPv6. Cheers, Murad. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Introduction from lokodlare
Roger, For completeness, I should amend point #3 to include configuring the Loadbalancer's Timeout to a Large Value: 3. Loadbalance using IP Transparency Mode (This was discovered while tirelessly combing through mountains of Tor debug logs), use Sticky Sessions based on Source IP Addresses, and configure Timeout to a Large Value (e.g., 5 minutes or 300 seconds) to allow the Tor instances to detect and deal with any overload state themselves (not the Loadbalancer) Respectfully, Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged) On Tuesday, December 14, 2021, 7:38:52 AM PST, Gary C. New wrote: Hi Roger, I've found the secret to effectively loadbalancing Tor Relay Nodes is as follows: 1. Use the same version of Tor on all Upstream Servers 2. Start/Stop all Upstream Tor Nodes at the same time to keep in sync 3. Loadbalance using IP Transparency Mode (This was discovered while tirelessly combing through mountains of Tor debug logs) and use Sticky Sessions based on Source IP Addresses 4. Configure Upstream Tor Nodes to deliver return packets to the Loadbalancer 5. Configure all Upstream Tor Nodes to use the same DirAuthority and FallbackDir (This is how centralization of statistics is addressed) This configuration has been working well for the past six months. The only dow downsides that I've seen are if an Upstream Tor Node goes down, I have to leave it down or restart all the Upstream Tor Nodes to keep in sync. Occasionally, if a medium-term key is updated, I can see circuits migrate to a single Upstream Tor Node; however, that can be easily discerned and addressed by reviewing centralized syslogs and copying the updated .tordb directory to the other Upstream Tor Nodes with a synced restart. In terms of metrics, the written/read bytes per second is only reported for a single Upstream Tor Node, but that's not a big deal. It would be helpful if metrics were pulled remotely instead pushed. Please provide your email address and I'll be happy to message you directly with the name of my Tor Meta Relay. Respectfully, Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged) On Tuesday, December 14, 2021, 3:39:44 AM PST, Roger Dingledine wrote: On Sun, Dec 12, 2021 at 03:42:12PM +, Gary C. New via tor-relays wrote: > I have a Single Tor Relay comprised of a number of Tor Nodes. I'm always > interested in knowledge sharing related to Tor Loadbalancing. > What are your thoughts on the Pros & Cons of dedicating resources to a > Single, Loadbalanced Tor Relay vs Many, Unloadbalanced Tor Relays by a Tor > Operator? Perhaps, a Hybrid approach? Hi Gary, One of the big downsides to trying to create one "meta" relay out of many independent relays is that each independent relay will make and maintain its own TLS connections with other relays. So while running a fast Tor relay the normal way might end up with roughly one connection to each other relay in the network (which could already be many thousands of connections), doing it the way you describe could result in many times that number of open connections. And even if your local router and systems can handle that many open connections, you're increasing the load on every other relay by forcing them to handle more connections. There will also be more bandwidth use, since each separate TLS connection will use its own keepalive packets to try to stay connected in the face of firewall and NAT timeouts, and also to try to foil rudimentary netflow-based traffic analysis attacks. And because circuits are spread out over many TLS connections, they won't get the privacy protections from being all bundled on a single TLS connection, i.e. a network observer will have an easier time distinguishing which circuit a given cell is for. Which relays are you running in this way? How do you aggregate all of the statistics/etc into a central Tor that publishes a unified relay descriptor? I would expect your meta-relay to have some kind of bizarre breakage, so we should check it out and see if that's true in practice. Thanks, --Roger ___ 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
Re: [tor-relays] General overload -> DNS timeouts
Georg Koppen: Well, not all potential overload is DNS related overload. There are a bunch of different criteria for emitting a general overload warning. Onionoo and this relay search have a hard time differentiating between DNS related (general) overload and other (general) overload. Thus, I don't think this change is easily to make. To have the DNS trigger included in a shared trigger info was a deliberate design decision as I understood it. In my opinion it is better to remove this notice from Relay Search for all affected versions, even if it will also remove the warning in cases where the trigger was not DNS related, because it potentially causes alarm fatique and operators will continue to ignore the banner even after it got improved. I think the best option here is to upgrade swiftly to 0.4.6.9/0.4.7.3-alpha. That is not easy for all of the operators that use the Torproject's Debian repos since these versions are usually not "swiftly" available on deb.torproject.org yet (unless you switch to nightly packages which I wouldn't recommend). currently: Version: 0.4.6.8-1~d10.buster+1 [1] kind regards, nusenu [1] https://deb.torproject.org/torproject.org/dists/buster/main/binary-amd64/Packages -- https://nusenu.github.io ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
