Hi all, something very strange is going on with my relay called torworld. For some reason, the tor software is reporting that the relay is reachable and the relay is sending and receiving data (please see the attached screenshot), but after several days the relay is not appearing on the tor relay list. This seems strange and any ideas as to why this might be happening is appreciated. Thank you.
running on Debian via Google Cloud VPS. Thank you. --Keifer
Hi,
On 21 May 2019, at 16:11, Keifer Bly keifer.bly@gmail.com wrote:
Hi all, something very strange is going on with my relay called torworld.
This looks like the same question as your previous thread: https://lists.torproject.org/pipermail/tor-relays/2019-May/017317.html
Did you assign a static address to your relay? Did you set up port forwarding correctly?
Your relay is only receiving a few connections (5) from the outside.
But you should be seeing many more connections. At least 1 connection from each of 9 authorities, every few hours.
T
Yes, the reserved external ip is 104.154.93.253 https://104.154.93.253/, and the port is allowed on the firewall. So the relay should appear now. Please check if it is reachable and I will keep checking it over the next few hours. Thanks. --Keifer
On Tue, May 21, 2019 at 1:16 AM teor teor@riseup.net wrote:
Hi,
On 21 May 2019, at 16:11, Keifer Bly keifer.bly@gmail.com wrote:
Hi all, something very strange is going on with my relay called torworld.
This looks like the same question as your previous thread: https://lists.torproject.org/pipermail/tor-relays/2019-May/017317.html
Did you assign a static address to your relay? Did you set up port forwarding correctly?
Your relay is only receiving a few connections (5) from the outside.
But you should be seeing many more connections. At least 1 connection from each of 9 authorities, every few hours.
T
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi, so the relay in question does indeed have a reserved Static IP (104.154.93.253), and the traffic is allowed by the firewall, but the relay is still not appearing in the consensus. The port it's running on is 65534. This is starting to seem odd.....any thoughts are appreciated. Thanks. --Keifer
On Tue, May 21, 2019 at 11:58 AM Keifer Bly keifer.bly@gmail.com wrote:
Yes, the reserved external ip is 104.154.93.253 https://104.154.93.253/, and the port is allowed on the firewall. So the relay should appear now. Please check if it is reachable and I will keep checking it over the next few hours. Thanks. --Keifer
On Tue, May 21, 2019 at 1:16 AM teor teor@riseup.net wrote:
Hi,
On 21 May 2019, at 16:11, Keifer Bly keifer.bly@gmail.com wrote:
Hi all, something very strange is going on with my relay called torworld.
This looks like the same question as your previous thread: https://lists.torproject.org/pipermail/tor-relays/2019-May/017317.html
Did you assign a static address to your relay? Did you set up port forwarding correctly?
Your relay is only receiving a few connections (5) from the outside.
But you should be seeing many more connections. At least 1 connection from each of 9 authorities, every few hours.
T
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Tue, 21 May 2019 23:36:28 -0700 Keifer Bly keifer.bly@gmail.com wrote:
Hi, so the relay in question does indeed have a reserved Static IP (104.154.93.253), and the traffic is allowed by the firewall, but the relay is still not appearing in the consensus. The port it's running on is 65534. This is starting to seem odd.....any thoughts are appreciated. Thanks. --Keifer
Indeed, I don't have any problem connecting to your relay with openssl from multiple locations (at least Russia, Netherlands and Germany):
$ openssl s_client -connect 104.154.93.253:65534 <snip> Certificate chain 0 s:CN = www.tvxaieaqsu6ibfe54.net i:CN = www.ak737rvyioit.com <snip> --- No client certificate CA names sent Peer signing digest: SHA512 Peer signature type: RSA Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 801 bytes and written 419 bytes Verification error: unable to verify the first certificate --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384
So far it seems it has to work.
Hi,
On 23 May 2019, at 18:41, Dmitrii Tcvetkov demfloro@demfloro.ru wrote:
On Tue, 21 May 2019 23:36:28 -0700 Keifer Bly keifer.bly@gmail.com wrote:
Hi, so the relay in question does indeed have a reserved Static IP (104.154.93.253), and the traffic is allowed by the firewall, but the relay is still not appearing in the consensus. The port it's running on is 65534. This is starting to seem odd.....any thoughts are appreciated. Thanks. --Keifer
Indeed, I don't have any problem connecting to your relay with openssl from multiple locations (at least Russia, Netherlands and Germany):
$ openssl s_client -connect 104.154.93.253:65534
<snip> Certificate chain ...
I can't find a relay called "torworld" or at "104.154.93.253" on the tor network: * using consensus health, which shows relays with votes: https://consensus-health.torproject.org/ * or relay search, which shows relays in the consensus: https://metrics.torproject.org/rs.html#search/104.154.93.253
Please copy and paste the latest logs from your relay the last time you started it up. We need to see logs that cover your relay's: * tor version, * role (relay or bridge), * nickname, * fingerprint, * IPv4 address, * reachability self-test, and * descriptor posts to authorities.
We might need info-level logs to see some of these things.
Do you know if Google supports tor relays? They could be blocking some connections.
T
Hi all, so this is the tor log since the last restart. It includes the relay fingerprint. The tor version is (0.2.9.16-1). When I tried updating tor I got a message saying that was the newest version. The relay has an assigned static ip and port which are both allowed by the firewall. It seems strange that Dmitrii Tcvetkov was able to reach the relay though teor cannot, also that the relay says it is reachable and receiving traffic but not appearing in the relay list. It seems like the relay would not be able to start at all if Google was blocking it. Thanks very much for the help.
May 21 20:01:30.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. May 21 20:01:32.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. May 21 20:01:32.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. May 21 20:01:32.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't. May 21 20:01:33.000 [notice] Your Tor server's identity key fingerprint is 'torworld 3A4E582092E7C6B822EC01F4D76F680F6C65B0A2' May 21 20:01:33.000 [notice] Bootstrapped 0%: Starting May 21 20:03:53.000 [notice] Bootstrapped 80%: Connecting to the Tor network May 21 20:03:54.000 [notice] Guessed our IP address as 104.154.93.253 (source: 128.31.0.34). May 21 20:03:56.000 [notice] Bootstrapped 85%: Finishing handshake with first hop May 21 20:03:56.000 [notice] Bootstrapped 90%: Establishing a Tor circuit May 21 20:03:58.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. May 21 20:03:58.000 [notice] Bootstrapped 100%: Done May 21 20:03:58.000 [notice] Now checking whether ORPort 104.154.93.253:65534 is reachable... (this may take up to 20 minutes -- lookfor log messages indicating success) May 21 20:04:01.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. May 21 20:05:08.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 156 buildtimes. May 21 20:05:12.000 [notice] Performing bandwidth self-test...done. May 22 02:03:53.000 [notice] Heartbeat: It seems like we are not in the cached consensus. May 22 02:03:53.000 [notice] Heartbeat: Tor's uptime is 5:59 hours, with 0 circuits open. I've sent 1.13 MB and received 8.70 MB. May 22 02:03:53.000 [notice] Average packaged cell fullness: 100.000%. TLS write overhead: 21% May 22 02:03:53.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 22/22 NTor. May 22 02:03:53.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 29 v4 connections; and received 1 v1 connections, 0 v2 connections, 0 v3 connections, and 21 v4 connections. May 22 02:03:53.000 [notice] DoS mitigation since startup: 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. May 22 08:03:53.000 [notice] Heartbeat: It seems like we are not in the cached consensus. May 22 08:03:53.000 [notice] Heartbeat: Tor's uptime is 11:59 hours, with 0 circuits open. I've sent 1.29 MB and received 16.06 MB. May 22 08:03:53.000 [notice] Average packaged cell fullness: 100.000%. TLS write overhead: 21% May 22 08:03:53.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 0/0 NTor. May 22 08:03:53.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 29 v4 connections; and received 1 v1 connections, 0 v2 connections, 0 v3 connections, and 21 v4 connections. May 22 08:03:53.000 [notice] DoS mitigation since startup: 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. May 22 14:03:53.000 [notice] Heartbeat: It seems like we are not in the cached consensus. May 22 14:03:53.000 [notice] Heartbeat: Tor's uptime is 17:59 hours, with 0 circuits open. I've sent 1.44 MB and received 22.35 MB. May 22 14:03:53.000 [notice] Average packaged cell fullness: 100.000%. TLS write overhead: 21% May 22 14:03:53.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 0/0 NTor. May 22 14:03:53.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 29 v4 connections; and received 1 v1 connections, 0 v2 connections, 0 v3 connections, and 21 v4 connections. May 22 14:03:53.000 [notice] DoS mitigation since startup: 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. May 22 20:03:53.000 [notice] Heartbeat: It seems like we are not in the cached consensus. May 22 20:03:53.000 [notice] Heartbeat: Tor's uptime is 23:59 hours, with 0 circuits open. I've sent 1.58 MB and received 29.42 MB. May 22 20:03:53.000 [notice] Average packaged cell fullness: 100.000%. TLS write overhead: 21% May 22 20:03:53.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 0/0 NTor. May 22 20:03:53.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 29 v4 connections; and received 1 v1 connections, 0 v2 connections, 0 v3 connections, and 21 v4 connections. May 22 20:03:53.000 [notice] DoS mitigation since startup: 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. May 23 02:03:53.000 [notice] Heartbeat: It seems like we are not in the cached consensus. May 23 02:03:53.000 [notice] Heartbeat: Tor's uptime is 1 day 5:59 hours, with 0 circuits open. I've sent 1.72 MB and received 36.42 MB. May 23 02:03:53.000 [notice] Average packaged cell fullness: 100.000%. TLS write overhead: 21% May 23 02:03:53.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 0/0 NTor. May 23 02:03:53.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 29 v4 connections; and received 1 v1 connections, 0 v2 connections, 0 v3 connections, and 21 v4 connections. May 23 02:03:53.000 [notice] DoS mitigation since startup: 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. May 23 08:03:53.000 [notice] Heartbeat: It seems like we are not in the cached consensus. May 23 08:03:53.000 [notice] Heartbeat: Tor's uptime is 1 day 11:59 hours, with 0 circuits open. I've sent 1.82 MB and received 42.16MB. May 23 08:03:53.000 [notice] Average packaged cell fullness: 100.000%. TLS write overhead: 21% May 23 08:03:53.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 0/0 NTor. May 23 08:03:53.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 29 v4 connections; and received 1 v1 connections, 0 v2 connections, 0 v3 connections, and 21 v4 connections. May 23 08:03:53.000 [notice] DoS mitigation since startup: 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. May 23 14:03:53.000 [notice] Heartbeat: It seems like we are not in the cached consensus. May 23 14:03:53.000 [notice] Heartbeat: Tor's uptime is 1 day 17:59 hours, with 0 circuits open. I've sent 1.96 MB and received 48.91MB. May 23 14:03:53.000 [notice] Average packaged cell fullness: 100.000%. TLS write overhead: 21% May 23 14:03:53.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 0/0 NTor. May 23 14:03:53.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 29 v4 connections; and received 1 v1 connections, 0 v2 connections, 0 v3 connections, and 21 v4 connections. May 23 14:03:53.000 [notice] DoS mitigation since startup: 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. May 23 20:03:53.000 [notice] Heartbeat: It seems like we are not in the cached consensus. May 23 20:03:53.000 [notice] Heartbeat: Tor's uptime is 1 day 23:59 hours, with 0 circuits open. I've sent 2.07 MB and received 54.87MB. May 23 20:03:53.000 [notice] Average packaged cell fullness: 100.000%. TLS write overhead: 21% May 23 20:03:53.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 0/0 NTor. May 23 20:03:53.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 29 v4 connections; and received 1 v1 connections, 0 v2 connections, 0 v3 connections, and 21 v4 connections. May 23 20:03:53.000 [notice] DoS mitigation since startup: 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. --Keifer
On Thu, May 23, 2019 at 2:09 PM teor teor@riseup.net wrote:
Hi,
On 23 May 2019, at 18:41, Dmitrii Tcvetkov demfloro@demfloro.ru wrote:
On Tue, 21 May 2019 23:36:28 -0700 Keifer Bly keifer.bly@gmail.com wrote:
Hi, so the relay in question does indeed have a reserved Static IP
(104.154.93.253), and the traffic is allowed by the firewall, but the
relay is still not appearing in the consensus. The port it's running
on is 65534. This is starting to seem odd.....any thoughts are
appreciated. Thanks. --Keifer
Indeed, I don't have any problem connecting to your relay with openssl from multiple locations (at least Russia, Netherlands and Germany):
$ openssl s_client -connect 104.154.93.253:65534
<snip> Certificate chain ...
I can't find a relay called "torworld" or at "104.154.93.253" on the tor network:
- using consensus health, which shows relays with votes: https://consensus-health.torproject.org/
https://metrics.torproject.org/rs.html#search/104.154.93.253
- or relay search, which shows relays in the consensus:
Please copy and paste the latest logs from your relay the last time you started it up. We need to see logs that cover your relay's:
- tor version,
- role (relay or bridge),
- nickname,
- fingerprint,
- IPv4 address,
- reachability self-test, and
- descriptor posts to authorities.
We might need info-level logs to see some of these things.
Do you know if Google supports tor relays? They could be blocking some connections.
T
Hi,
On 24 May 2019, at 09:19, Keifer Bly keifer.bly@gmail.com wrote:
Hi all, so this is the tor log since the last restart. It includes the relay fingerprint. The tor version is (0.2.9.16-1).
The log you posted is missing a few lines at the start, including the lines that tell us the tor version.
We need to see the tor version that is *running*, not the tor version that you installed. Just in case they are different. (Authorities reject really old Tor versions.)
When I tried updating tor I got a message saying that was the newest version.
It looks like you're on Debian or Ubuntu, please follow these instructions to update: https://2019.www.torproject.org/docs/debian.html.en
The relay has an assigned static ip and port which are both allowed by the firewall. It seems strange that Dmitrii Tcvetkov was able to reach the relay though teor cannot,
We looked in different places:
Dmitrii connected to the IP and ports of your relay using SSL. I looked for your relay in the votes and the consensus, but I did not find it.
also that the relay says it is reachable and receiving traffic but not appearing in the relay list.
I think your relay is not publishing its descriptor. See my comments below about the relay log.
It seems like the relay would not be able to start at all if Google was blocking it.
There are lots of different ways to block relays. Some let the relay start, but it never gets in the consensus. But I don't think that has happened to your relay.
May 21 20:01:32.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't.
I don't know how you are configuring and running your relay. Using a guided relay configuration tool might help you. See my suggestion below.
May 21 20:01:33.000 [notice] Your Tor server's identity key fingerprint is 'torworld 3A4E582092E7C6B822EC01F4D76F680F6C65B0A2'
I have confirmed that this fingerprint is not in the votes or consensus.
May 21 20:01:33.000 [notice] Bootstrapped 0%: Starting May 21 20:03:53.000 [notice] Bootstrapped 80%: Connecting to the Tor network May 21 20:03:54.000 [notice] Guessed our IP address as 104.154.93.253 (source: 128.31.0.34).
128.31.0.34 is the IP address of moria1, so your relay can connect to the directory authorities. That means that Google isn't blocking connections out.
May 21 20:03:58.000 [notice] Bootstrapped 100%: Done May 21 20:03:58.000 [notice] Now checking whether ORPort 104.154.93.253:65534 is reachable... (this may take up to 20 minutes -- lookfor log messages indicating success) May 21 20:04:01.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent.
Your relay and Dmitrii have confirmed that this port is reachable from the outside.
But your relay log does not say "Publishing server descriptor." That's why your relay is not in the votes or the consensus.
So we need to answer these questions: * Is your relay configured as a bridge? * Is your relay configured to *not* publish its descriptor? (Relays publish their descriptors by default.)
Please copy and paste your torrc into your next email.
Your logs were also missing these things:
- tor version,
- role (relay or bridge), and
- descriptor posts to authorities.
Please post the parts of your logs that contain this information. There is no need to paste more than 2 repetitions of the Heartbeat/Cell/Circuit/Connection/DoS lines.
You seem to have a lot of trouble configuring relays manually. You might have a better experience with a guided setup tool, like this Tor Relay role in Ansible: https://github.com/nusenu/ansible-relayor
T
On Thu, May 23, 2019 at 2:09 PM teor teor@riseup.net wrote:
On 23 May 2019, at 18:41, Dmitrii Tcvetkov demfloro@demfloro.ru wrote:
On Tue, 21 May 2019 23:36:28 -0700 Keifer Bly keifer.bly@gmail.com wrote:
Hi, so the relay in question does indeed have a reserved Static IP (104.154.93.253), and the traffic is allowed by the firewall, but the relay is still not appearing in the consensus. The port it's running on is 65534. This is starting to seem odd.....any thoughts are appreciated. Thanks. --Keifer
Indeed, I don't have any problem connecting to your relay with openssl from multiple locations (at least Russia, Netherlands and Germany):
$ openssl s_client -connect 104.154.93.253:65534
<snip> Certificate chain ...
I can't find a relay called "torworld" or at "104.154.93.253" on the tor network:
- using consensus health, which shows relays with votes: https://consensus-health.torproject.org/
- or relay search, which shows relays in the consensus: https://metrics.torproject.org/rs.html#search/104.154.93.253
Please copy and paste the latest logs from your relay the last time you started it up. We need to see logs that cover your relay's:
- tor version,
- role (relay or bridge),
- nickname,
- fingerprint,
- IPv4 address,
- reachability self-test, and
- descriptor posts to authorities.
We might need info-level logs to see some of these things.
Do you know if Google supports tor relays? They could be blocking some connections.
T
Hi all, so I believe I found the problem. In my torrc file, there was a rogue line which read "PublishServerDescriptor" with nothing after it. I removed this line and restarted the relay, now it is saying "May 24 01:38:16.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. May 24 01:38:20.000 [notice] Performing bandwidth self-test...done."
So it seems this solved the problem. Now, I am also wondering, is there a tool that can be used to automatically update tor? Thank you.
--Keifer
On Thu, May 23, 2019 at 6:16 PM teor teor@riseup.net wrote:
Hi,
On 24 May 2019, at 09:19, Keifer Bly keifer.bly@gmail.com wrote:
Hi all, so this is the tor log since the last restart. It includes the
relay fingerprint. The tor version is (0.2.9.16-1).
The log you posted is missing a few lines at the start, including the lines that tell us the tor version.
We need to see the tor version that is *running*, not the tor version that you installed. Just in case they are different. (Authorities reject really old Tor versions.)
When I tried updating tor I got a message saying that was the newest version.
It looks like you're on Debian or Ubuntu, please follow these instructions to update: https://2019.www.torproject.org/docs/debian.html.en
The relay has an assigned static ip and port which are both allowed by
the firewall. It seems strange that
Dmitrii Tcvetkov was able to reach the relay though teor cannot,
We looked in different places:
Dmitrii connected to the IP and ports of your relay using SSL. I looked for your relay in the votes and the consensus, but I did not find it.
also that the relay says it is reachable and receiving traffic but not
appearing in the relay list.
I think your relay is not publishing its descriptor. See my comments below about the relay log.
It seems like the relay would not be able to start at all if Google was blocking it.
There are lots of different ways to block relays. Some let the relay start, but it never gets in the consensus. But I don't think that has happened to your relay.
May 21 20:01:32.000 [warn] You are running Tor as root. You don't need
to, and you probably shouldn't.
I don't know how you are configuring and running your relay. Using a guided relay configuration tool might help you. See my suggestion below.
May 21 20:01:33.000 [notice] Your Tor server's identity key fingerprint
is 'torworld 3A4E582092E7C6B822EC01F4D76F680F6C65B0A2'
I have confirmed that this fingerprint is not in the votes or consensus.
May 21 20:01:33.000 [notice] Bootstrapped 0%: Starting May 21 20:03:53.000 [notice] Bootstrapped 80%: Connecting to the Tor
network
May 21 20:03:54.000 [notice] Guessed our IP address as 104.154.93.253
(source: 128.31.0.34).
128.31.0.34 is the IP address of moria1, so your relay can connect to the directory authorities. That means that Google isn't blocking connections out.
May 21 20:03:58.000 [notice] Bootstrapped 100%: Done May 21 20:03:58.000 [notice] Now checking whether ORPort
104.154.93.253:65534 is reachable... (this may take up to 20 minutes -- lookfor log messages indicating success)
May 21 20:04:01.000 [notice] Self-testing indicates your ORPort is
reachable from the outside. Excellent.
Your relay and Dmitrii have confirmed that this port is reachable from the outside.
But your relay log does not say "Publishing server descriptor." That's why your relay is not in the votes or the consensus.
So we need to answer these questions:
- Is your relay configured as a bridge?
- Is your relay configured to *not* publish its descriptor? (Relays publish their descriptors by default.)
Please copy and paste your torrc into your next email.
Your logs were also missing these things:
- tor version,
- role (relay or bridge), and
- descriptor posts to authorities.
Please post the parts of your logs that contain this information. There is no need to paste more than 2 repetitions of the Heartbeat/Cell/Circuit/Connection/DoS lines.
You seem to have a lot of trouble configuring relays manually. You might have a better experience with a guided setup tool, like this Tor Relay role in Ansible: https://github.com/nusenu/ansible-relayor
T
On Thu, May 23, 2019 at 2:09 PM teor teor@riseup.net wrote:
On 23 May 2019, at 18:41, Dmitrii Tcvetkov demfloro@demfloro.ru wrote:
On Tue, 21 May 2019 23:36:28 -0700 Keifer Bly keifer.bly@gmail.com wrote:
Hi, so the relay in question does indeed have a reserved Static IP (104.154.93.253), and the traffic is allowed by the firewall, but the relay is still not appearing in the consensus. The port it's running on is 65534. This is starting to seem odd.....any thoughts are appreciated. Thanks. --Keifer
Indeed, I don't have any problem connecting to your relay with openssl from multiple locations (at least Russia, Netherlands and Germany):
$ openssl s_client -connect 104.154.93.253:65534
<snip> Certificate chain ...
I can't find a relay called "torworld" or at "104.154.93.253" on the tor
network:
- using consensus health, which shows relays with votes: https://consensus-health.torproject.org/
- or relay search, which shows relays in the consensus: https://metrics.torproject.org/rs.html#search/104.154.93.253
Please copy and paste the latest logs from your relay the last time you
started
it up. We need to see logs that cover your relay's:
- tor version,
- role (relay or bridge),
- nickname,
- fingerprint,
- IPv4 address,
- reachability self-test, and
- descriptor posts to authorities.
We might need info-level logs to see some of these things.
Do you know if Google supports tor relays? They could be blocking some connections.
T
Hi,
On 24 May 2019, at 11:41, Keifer Bly keifer.bly@gmail.com wrote:
Hi all, so I believe I found the problem. In my torrc file, there was a rogue line which read "PublishServerDescriptor" with nothing after it. I removed this line and restarted the relay, now it is saying "May 24 01:38:16.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. May 24 01:38:20.000 [notice] Performing bandwidth self-test...done."
So it seems this solved the problem.
It looks like your relay changed keys about 2 hours ago: https://metrics.torproject.org/rs.html#search/torworld
If you keep changing your relay keys, it won't be used very much.
Now, I am also wondering, is there a tool that can be used to automatically update tor? Thank you.
Yes!
From my last email:
When I tried updating tor I got a message saying that was the newest version.
It looks like you're on Debian or Ubuntu, please follow these instructions to update: https://2019.www.torproject.org/docs/debian.html.en
May 21 20:01:32.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't.
I don't know how you are configuring and running your relay. Using a guided relay configuration tool might help you. See my suggestion below.
You seem to have a lot of trouble configuring relays manually. You might have a better experience with a guided setup tool, like this Tor Relay role in Ansible: https://github.com/nusenu/ansible-relayor
I really think that something like ansible is your best chance of having a working relay.
T
Hi,
I apologize for top posting, but it’ll be the simplest way to convey the message.
In April 2018 Google released an update that caused VPNs and Tor services to stop working on GCE and App Engine. It was a long planned network update.
The following ticket refers: https://trac.torproject.org/projects/tor/ticket/25804
Thanks,
Conrad
On May 23, 2019, at 8:15 PM, teor teor@riseup.net wrote:
Hi,
On 24 May 2019, at 09:19, Keifer Bly keifer.bly@gmail.com wrote:
Hi all, so this is the tor log since the last restart. It includes the relay fingerprint. The tor version is (0.2.9.16-1).
The log you posted is missing a few lines at the start, including the lines that tell us the tor version.
We need to see the tor version that is *running*, not the tor version that you installed. Just in case they are different. (Authorities reject really old Tor versions.)
When I tried updating tor I got a message saying that was the newest version.
It looks like you're on Debian or Ubuntu, please follow these instructions to update: https://2019.www.torproject.org/docs/debian.html.en
The relay has an assigned static ip and port which are both allowed by the firewall. It seems strange that Dmitrii Tcvetkov was able to reach the relay though teor cannot,
We looked in different places:
Dmitrii connected to the IP and ports of your relay using SSL. I looked for your relay in the votes and the consensus, but I did not find it.
also that the relay says it is reachable and receiving traffic but not appearing in the relay list.
I think your relay is not publishing its descriptor. See my comments below about the relay log.
It seems like the relay would not be able to start at all if Google was blocking it.
There are lots of different ways to block relays. Some let the relay start, but it never gets in the consensus. But I don't think that has happened to your relay.
May 21 20:01:32.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't.
I don't know how you are configuring and running your relay. Using a guided relay configuration tool might help you. See my suggestion below.
May 21 20:01:33.000 [notice] Your Tor server's identity key fingerprint is 'torworld 3A4E582092E7C6B822EC01F4D76F680F6C65B0A2'
I have confirmed that this fingerprint is not in the votes or consensus.
May 21 20:01:33.000 [notice] Bootstrapped 0%: Starting May 21 20:03:53.000 [notice] Bootstrapped 80%: Connecting to the Tor network May 21 20:03:54.000 [notice] Guessed our IP address as 104.154.93.253 (source: 128.31.0.34).
128.31.0.34 is the IP address of moria1, so your relay can connect to the directory authorities. That means that Google isn't blocking connections out.
May 21 20:03:58.000 [notice] Bootstrapped 100%: Done May 21 20:03:58.000 [notice] Now checking whether ORPort 104.154.93.253:65534 is reachable... (this may take up to 20 minutes -- lookfor log messages indicating success) May 21 20:04:01.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent.
Your relay and Dmitrii have confirmed that this port is reachable from the outside.
But your relay log does not say "Publishing server descriptor." That's why your relay is not in the votes or the consensus.
So we need to answer these questions:
- Is your relay configured as a bridge?
- Is your relay configured to *not* publish its descriptor?
(Relays publish their descriptors by default.)
Please copy and paste your torrc into your next email.
Your logs were also missing these things:
- tor version,
- role (relay or bridge), and
- descriptor posts to authorities.
Please post the parts of your logs that contain this information. There is no need to paste more than 2 repetitions of the Heartbeat/Cell/Circuit/Connection/DoS lines.
You seem to have a lot of trouble configuring relays manually. You might have a better experience with a guided setup tool, like this Tor Relay role in Ansible: https://github.com/nusenu/ansible-relayor
T
On Thu, May 23, 2019 at 2:09 PM teor teor@riseup.net wrote:
On 23 May 2019, at 18:41, Dmitrii Tcvetkov demfloro@demfloro.ru wrote:
On Tue, 21 May 2019 23:36:28 -0700 Keifer Bly keifer.bly@gmail.com wrote:
Hi, so the relay in question does indeed have a reserved Static IP (104.154.93.253), and the traffic is allowed by the firewall, but the relay is still not appearing in the consensus. The port it's running on is 65534. This is starting to seem odd.....any thoughts are appreciated. Thanks. --Keifer
Indeed, I don't have any problem connecting to your relay with openssl from multiple locations (at least Russia, Netherlands and Germany):
$ openssl s_client -connect 104.154.93.253:65534
<snip> Certificate chain ...
I can't find a relay called "torworld" or at "104.154.93.253" on the tor network:
- using consensus health, which shows relays with votes:
https://consensus-health.torproject.org/
- or relay search, which shows relays in the consensus:
https://metrics.torproject.org/rs.html#search/104.154.93.253
Please copy and paste the latest logs from your relay the last time you started it up. We need to see logs that cover your relay's:
- tor version,
- role (relay or bridge),
- nickname,
- fingerprint,
- IPv4 address,
- reachability self-test, and
- descriptor posts to authorities.
We might need info-level logs to see some of these things.
Do you know if Google supports tor relays? They could be blocking some connections.
T
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi,
On 24 May 2019, at 14:08, Conrad Rockenhaus conrad@rockenhaus.com wrote:
In April 2018 Google released an update that caused VPNs and Tor services to stop working on GCE and App Engine. It was a long planned network update.
The following ticket refers: https://trac.torproject.org/projects/tor/ticket/25804
That ticket is about domain-fronting, which is used by meek and snowflake bridges. But these issues do not affect other relays.
Do you have any information about Google blocking relays?
T
Hello,
My bust, confirmation bias.
Thanks,
Conrad
On Thu, May 23, 2019 at 11:45 PM teor teor@riseup.net wrote:
Hi,
On 24 May 2019, at 14:08, Conrad Rockenhaus conrad@rockenhaus.com
wrote:
In April 2018 Google released an update that caused VPNs and Tor
services to stop working on GCE and App Engine. It was a long planned network update.
The following ticket refers:
https://trac.torproject.org/projects/tor/ticket/25804
That ticket is about domain-fronting, which is used by meek and snowflake bridges. But these issues do not affect other relays.
Do you have any information about Google blocking relays?
T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi, so I am now auto upgrading tor using the method at https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/DebianUbuntuUpda...
Upon testing, this is what I got.
Initial blacklisted packages: Initial whitelisted packages: Starting unattended upgrades script Allowed origins are: [] Checking: firefox-esr ([<Origin component:'main' archive:'stable' origin:'Debian' label:'Debian-Security' site:'security.debian.org' isTrusted:True>]) Checking: google-cloud-sdk ([<Origin component:'main' archive:'cloud-sdk-stretch' origin:'cloud-sdk-stretch' label:'cloud-sdk-stretch' site:'packages.cloud.google.com' isTrusted:True>]) Checking: google-compute-engine ([<Origin component:'main' archive:'google-compute-engine-stretch-stable' origin:'google-compute-engine-stretch-stable' label:'google-compute-engine-stretch-stable' site:'packages.cloud.google.com' isTrusted:True>]) Checking: google-compute-engine-oslogin ([<Origin component:'main' archive:'google-compute-engine-stretch-stable' origin:'google-compute-engine-stretch-stable' label:'google-compute-engine-stretch-stable' site:'packages.cloud.google.com' isTrusted:True>]) Checking: libavcodec57 ([<Origin component:'main' archive:'stable' origin:'Debian' label:'Debian-Security' site:'security.debian.org' isTrusted:True>]) Checking: libavfilter6 ([<Origin component:'main' archive:'stable' origin:'Debian' label:'Debian-Security' site:'security.debian.org' isTrusted:True>]) Checking: libavformat57 ([<Origin component:'main' archive:'stable' origin:'Debian' label:'Debian-Security' site:'security.debian.org' isTrusted:True>]) Checking: libavresample3 ([<Origin component:'main' archive:'stable' origin:'Debian' label:'Debian-Security' site:'security.debian.org' isTrusted:True>]) Checking: libavutil55 ([<Origin component:'main' archive:'stable' origin:'Debian' label:'Debian-Security' site:'security.debian.org' isTrusted:True>]) Checking: libpostproc54 ([<Origin component:'main' archive:'stable' origin:'Debian' label:'Debian-Security' site:'security.debian.org' isTrusted:True>]) Checking: libswresample2 ([<Origin component:'main' archive:'stable' origin:'Debian' label:'Debian-Security' site:'security.debian.org' isTrusted:True>]) Checking: libswscale4 ([<Origin component:'main' archive:'stable' origin:'Debian' label:'Debian-Security' site:'security.debian.org' isTrusted:True>]) Checking: python-google-compute-engine ([<Origin component:'main' archive:'google-compute-engine-stretch-stable' origin:'google-compute-engine-stretch-stable' label:'google-compute-engine-stretch-stable' site:'packages.cloud.google.com' isTrusted:True>]) Checking: python3-google-compute-engine ([<Origin component:'main' archive:'google-compute-engine-stretch-stable' origin:'google-compute-engine-stretch-stable' label:'google-compute-engine-stretch-stable' site:'packages.cloud.google.com' isTrusted:True>]) pkgs that look like they should be upgraded: Fetched 0 B in 0s (0 B/s)
fetch.run() result: 0 blacklist: [] whitelist: [] No packages found that can be upgraded unattended and no pending auto-removals
What I am attempting to do is automatically install new tor versions when they are released. Will this do that automatically? How can I keep this process running? Thanks.
--Keifer
On Fri, May 24, 2019 at 12:38 AM Conrad Rockenhaus conrad@rockenhaus.com wrote:
Hello,
My bust, confirmation bias.
Thanks,
Conrad
On Thu, May 23, 2019 at 11:45 PM teor teor@riseup.net wrote:
Hi,
On 24 May 2019, at 14:08, Conrad Rockenhaus conrad@rockenhaus.com
wrote:
In April 2018 Google released an update that caused VPNs and Tor
services to stop working on GCE and App Engine. It was a long planned network update.
The following ticket refers:
https://trac.torproject.org/projects/tor/ticket/25804
That ticket is about domain-fronting, which is used by meek and snowflake bridges. But these issues do not affect other relays.
Do you have any information about Google blocking relays?
T _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- Conrad Rockenhaus https://www.rockenhaus.com Cell: (254) 292-3350 Fax: (254) 875-0459 _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
Conrad Rockenhaus -
Dmitrii Tcvetkov -
Keifer Bly -
teor