It's not clear what you're asking. What "information" exactly. Etc. Please put each question in one paragraph or line dedicated to that question.

If reaching the DA's is the only blockage, you should be able to setup your host's routing table and packet filters to send the DA's ip traffic to them over bridge or vpn. Probably no one has really tested that yet. And there may surely be other issues to investigate.

On Fri, Nov 23, 2018 at 01:30:12PM -0600, Gunnar Wolf wrote:

I am working together with some other people to increase the number of relays in Mexico. We have finally started to increase the number - from our usual two active relays to four, still WAY too low, but it's a beginning:

https://metrics.torproject.org/rs.html#search/country:mx

Cool!

But there are some issues / questions bugging me:

When we set out to pursue this, we faced the reality that most Mexican ISPs block Tor relays in some way or another: The main ISP in the country (Telmex / Infinitum / Uninet, depending on the business branch in question) blocks all communication to seven of the dirauths, thereby making it impossible to operate a relay

Ok. There are two pieces to how this could be a problem. The first piece is that when the relay tries to publish its descriptor, it can't reach the directory authorities, so they never learn that it exists. For this side, even being able tor each one of them would technically be enough, because that one will get the word to the rest of them.

The second piece is that the directory authorities need to be able to reach the relay, to decide that it's Running. So if the blocking goes both ways, and a majority of the dir auths can't reach the relay, it won't get the Running flag in the consensus.

(although bridges do work); many other ISPs employ a set of nested NAT systems, making it impossible for external computers to reach a server inside it...

However, we have at least one relay claiming to be from Uninet (5F6E720D7F0A95D6276B6F6DF8C210735A331B9D - Not currently online, but made it to the consensus at least at several points over the past months).

It's online as I write this. I can reach it from moria1.

https://metrics.torproject.org/rs.html#details/5F6E720D7F0A95D6276B6F6DF8C21...

$ host 189.144.191.183 183.191.144.189.in-addr.arpa domain name pointer dsl-189-144-191-183-dyn.prod-infinitum.com.mx.

(I don't know enough about the Mexico ISP world to know if prod-infinitum is the same as Uninet.)

We also have some in an ISP that gives addresses behind multiple layers of NAT and are unworkable (FF3FF664B0811B2E3C237BECA4382966AD9E393C, 6E483A91105C647A65ED04E1CB637AAD84F5943F)

Those are indeed publishing to moria1, but they're not currently reachable (probably because they're not currently up). They look like they're at DSL providers. Have any of them actually been marked Running?

Btw, all of these UbuntuCore relays are from snap packages run by Tor enthusiasts -- but in general the UbuntuCore Tor relays aren't stable or around for a long time, since people who want to run a real Tor relay tend to use the more traditional Tor packages.

So... Is this information right? Can this be in some way spoofed? How should I interpret this?

I haven't seen anything weird yet. There's a relay, it's running; there are some other relays that aren't currently online and may not ever have been reachable or may have figured out some sort of port forwarding / firewall piercing trick to be reachable.

(Relays try not to publish their descriptor until their self-reachability test works, so it seems likely that at some point in the past they managed to get a connection to their IP:ORPort to work. That or the UbuntuCore snap package does something weird like setting AssumeReachable to 1.)

--Roger