[tor-relays] Introduction from lokodlare

Mailing Lists tor-relays
1

Hello Tor relay operators,

I joined this mail list recently and wanted to take the opportunity to shortly introduce myself.

My name is Kristian, I am based in Europe, and I operate all nodes behind the domain lokodlare.com. “Lökodlare” is Swedish for “onion farmers”, which is pretty much what I do.

My goal is to contribute to the Tor network by providing a couple of high-bandwidth nodes all over the globe, preferably at less common providers and/or in niche countries. I will focus on Middle and Guard relays, though I will throw some exits into the mix every now and then with a very reduced exit policy.

I currently operate 90+ relays and bridges with a theoretical bandwidth capacity of roughly 25 Gbit/s. As a snapshot, those nodes handled around 280 TB of Tor-related traffic in the past 24 hours.

I am looking forward to talk/discuss with all of you in the future.

Thanks, have a great Sunday,

Kristian

1 Like
2

Welcome to the tor-relays list,

I was already wondering about that
domain - registered 2 days ago at the time I looked it up in Nov 2021.

preferably at less common providers and/or in niche countries

Great to see someone cares about network diversity.
In that case I'd recommend to stay away from the ISPs
Hetzner and OVH to name two obvious once.

Especially when you are digging for rarely used hosters the hoster field might be useful to publish
for others, because sometimes it is not clear where to order even if the AS is easy to see.

kind regards,
nusenu

btw:
thanks for setting up the CIISS v2 fields including the proof on your relays
https://nusenu.github.io/OrNetStats/lokodlare.com.html

···

--
https://nusenu.github.io
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 Likes
3

Welcome to tor-relays, Kristian. It’s nice to meet a fellow Tor Farmer. It sounds like you are fairly seasoned with quite an extensive deployment of Tor Relays.

Are you performing any loadbalancing with Tor Nodes or are they Individually, Distributed Tor Relays?

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?

I look forward to hear more of your Tor farming practices.

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 Sunday, December 12, 2021, 1:31:09 AM PST, abuse— via tor-relays tor-relays@lists.torproject.org wrote:

Hello Tor relay operators,

I joined this mail list recently and wanted to take the opportunity to shortly introduce myself.

My name is Kristian, I am based in Europe, and I operate all nodes behind the domain lokodlare.com. “Lökodlare” is Swedish for “onion farmers”, which is pretty much what I do.

My goal is to contribute to the Tor network by providing a couple of high-bandwidth nodes all over the globe, preferably at less common providers and/or in niche countries. I will focus on Middle and Guard relays, though I will throw some exits into the mix every now and then with a very reduced exit policy.

I currently operate 90+ relays and bridges with a theoretical bandwidth capacity of roughly 25 Gbit/s. As a snapshot, those nodes handled around 280 TB of Tor-related traffic in the past 24 hours.

I am looking forward to talk/discuss with all of you in the future.

Thanks, have a great Sunday,

Kristian

tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 Likes
4

Hi Gary,

thanks for the warm welcome.

I am currently not performing any load-balancing between my different Tor relays or my physical/virtual servers. Having thought about it a bit, I can only see this make sense if you intend to offer .onion services. I don’t. Maybe I missed something?

I have some bare-metal servers that run multiple instances of Tor to provide multiple relays each and I have some virtual instances (KVM, VMWare) that run a single instance of Tor, providing one relay each. These are hosted at different providers all over the world (see simplified attached graphic).

As each relay is measured by the Tor network individually, is reachable independently and is not “critical” to the rest of the network, I don’t see how load-balancing them could give me or the users of Tor a sizable benefit - as long as I am not running any hidden services. If one relay goes down, there is already an automatic switch-over to a different relay in the network. If one relay is overloaded, this is also detected and (presumably) it will be used less in the future.

What part do you intent to load-balance and to what outcome?

Best Regards,

Kristian

Dec 12, 2021, 15:42 by tor-relays@lists.torproject.org:

···

Welcome to tor-relays, Kristian. It’s nice to meet a fellow Tor Farmer. It sounds like you are fairly seasoned with quite an extensive deployment of Tor Relays.

Are you performing any loadbalancing with Tor Nodes or are they Individually, Distributed Tor Relays?

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?

I look forward to hear more of your Tor farming practices.

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 Sunday, December 12, 2021, 1:31:09 AM PST, abuse— via tor-relays tor-relays@lists.torproject.org wrote:

Hello Tor relay operators,

I joined this mail list recently and wanted to take the opportunity to shortly introduce myself.

