[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: opening up (exit policy) a bit ...



On Sat, May 8, 2010 at 1:56 PM, Sebastian Hahn <mail@xxxxxxxxxxxxxxxxx> wrote:
>
> On May 8, 2010, at 7:54 PM, Dyno Tor wrote:
>
>> On Sat, May 8, 2010 at 9:03 AM, John Case <case@xxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/