[tor-relays] [SOLVED] published descriptor missing from consensus

[teor]

> On 9 Jun 2017, at 08:30, Scott Bennett <bennett at sdf.org> wrote:
> 
> Roman Mamedov <rm at romanrm.net> wrote:
> 
>> On Thu, 08 Jun 2017 09:43:00 -0500
>> Scott Bennett <bennett at sdf.org> wrote:
>> 
>>>     As noted more than once previously, the pf rules *pass* all traffic
>>> from relay addresses *first*, so that traffic has already gone on to tor
>>> before the block list is applied.
>> 
>> There are most likely some relays which use a different IP for outgoing
>> connections than what is listed in the consensus, due to multiple IPs or
>> provider multihoming. Your scheme does not seem to account for that, so those
>> connections may fail. In effect you will be leaving the Tor network
>> permanently semi-broken by running a relay while employing such filtering.

This also excludes any direct client connections to your relay. For an Exit,
clients should only connect if UseEntryGuards is 0 (the default is 1, except
for Tor2Web and Single Onion Service clients).

It also excludes connections from relays that come up and down frequently.

>     You're right.  I recall spending a lot of time trying to find a way to
> get those addresses, so that I could include them in the TorRelays table or
> some other arrangement to let their traffic through.  Unfortunately, tor
> doesn't publish them anywhere that I could find nor did anything else back
> at the time I set these rules and tables up.  However, I figured most relays
> probably have only a single WAN interface, so the rules would probably cause
> few failures.

My relays have multiple IP addresses on a single WAN interface. They all use
OutboundBindAddress to separate OR and Dir traffic from outbound traffic. And
they make up about 1% of Tor guard/middle bandwidth.

I think you will find this is not an uncommon configuration among
high-bandwidth relays.

Some directory authorities also have multiple IP addresses.

> Also, clients don't give up after something like that, but
> rather continue to try more circuits, so the end user may experience a short
> delay, but won't actually go unserved in such cases.

What actually happens depends on a number of factors:
* whether the other relay has successfully connected to your relay,
* whether both relays think the connection is canonical,
* whether either relay has a large exponential backoff on retries.

So in some cases, clients will be unable to connect to your exit via some
middle relays. This reduces your exit traffic, and also reduces the number of
different circuit paths available to clients. (Using a wide variety of paths
is one of the building blocks of Tor's anonymity.)

My point is that there are a lot of moving parts here.
And there could be multiple contributing factors, not just OpenSSL.

For the record, we generally suggest the following firewall
configuration:
* allow incoming connections to your ORPort and DirPort from any IP
* allow all outgoing connections.

But we might have to agree to disagree here.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20170609/41e3c7fc/attachment.sig>