Why is Tor trying to check the wrong ORPort/DirPort addresses?
Hello everyone. Long story short I have just begun experimenting with running multiple Tor instances on a couple of my servers, namely to see if it actually makes an appreciable difference to my overall throughput. I have multiple public IPs on my servers, and I would like each Tor instance to use its own dedicated address so I have configured the appropriate ip:port addresses in my second torrc file. When I start up the second instance, everything gets bound to the correct ip:port combinations (as specified in my torrc file), and I have no problems getting Tor to bootstrap and successfully open a circuit. The problem appears when Tor tries to verify that my ORPort/DirPort are reachable, because for some reason it's trying to check the wrong IP address? EG - Here are the relevant ports from my torrc file: SocksPort 9053 ControlPort 9063 Log notice file /var/log/tor/notices3.log RunAsDaemon 1 DataDirectory /var/lib/tor/3 ORPort 50.7.178.99:445 DirPort 50.7.178.99:83 When I start Tor, everything matches the above: Jan 08 11:56:23.178 [notice] Opening Socks listener on 127.0.0.1:9053 Jan 08 11:56:23.179 [notice] Opening Control listener on 127.0.0.1:9063 Jan 08 11:56:23.179 [notice] Opening OR listener on 50.7.178.99:445 Jan 08 11:56:23.179 [notice] Opening Directory listener on 50.7.178.99:83 Tor successfully bootstraps and establishes a circuit: Jan 08 11:57:13.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Jan 08 11:57:13.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Jan 08 11:57:13.000 [notice] Bootstrapped 100%: Done BUT THEN ... Jan 08 11:57:13.000 [notice] Now checking whether ORPort 50.7.178.102:444 and DirPort 50.7.178.102:83 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) Notice that it's still checking the correct port from the torrc file, but not the correct ip address. I've tried different IP:port combinations, and each time it's the same result. Right port, wrong IP. I've tried now on two different servers, and had exactly the same results each time. Machines are running Debian 8.0 with Tor 0.2.7.6. I have tried installing from the Debian repo, as well as building from the latest source. No difference. What's causing this to go wrong? Is there something incredibly simple which I'm simply just not doing properly, or is there possibly more going on here than first meets the eye?
On Fri, 8 Jan 2016 23:39:59 +1100 David Tomic <david@tomic.com.au> wrote:
Is there something incredibly simple which I'm simply just not doing properly, or is there possibly more going on here than first meets the eye?
Set the `Address` option in each torrc, otherwise tor will guess. -- Yawning Angel
I have already done that, so that doesn't appear to be the problem. I see exactly the same problem even when I'm only starting up a single instance. Tor binds everything to the correct ip:port, but the reachability test always tries to connect to the .102 ip address. Is it possibly something to do with the way that my network interfaces are configured? FWIW I haven't actually touched anything there, it's still exactly how it was originally provided to me by the host: # cat /etc/network/interfaces # Automatically generated by OnApp (2.3.3) auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 50.7.178.98 netmask 255.255.255.248 broadcast 50.7.178.103 network 50.7.178.96 gateway 50.7.178.97 auto eth0:1 iface eth0:1 inet static address 50.7.178.99 netmask 255.255.255.248 broadcast 50.7.178.103 network 50.7.178.96 post-up ip route add 50.7.178.96/29 dev eth0:1 src 50.7.178.99 table eth0:1_if post-up ip route add default via 50.7.178.97 table eth0:1_if post-up ip rule add from 50.7.178.99 table eth0:1_if post-down ip rule del from 50.7.178.99 table eth0:1_if auto eth0:2 iface eth0:2 inet static address 50.7.178.100 netmask 255.255.255.248 broadcast 50.7.178.103 network 50.7.178.96 post-up ip route add 50.7.178.96/29 dev eth0:2 src 50.7.178.100 table eth0:2_if post-up ip route add default via 50.7.178.97 table eth0:2_if post-up ip rule add from 50.7.178.100 table eth0:2_if post-down ip rule del from 50.7.178.100 table eth0:2_if auto eth0:3 iface eth0:3 inet static address 50.7.178.101 netmask 255.255.255.248 broadcast 50.7.178.103 network 50.7.178.96 post-up ip route add 50.7.178.96/29 dev eth0:3 src 50.7.178.101 table eth0:3_if post-up ip route add default via 50.7.178.97 table eth0:3_if post-up ip rule add from 50.7.178.101 table eth0:3_if post-down ip rule del from 50.7.178.101 table eth0:3_if auto eth0:4 iface eth0:4 inet static address 50.7.178.102 netmask 255.255.255.248 broadcast 50.7.178.103 network 50.7.178.96 post-up ip route add 50.7.178.96/29 dev eth0:4 src 50.7.178.102 table eth0:4_if post-up ip route add default via 50.7.178.97 table eth0:4_if post-up ip rule add from 50.7.178.102 table eth0:4_if post-down ip rule del from 50.7.178.102 table eth0:4_if On 8 January 2016 at 23:43, Yawning Angel <yawning@schwanenlied.me> wrote:
On Fri, 8 Jan 2016 23:39:59 +1100 David Tomic <david@tomic.com.au> wrote:
Is there something incredibly simple which I'm simply just not doing properly, or is there possibly more going on here than first meets the eye?
Set the `Address` option in each torrc, otherwise tor will guess.
-- Yawning Angel
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 9 Jan 2016, at 00:03, David Tomic <david@tomic.com.au> wrote:
I have already done that, so that doesn't appear to be the problem. I see exactly the same problem even when I'm only starting up a single instance. Tor binds everything to the correct ip:port, but the reachability test always tries to connect to the .102 ip address.
What IP addresses does Tor mention in its log as it is starting up?
Is it possibly something to do with the way that my network interfaces are configured? FWIW I haven't actually touched anything there, it's still exactly how it was originally provided to me by the host:
It appears that the Address option hasn't been applied, and Tor is still guessing based on the IP address of the last interface. Please send a HUP to your tor instances after changing their configs, or restart them entirely. As a separate issue, Tor really should use the addresses from the ORPort or DirPort to check reachability (what if they're different?), and fall back to Address if there isn't an explicit address set for either port. This might mean setting Address based on the ORPort address. (But what if they conflict?) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
-- What IP addresses does Tor mention in its log as it is starting up? The ones which I have configured in my torrc file. -- It appears that the Address option hasn't been applied, and Tor is still guessing based on the IP address of the last interface. -- Please send a HUP to your tor instances after changing their configs, or restart them entirely. I have already tried both options, many times now ;) While I'm also seeing exactly the same kind of problem on my second server, the reachability test is always trying to contact the first adapter / ip address there, so it doesn't necessarily seem to be getting stuck on the last interface. On 9 January 2016 at 00:13, Tim Wilson-Brown - teor <teor2345@gmail.com> wrote:
On 9 Jan 2016, at 00:03, David Tomic <david@tomic.com.au> wrote:
I have already done that, so that doesn't appear to be the problem. I see exactly the same problem even when I'm only starting up a single instance. Tor binds everything to the correct ip:port, but the reachability test always tries to connect to the .102 ip address.
What IP addresses does Tor mention in its log as it is starting up?
Is it possibly something to do with the way that my network interfaces are configured? FWIW I haven't actually touched anything there, it's still exactly how it was originally provided to me by the host:
It appears that the Address option hasn't been applied, and Tor is still guessing based on the IP address of the last interface. Please send a HUP to your tor instances after changing their configs, or restart them entirely.
As a separate issue, Tor really should use the addresses from the ORPort or DirPort to check reachability (what if they're different?), and fall back to Address if there isn't an explicit address set for either port. This might mean setting Address based on the ORPort address. (But what if they conflict?)
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Sorry. I've just noticed that the ORPort that it's checking doesn't actually match what I've shown in my torrc file. That's just the result of me playing with different port numbers and then not copying the correct results into my message. Tor is definitely binding the ORPort to the correct port number, and it's trying to verify the correct port number as well. It's only the IP address that's being an issue. I should point out out that I have also tried configuring the DirListenAddress / ORPortListenAddress options as well (despite it saying that they've now been depreciated), and it hasn't made any difference to what's happening. On 8 January 2016 at 23:39, David Tomic <david@tomic.com.au> wrote:
Hello everyone.
Long story short I have just begun experimenting with running multiple Tor instances on a couple of my servers, namely to see if it actually makes an appreciable difference to my overall throughput.
I have multiple public IPs on my servers, and I would like each Tor instance to use its own dedicated address so I have configured the appropriate ip:port addresses in my second torrc file.
When I start up the second instance, everything gets bound to the correct ip:port combinations (as specified in my torrc file), and I have no problems getting Tor to bootstrap and successfully open a circuit.
The problem appears when Tor tries to verify that my ORPort/DirPort are reachable, because for some reason it's trying to check the wrong IP address?
EG - Here are the relevant ports from my torrc file:
SocksPort 9053 ControlPort 9063 Log notice file /var/log/tor/notices3.log RunAsDaemon 1 DataDirectory /var/lib/tor/3
ORPort 50.7.178.99:445 DirPort 50.7.178.99:83
When I start Tor, everything matches the above: Jan 08 11:56:23.178 [notice] Opening Socks listener on 127.0.0.1:9053 Jan 08 11:56:23.179 [notice] Opening Control listener on 127.0.0.1:9063 Jan 08 11:56:23.179 [notice] Opening OR listener on 50.7.178.99:445 Jan 08 11:56:23.179 [notice] Opening Directory listener on 50.7.178.99:83
Tor successfully bootstraps and establishes a circuit: Jan 08 11:57:13.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Jan 08 11:57:13.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Jan 08 11:57:13.000 [notice] Bootstrapped 100%: Done
BUT THEN ... Jan 08 11:57:13.000 [notice] Now checking whether ORPort 50.7.178.102:444 and DirPort 50.7.178.102:83 are reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Notice that it's still checking the correct port from the torrc file, but not the correct ip address. I've tried different IP:port combinations, and each time it's the same result. Right port, wrong IP.
I've tried now on two different servers, and had exactly the same results each time.
Machines are running Debian 8.0 with Tor 0.2.7.6. I have tried installing from the Debian repo, as well as building from the latest source. No difference.
What's causing this to go wrong?
Is there something incredibly simple which I'm simply just not doing properly, or is there possibly more going on here than first meets the eye?
On Fri, 8 Jan 2016 23:39:59 +1100 David Tomic <david@tomic.com.au> wrote:
The problem appears when Tor tries to verify that my ORPort/DirPort are reachable, because for some reason it's trying to check the wrong IP address?
Did you try setting OutboundBindAddress? -- With respect, Roman
I got a little bit excited a few minutes ago when I discovered https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-create... However, that doesn't appear to have made any difference either. For some reason the reachability tests are still insisting on trying to connect to .102. On 9 January 2016 at 00:39, Roman Mamedov <rm@romanrm.net> wrote:
On Fri, 8 Jan 2016 23:39:59 +1100 David Tomic <david@tomic.com.au> wrote:
The problem appears when Tor tries to verify that my ORPort/DirPort are reachable, because for some reason it's trying to check the wrong IP address?
Did you try setting OutboundBindAddress?
-- With respect, Roman
On 9 Jan 2016, at 01:22, David Tomic <david@tomic.com.au> wrote:
I got a little bit excited a few minutes ago when I discovered https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-create... <https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-create.8.txt>
However, that doesn't appear to have made any difference either. For some reason the reachability tests are still insisting on trying to connect to .102.
Tor should only fall back to using an interface address when it fails to parse the Address torrc option. So you may have found a bug in the tor function resolve_my_address(). (Tor should also probably pay attention to the address in the ORPort line when testing reachability, but that's a separate issue.) Can you please choose a tor instance with this issue, and provide: * The exact Address, ORPort and DirPort lines (or the entire torrc, if you're able) * The debug-level log output for the first and second calls to resolve_my_address() * there will be a lot of output here, and it can reveal sensitive info - don't leave debug logging on all the time! Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I have experienced exactly the same problem with similar networking configuration and reported it here: https://trac.torproject.org/projects/tor/ticket/13953 It's being worked on. In your case, however, it appears that the Address argument isn't working and we need to find out why. I only want to highlight not to confuse Address with OutboundBindAddress which are separate things and both needed. The only difference in your setup vs mine is the Debian version (you are on Jessie, I was on Wheezy). Please retry with these lines in the config: ORPort 50.7.178.99:444 DirPort 50.7.178.99:83 OutboundBindAddress 50.7.178.99 Address 50.7.178.99 RunAsDaemon 1 [add your other required config lines such as Log notice file and DataDirectory] Do this for every instance and substitute the IP address and ports per each one. After you make sure the configuration files for all your Tor instances contain the above data do what teor asked and provide the relevant section of the debug log. On 1/9/2016 12:42 AM, Tim Wilson-Brown - teor wrote:
On 9 Jan 2016, at 01:22, David Tomic <david@tomic.com.au <mailto:david@tomic.com.au>> wrote:
I got a little bit excited a few minutes ago when I discovered https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-create...
However, that doesn't appear to have made any difference either. For
some reason the reachability tests are still insisting on trying to connect to .102.
Tor should only fall back to using an interface address when it fails to parse the Address torrc option. So you may have found a bug in the tor function resolve_my_address(). (Tor should also probably pay attention to the address in the ORPort line when testing reachability, but that's a separate issue.)
Can you please choose a tor instance with this issue, and provide: * The exact Address, ORPort and DirPort lines (or the entire torrc, if you're able) * The debug-level log output for the first and second calls to resolve_my_address() * there will be a lot of output here, and it can reveal sensitive info - don't leave debug logging on all the time!
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJWkE8uAAoJEIN/pSyBJlsR54oH/2UqOIL4UugD5024s9q1ZEw4 lp+K8c3vGcgLgI/l2Nm0hI95X1RwX6+bNjmtVpw1oC9Cc4wIM21ngrU9kRiveLZc scoYj+N8bBoyMTpXG01mWEKT/4H5rmvOYdoxYlL5+7tMtGdjGKJ3BigZSk2+D8n+ b1Z5zszr2WElGIF9WNoJCD8iFqCLGUDSCHB0ZJ/+tPqKYqy4ffQT4dyQjscqh26u 6KwxrdnU4GkOYjtW5QYK1LoIvvwVKjjLUSNlTb3D9P6IljzQVfhcDkLw8j0Ksl4r bwG4dfgZ84dteXfK15hGmqidVAC1hJm4+zxRGJ+FrRT7S9k66r7u8Wl0zfw9Fek= =G5K3 -----END PGP SIGNATURE-----
On 9 Jan 2016, at 00:39, Roman Mamedov <rm@romanrm.net> wrote:
On Fri, 8 Jan 2016 23:39:59 +1100 David Tomic <david@tomic.com.au> wrote:
The problem appears when Tor tries to verify that my ORPort/DirPort are reachable, because for some reason it's trying to check the wrong IP address?
Did you try setting OutboundBindAddress?
This will help other relays identify connections from your relay as canonical, but it won't affect the address your relay uses for itself. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
participants (5)
-
David Tomic -
Roman Mamedov -
s7r -
Tim Wilson-Brown - teor -
Yawning Angel