Setting up a private tor network

[Csaba Kiraly]

Karsten Loesing wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Csaba,
>
>   
>> I have seen similar error and warning messages to what you have 
>> mentioned, both with 0.1.2.17 and with 0.2.0.8-alpha.
>>     
>
> Quoting from your private mail (with your permission):
>   
>> I've seen in your doc that you are killing and restarting Tor
>> instances in order to have the thing running. I have also seen a note
>> on that, but till now I was trying to avoid that, I was hoping that
>> there is a combination of configurations with which things start up
>> smoothly. Before I go into the restart game, I would like to be sure
>> if my torrc files are good or not.
>>     
>
> In PuppeTor I did not get 0.2.0.8-alpha to work in a private network
> setting, but only versions up to 0.2.0.7-alpha. Further, the current
> trunk (or what will become 0.2.0.9-alpha these days) introduces the new
> v3 directories that make things a little bit more complicated:
>
> The solution for building a private network with all versions up to
> 0.2.0.7-alpha is to periodically send HUP signals to the nodes until
> they start building circuits. In principal you don't have to, but it
> accelerates things a lot; as an example, I tried to create a private
> network with 2 directories and 4 routers _without_ sending HUP commands:
> 3 out of 10 attempts built circuits after 15 minutes and a few seconds,
> and the other 7 attempts took 60 minutes and a few seconds for it. The
> multiples of 15 minutes should come from the interval in which directory
> mirrors fetch networkstatuses from the directory authorities. When
> sending HUP signals, the whole process takes about half a minute. The
> reason is that directory mirrors refetch the networkstatus immediately
> when reloading their configuration. As a side note: proxies behave
> differently for this. If you want to read more, have a look at the
> Javadocs of PuppeTor's ProxyNode class:
> https://tor-svn.freehaven.net/svn/puppetor/trunk/src/de/uniba/wiai/lspi/puppetor/ProxyNode.java
>
>   
I've seen the long delays in the clients (running as Tor proxy nodes) 
before they were able to build
circuits. Smaller (but still huge) delays in the routers, and some 
delays in the authoritative directories.
What surprised me, however, is how casual the behavior is. Is there some 
casualty intentionally in
the protocol? Or is it just the result of concurrence between the nodes 
that we start up almost
simultaneously? I don't know yet but it was e.g. strange to see how the 
three routers I was starting
up behaved differently.

> In 0.2.0.8-alpha-dev (and newer versions) you need to configure v3
> directory authorities to get things working. There is a description how
> to do this here:
> https://tor-svn.freehaven.net/svn/tor/trunk/doc/v3-authority-howto.txt .
> In order to speed up the process you can configure Tor to build
> consensuses in shorter intervals. The following configuration worked for
> me: V3AuthVotingInterval 10 minutes, V3AuthVoteDelay 1 minute,
> V3AuthDistDelay 1 minute. Unfortunately, the process still takes about
> half an hour, so this is only a first solution to get it working. If you
> find a better solution, please let us know!
>
>   
After seeing your comments on difficulties with v3, I have decided to 
postpone experiments with
0.2.0.8-alpha. I'm concentrating on stabilizing the environment at the 
moment. Then I think we might
use the two environments to cross-check results.
>> After seeing PuppeTor I've realized that mine is quite similar to it
>> in its goals, [...]
>>     
>
> First of all, it's good to have multiple approaches to this problem. We
> could both learn from the other approach and improve our tools.
>
> My decision to not use a virtual machine for each node was that I did
> not see why it should be necessary. In PuppeTor every Tor node has it's
> own working directory and set of ports and should not interfere with the
> other local Tor processes. The only output that I care about is what Tor
> writes to its log files. My primary motivation for writing PuppeTor was
> to test my developments on Tor hidden services which are rather
> high-level in Tor.
>
> However, when it comes to lower levels, like sniffing or altering
> packets, my approach might be too limited. I'm not sure about that,
> because I rarely used that. Thus, there is room for other approaches! :)
>   
I see your point, and I have to say I had similar reasons to go for a 
low-level emulation approach.
First of all, I was more interested in Tor performance at the 
transmission level. Here, especially if
thinking of using datagrams instead of TCP tunnels, packet level capture 
and more control over the
network environment helps.

I did not study the logging part of the code, but when I see a packet 
flying on the net, I know there was
communications, and when there is none, I know there wasn't. Logging 
(which, btw, is very nice and
extensive in Tor) gives an explanation of what the developer thinks 
about the event, or about the cause,
but it could be misleading. It was also not explaining me the problems I 
had with DNS during the setup
of the private Tor network, while the sniffer showed what is happening.

Csaba