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@xxxxxxxxx): > > 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
Attachment:
pgpeW7eh3qkhq.pgp
Description: PGP signature