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
Chutney sounds really cool, but this is more of a learning exercise so I'll keep at it manually for a bit.
I read someplace that test instances on the public tor are "near useless", so I tried setting TestingTorNetwork 0 on all he routers and one of the directory servers in case there was some logic guarding against instances with different values. The directory authority came up and did participate in consensus generation but never decided that the orport/dirport was reachable. None of the routers did any better. However they do seem to be successfully creating circuits to other routers and the directory authorities. I turned on debug logging and went through it line for line, and if there are any complaints they are not being logged.
It looks like there are only a few bits of code involved in the reachability tests, I'll throw in some printfs and see if I can catch whats happening. That failing I have a good test case I can submit.
I'm using Tor v0.2.6.7 for all this BTW.
On Tue, Apr 21, 2015 at 9:01 AM, teor teor2345@gmail.com wrote:
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
I found the problem here: https://github.com/torproject/tor/blob/cc10f13408e25eaf04f849d0f761680f383fa...
The check for channel_is_local returns true because my dev box has an 172.16/12 address:
https://github.com/torproject/tor/blob/725d6157df150ec9151450dc2422d9838c201...
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@gmail.com wrote:
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
-
CJ Ess -
teor