My name is Kristian, I am based in Europe, and I operate all nodes behind the domain lokodlare.com. “Lökodlare” is Swedish for “onion farmers”, which is pretty much what I do.

My goal is to contribute to the Tor network by providing a couple of high-bandwidth nodes all over the globe, preferably at less common providers and/or in niche countries. I will focus on Middle and Guard relays, though I will throw some exits into the mix every now and then with a very reduced exit policy.

I currently operate 90+ relays and bridges with a theoretical bandwidth capacity of roughly 25 Gbit/s. As a snapshot, those nodes handled around 280 TB of Tor-related traffic in the past 24 hours.

I am looking forward to talk/discuss with all of you in the future.

Thanks, have a great Sunday,

Kristian

tor-relays mailing list

tor-relays@lists.torproject.org

https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

tor_LB.png
tor_LB.png1041×594 44.4 KB

1 Like
5

What part do you intent to load-balance and to what outcome?

My current implementation is loadbalancing Tor Relay traffic, which provides high availability and economies of scale using existing, cost-effective, bare metal nodes. The same approach could be extrapolated to cost-effective, virtual nodes to a similar benefit.

I suppose the real question is the cost-benefit of deploying to multiple public addresses vs single addresses in a location? I assume that answer is dependent on resource availability and/or the needs of the Tor network (e.g., the recent need for new Tor bridges).

Whichever the situation, it’s nice to know there are multiple solutions to Tor.

Thank you for the overview of your Tor deployments. I hope that I have answered your question regarding my Tor implementation.

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 Monday, December 13, 2021, 2:20:30 AM PST, abuse— via tor-relays tor-relays@lists.torproject.org wrote:

Hi Gary,

thanks for the warm welcome.

I am currently not performing any load-balancing between my different Tor relays or my physical/virtual servers. Having thought about it a bit, I can only see this make sense if you intend to offer .onion services. I don’t. Maybe I missed something?

I have some bare-metal servers that run multiple instances of Tor to provide multiple relays each and I have some virtual instances (KVM, VMWare) that run a single instance of Tor, providing one relay each. These are hosted at different providers all over the world (see simplified attached graphic).

As each relay is measured by the Tor network individually, is reachable independently and is not “critical” to the rest of the network, I don’t see how load-balancing them could give me or the users of Tor a sizable benefit - as long as I am not running any hidden services. If one relay goes down, there is already an automatic switch-over to a different relay in the network. If one relay is overloaded, this is also detected and (presumably) it will be used less in the future.

What part do you intent to load-balance and to what outcome?

Best Regards,

Kristian

Dec 12, 2021, 15:42 by tor-relays@lists.torproject.org:

Welcome to tor-relays, Kristian. It’s nice to meet a fellow Tor Farmer. It sounds like you are fairly seasoned with quite an extensive deployment of Tor Relays.

Are you performing any loadbalancing with Tor Nodes or are they Individually, Distributed Tor Relays?

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?

I look forward to hear more of your Tor farming practices.

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 Sunday, December 12, 2021, 1:31:09 AM PST, abuse— via tor-relays tor-relays@lists.torproject.org wrote:

Hello Tor relay operators,

I joined this mail list recently and wanted to take the opportunity to shortly introduce myself.

My name is Kristian, I am based in Europe, and I operate all nodes behind the domain lokodlare.com. “Lökodlare” is Swedish for “onion farmers”, which is pretty much what I do.

My goal is to contribute to the Tor network by providing a couple of high-bandwidth nodes all over the globe, preferably at less common providers and/or in niche countries. I will focus on Middle and Guard relays, though I will throw some exits into the mix every now and then with a very reduced exit policy.

I currently operate 90+ relays and bridges with a theoretical bandwidth capacity of roughly 25 Gbit/s. As a snapshot, those nodes handled around 280 TB of Tor-related traffic in the past 24 hours.

I am looking forward to talk/discuss with all of you in the future.

Thanks, have a great Sunday,

Kristian

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

6

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

···

On Sun, Dec 12, 2021 at 03:42:12PM +0000, 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?

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

7

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 arma@torproject.org wrote:

On Sun, Dec 12, 2021 at 03:42:12PM +0000, 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

1 Like
8

Roger,

For completeness, I should amend point #3 to include configuring the Loadbalancer’s Timeout to a Large Value:

  1. 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 garycnew@yahoo.com 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 arma@torproject.org wrote:

On Sun, Dec 12, 2021 at 03:42:12PM +0000, 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