Yes :(
1) Blanket caching on port 80 is mostly fine, but not completely due to squid dropping/erroring on non-http traffic. Not acceptable. 2) I've been unable to find a way to pass non-http traffic in a reliable way. 3) netfilter inspection to determine protocol ends with the layer7 filter project which appears to dead. I might be able to nudge the inspection capabilities up to current 3.x kernels but that's iffy, but either way it isn't currently functional or even functional-adjacent. 4) A *gobsmackingly large* (40k+) amount of CLOSE_WAIT connections to squid gets setup over a period few hours, and I'm at a bit of a loss as to why.
I've never had this problem before with previous personal or professional usage of squid...
This breaks the fuck out of everything anyway after a few hours.
I am unmoved by the philosophical considerations. But there are serious practical ones that I didn't fully think through. So, the puppet manifest for squid gets put away again and the iptables rule is removed until I can solve the above problems.
I'm keeping DNS caching though. DNS gets to be pretty slow, as seen from this segment of the bind statistics output:
283152 queries with RTT < 10ms 1724419 queries with RTT 10-100ms 1006967 queries with RTT 100-500ms 60675 queries with RTT 500-800ms 48536 queries with RTT 800-1600ms 2961 queries with RTT > 1600ms
I assume everyone's ok with that, right? :p
On Sat, Jan 10, 2015 at 4:11 AM, Nusenu BM-2D8wMEVgGvY76je1WXNPfo8SrpZt5yGHES@bitmessage.ch wrote:
On Fri, Jan 9, 2015 at 6:29 PM, Nusenu
Are you saying you are routing exit traffic through a transparent squid http proxy?
If that is the case, please do not interfere with exit traffic in any way.
eric gisse:
Why?
Is your exit breaking non-HTTP protocolls on destination port 80?
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays