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

[Scott Bennett]

teor <teor2345 at gmail.com> wrote:

>
> > 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 only excludes client connections from IP addresses with a history
of offending behavior against my system.  That exclusion is an express aim
of the packet filter rules I posted.  By excluding their access to anything
on my system, I keep them from causing me further trouble.  Unfortunately,
if such troublemaking IP addresses also happen to host relays, then I have
to let them have access to the ORPort and DirPort, but I can still exclude
them from everything else.  Bad behavior should be expected to have
consequences.
     Clients at non-offending IP addresses are allowed to connect without
interference.
>
> It also excludes connections from relays that come up and down frequently.

     Well, laying aside the fact that we don't want them to be up and down
frequently, my TorRelays table is regenerated every 15 minutes from the
most recently retrieved consensus.  Consensuses are rarely fetched more than
once during the same hour, but even if they are and regardless of the time
during the clock hour the consensus is retrieved, only a few minutes will
pass before the table is produced fresh and loaded into pf.  That is much
faster than a new consensus is propagated to all relays or clients anyway.
>
> >     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.

     So, although the traffic is not separated on that machine, you use the
source addresses to allow a router to separate the traffic as it leaves your
network?  Or is it indeed separated on that machine via routing table entries?
>
> I think you will find this is not an uncommon configuration among
> high-bandwidth relays.

     I will check further into the procedure for which Roger posted a URL
to see whether it will indeed give me a list of such addresses that I can
use.  If so, I will certainly begin running it, scraping the addresses,
and merging them with the addresses already going into table creation.
>
> Some directory authorities also have multiple IP addresses.

     See above.
>
> > 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

     Although I allow exits to a small list of places, my relay does not
allow general exiting in a manner that would qualify it for an Exit flag
on its entry in the consensus, so in that sense, there is no exit here.

> 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 daily exit traffic is ordinarily zero.  Non-zero days are so rare as
not to be worth calculating their frequency.  I no longer remember the last
time I saw one, but many versions of tor have come and gone since then.
>
> 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.

     Exactly.  I block outbound connections to known (to me) malware sites
(currently just three entries), but otherwise everything outbound is
basically just passed on through.  Inbound connections are subject to the
rules previously outlined.
     If I can get my hands on the extra relay addresses, that will be great.
I'd love to have them included in the TorRelays table.  Like I wrote before,
I did try to find them long ago in order to do just that, so it will be good
to have them at last.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************