> Date: Tue, 21 Apr 2015 02:13:48 -0400
> From: CJ Ess <zxcvbn4038@gmail.com>
>
> I've been experimenting with a private tor setup - I've managed to setup a
> couple directory authorities, six routers/exit nodes (which seemed to be
> the minimum to bootstrap everything), and a client.

With the latest versions of tor and chutney, the "basic-min" configuration bootstraps a testing tor network with 3 authorities (non-exits), 1 exit relay, and 1 client.

I'm pretty sure this is the minimum number of tor instances to bootstrap, as bootstrapping requires each relay to create a 3-hop path through other relays which have already bootstrapped (or, in this case, the 3 authorities, which assume their own reachability).

I'm not sure if you're using chutney to set up your network.
chutney simplifies the setup of local tor networks using a templating and launch system.
The latest version can be downloaded using:
git clone https://git.torproject.org/chutney.git

> Its a pretty normal
> setup (aside from everything running on my development box) and passes
> traffic as expected.
>
> So I'm wondering what would happen if I set TestingTorNetwork to 0, so I
> picked one onion router instance and made that change.
>
> Because its all running on one box I had to keep some of the special
> settings:
> DirAllowPrivateAddresses 1
> EnforceDistinctSubnets 0
> AuthDirMaxServersPerAddr 0
> AuthDirMaxServersPerAuthAddr 0
> ExtendAllowPrivateAddresses 1
>
> And that almost works, I got this far:
>
> Apr 21 00:50:09.000 [notice] Bootstrapped 100%: Done
> Apr 21 00:50:09.000 [notice] Now checking whether ORPort
> xxx.18.110.101:5106 is reachable... (this may take up to 20 minutes -- look
> for log messages indicating success)
> Apr 21 01:10:09.000 [warn] Your server (xxx.18.110.101:5106) has not
> managed to confirm that its ORPort is reachable. Please check your
> firewalls, ports, address, /etc/hosts file, etc.
> Apr 21 01:30:09.000 [warn] Your server (xxx.18.110.101:5106) has not
> managed to confirm that its ORPort is reachable. Please check your
> firewalls, ports, address, /etc/hosts file, etc.
>
> It looks like the "is reachable" is determined by opening a circuit.
>
> I see this message several times in the logs:
>
> Apr 21 01:38:56.000 [info] channel_tls_process_netinfo_cell(): Got good
> NETINFO cell from xxx.18.110.101:5002; OR connection is now open, using
> protocol version 4. Its ID digest is
> 41373151BCC461FEFEFCC1BAF6DCEFD89922014C. Our address is apparently
> xxx.18.110.101.
>
> I don't see any warnings or errors, it looks like the circuits are being
> opened successfully. Any ideas why this doesn't translate to getting past
> the ORPort being reachable test?

If you're using a version of tor before 0.2.6.1, then it's possible that bug #13924 may be the culprit:
https://trac.torproject.org/projects/tor/ticket/13924
"Reachability testing and channel is_local assume private addresses are local" (and therefore discount the local/private addresses for the purposes of reachability testing).

Alternately, you could have discovered a similar bug which occurs when all tor instances in a network are on the same, public IP address. Please feel free to log a bug if this behaviour is still showing up in tor versions after 0.2.6.1 - and reference #13924 so we know the history of the issue.
https://trac.torproject.org/projects/tor/newticket

You could also disable reachability testing entirely using:
AssumeReachable 1

TestingTorNetworks also allow you to skip several boring minutes of bootstrap by just voting everything a guard and an exit (only in recent versions of tor):
TestingDirAuthVoteExit *
TestingDirAuthVoteHSDir *

Let us know how you go.

teor

teor2345 at gmail dot com
pgp 0xABFED1AC
https://gist.github.com/teor2345/d033b8ce0a99adbc89c5

teor at blah dot im
OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7


_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev