How to Run High Capacity Tor Relays

[Mike Perry]

I should have said this in my first post, but I believe that all
subsequent replies should go to tor-relays. This should be the last
post discussing technical details of relay operation on or-talk.


Thus spake coderman (coderman at gmail.com):

> > net.ipv4.tcp_keepalive_time = 1200
> 
> ^- who uses keepalive? :)

Hrmm, Tor does its own application-level keepalive. Perhaps that's how
this got merged in by confusion. Or maybe, like many of these, it was
just a blanket cut+and+paste move out of desperation to try to
increase capacity. The whole superset of voodoo thing.
 
> > net.netfilter.nf_conntrack_tcp_timeout_established=7200
> > net.netfilter.nf_conntrack_checksum=0
> > net.netfilter.nf_conntrack_max=131072
> > net.netfilter.nf_conntrack_tcp_timeout_syn_sent=15
> 
> ^- best to just disable conntrack altogether if you can. -J NOTRACK in
> the raw table as appropriate.
> you're going to each up lots of memory with a decent nf|ip_conntrack_max
> ( check /proc/sys/net/ipv4/netfilter/ip_conntrack_max , etc )

Will this remove the ability to do PREROUTING DNAT rules? I know a lot
of Tor nodes forward ports and even IPs around.

Good suggestion though. Perhaps we should mention both options in the
final draft.

> > [...]
> some dupes in here?
> 
> > net.ipv4.ip_forward=1
> > ...
> > net.ipv4.conf.default.forwarding=1
> > net.ipv4.conf.default.proxy_arp = 1
> 
> ^- BAD! this should not be enabled by default unless you're actually
> routing specifically to guest vm's or between interfaces or something.
> if you enable forwarding by default, someone may use you to relay some
> malicious traffic.

Oh shit, that is a relic of Mortiz's config. He is also planning to
provide VPN and VPS services. Good catch.

Also, does DNAT count as forwarding for the ip_forward option? 
 
> > == Did I leave anything out? ==
> >
> > Well, did I?
> 
> i'd love to see an sca6000 accelerated node.  been working with these
> recently but unfortunately they're allocated for other work...
> (most of the other crypto hw is going to be bus / implementation
> limited to less than what a beefy 64bit modern server can provide, so
> of little utility in this context.)

I'd love to hear Roger and Nick's comments on this, but isn't it
possible this might also bottleneck well before 1Gbit? I am worried it
may depend largely on the architecture of the card and our use of
openssl. Their docs claim "up to 1Gbit" but this could be using highly
parallelized processing, which tor cannot really do, as I understand
it.

Personally I think the hyperthreading option is the lowest hanging
fruit for maxing out a single Tor relay process for lowest cost.

Also, afaik, zero people in the wild are actively running Tor with any
crypto accelerator. May be a very painful process... I'm not really
interested in documenting it unless its proven to scale by actual use.
I want this document to end up with tested and reproduced results
only. You know, Science. Not computerscience ;)


-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20100825/d933a024/attachment.pgp>