On Sat, May 8, 2010 at 1:56 PM, Sebastian Hahn <m...@sebastianhahn.net> wrote: > > On May 8, 2010, at 7:54 PM, Dyno Tor wrote: > >> On Sat, May 8, 2010 at 9:03 AM, John Case <c...@sdf.lonestar.org> wrote: >>> >>> Let's say you run a tor relay with no exit policy: >>> >>> reject *:* >>> >>> And then later you alter that exit policy a bit: >>> >>> accept *:80,reject *:* >>> >>> My understanding is that this system will continue to be used as a >>> non-exit >>> relay, but will then also be used as an exit. That is, it's not going to >>> be >>> monopolized by exit traffic only ... it will do both, right ? >> >> I don't believe this is correct. I think this means you're not an >> exit node at all. > > What do you mean, not an exit node at all? As long as the Tor > process receives a HUP signal or is restarted to notify it of the > config changes, it will become an exit.
Because he has reject *:* first, it won't even look at the commands later. First matching command wins. >> I suspect if you want your node to be an internal relay or have a >> chance at being a guard and still relay some exit traffic, you'll have >> more luck by running two tor instances, which could be on the same >> box. Put them in the same family (although I suppose tor will be >> smart enough to keep them from being used on the same circuit anyway, >> since they'll be on the same IP.) Then you can adjust the bandwidth >> for each instance to be the split you want. > > This is totally incorrect. Tor uses exit nodes in the middle and possibly > even guard position, depending on flags and general scarcity of > guards. Well, you definitely know better than I. I had been under the (false) impression that exit nodes were (at least mostly) used to exit. Why isn't that the case, given that we're constrained by exits? Or am I wrong about that too? *********************************************************************** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/
