Thus spake Jesus Cea (jcea@xxxxxxx): > On 03/06/11 16:13, tagnaq wrote: > > If one out of 1000 circuits through your relay are failing because you > > filter 443 while relaying 50Mbit/s I would find it acceptable, > > but I fear it are far more. Do you have any stats? (I'm not sure how to > > gather them.) > > Mikes opinion is also be very valuable on such topics. > > If somebody can tell me where to look... You likely need to taylor your iptables rules to also log when you reject these connections: http://www.cyberciti.biz/tips/force-iptables-to-log-messages-to-a-different-log-file.html (Paste your current 443-blocking firewall rules to the list if you need some help creating log lines for them.) Note, this is not a great metric, because each circuit attempt will cause a connection attempt, but if a connection already exists, it will be re-used.. So it is hard to use this to get a baseline of the percentag of circuits your node tends to fail from clients... On the flip side, it will still be an interesting thing to measure, because Tor relay TLS connections are actually bi-directional, meaning that if a relay successfully connects *to* you, you will use that connection for circuits destined for that relay as opposed to trying to make a new connection. With time, you may actually end up connected to most/all of the 443 relays anyway. It would be interesting to see if you are actually blocking any connection attempts at all after being up for a long time. You should end up connected to most/all relays at some point. P.S. Not sure what your rules are, but you should really be using the REJECT target, not the DROP target for satisfying your crazy ISPs policy. DROP will force clients to wait to register a timeout for their circuit, where a REJECT will cause them to get a fail reason back. THe REJECT is thus way better for performance of clients: http://www.readmespot.com/question/f/157375/iptables--reject-vs-drop P.P.S. Your ISP is really crazy. Have you thought about giving them a link to a torstatus directory of Tor IPs so they can feed it to their stupid IDS to whitelist for purposes of outgoing connections? We can probably induce torstatus to produce a csv of this IP set if would help. -- Mike Perry Mad Computer Scientist fscked.org evil labs
Attachment:
pgppINJSEQGzQ.pgp
Description: PGP signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays