[tor-relays] Tor relay says it is reachable, but is not appearing on the network.

Fri May 24 04:08:37 UTC 2019

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 at riseup.net> wrote:
> 
> Hi,
> 
>> On 24 May 2019, at 09:19, Keifer Bly <keifer.bly at 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 at riseup.net> wrote:
>> 
>> On 23 May 2019, at 18:41, Dmitrii Tcvetkov <demfloro at demfloro.ru> wrote:
>> 
>>> On Tue, 21 May 2019 23:36:28 -0700
>>> Keifer Bly <keifer.bly at 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1403 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20190523/a424def0/attachment.bin>