After reading every paper and post on sysctl.conf and iptables tuning I could find, and reading some kernel code, I have come to a conclusion that, while there are a few settings to tune (can share mine, but your mileage *will* vary), most of the defaults are actually not broken in the latest kernels, while a lot of tuning recommendations online are outdated.
I enjoyed this guide a lot: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html-single/performance_tuning_guide/index. It is written for Red Hat, but contains quite a few insights applicable to all Linux distributions. - Igor On Sat, Nov 25, 2017 at 3:14 PM, Dhalgren Tor <[email protected]> wrote: >>Well, it's still going on, and is pretty much ruining Libero :( . Running >>CentOS 6, here. >> >>When it's happening it can look like this: >> >># netstat -n | grep -c SYN >>17696 > > I run a fast exit and can offer some advice: > > 1) mitigate bug #18580 (also #21394); is a DNS denial-of-service and > could be the problem. either upgrade to 0.3.2.4+ or edit resolve.conf > per > https://trac.torproject.org/projects/tor/wiki/doc/DnsResolver#TuningeventdnscomponentofTorDaemon > > also check out https://arthuredelstein.net/exits/ > > 2) if you continue to experience excessive outbound scanning SYNs, > I've found that simply enabling connection tracking helps by > implicitly limiting the rate a which connections can originate. If an > iptables "-m state --state ESTABLISHED,RELATED -j ACCEPT" rule exists > it will turn it on or you could modprobe the module if you don't want > to configure incoming connection rules. > > some useful sysctl.conf changes, run sysctl -p after or reboot > > # Tor Exit tuning. > net.ipv4.ip_local_port_range = 1025 65535 > net.ipv4.tcp_synack_retries = 2 > net.ipv4.tcp_max_tw_buckets = 4194304 > net.ipv4.tcp_tw_recycle = 1 > net.ipv4.tcp_fin_timeout = 30 > net.ipv4.tcp_keepalive_time = 300 > net.ipv4.tcp_keepalive_intvl = 10 > net.ipv4.tcp_keepalive_probes = 3 > net.netfilter.nf_conntrack_tcp_timeout_established = 1000 > net.netfilter.nf_conntrack_checksum = 0 > > you might see many messages: > > kernel: nf_conntrack: table full, dropping packet > > which indicates no connection table slots were available for an > outbound connection and that rate limiting is effected > > state of connection tracking appears in /proc/net/nf_conntrack > _______________________________________________ > tor-relays mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
