[tor-dev] Experimenting with private tor setup

[CJ Ess]

I found the problem here:
https://github.com/torproject/tor/blob/cc10f13408e25eaf04f849d0f761680f383fa61d/src/or/circuitbuild.c#L1401

The check for channel_is_local returns true because my dev box has an
172.16/12 address:

https://github.com/torproject/tor/blob/725d6157df150ec9151450dc2422d9838c20187e/src/common/address.c#L389

And thats what is keeping everything from working. I commented out that
address block and now orport, dirport, and bandwidth tests are running.



On Tue, Apr 21, 2015 at 9:01 AM, teor <teor2345 at gmail.com> wrote:

>
> > Date: Tue, 21 Apr 2015 02:13:48 -0400
> > From: CJ Ess <zxcvbn4038 at 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150422/2eabadba/attachment.html>