Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #21044

Closed (moved)
Open
Opened Dec 20, 2016 by s7r@s7r🏁

ORPort self reachability test happens also when it shouldn't

I think we did not cover all cases when the self reachability test before publishing descriptors was introduced.

I am running a bridge with PublishServerDescriptor 0 and ORPort 127.0.0.1:443 because I want to run it just to do some responsible testing without hammering the public Guards used by other clients. The bridge is configured with PublishServerDescriptor 0 so it means I don't need a descriptor, I don't intend to make the bridge (or relay) public.

When a bridge is run in the conditions described above the log is spammed (exactly one log message at every 20 minutes) with:

[warn] Your server (PUBLIC_IP:443) has not managed to confirm that its ORPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

and

[warn] The IPv4 ORPort address 127.0.0.1 does not match the descriptor address PUBLIC_IP. If you have a static public IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'.

What it did wrong:

  • It guessed the public IP address and tried to make the self test on that address, regardless it's not the address explicitly configured at ORPort. Address is not set in this setup.

  • Based on the second log message, I think it even overwritten the address used with ORPort with the public IP address that it guessed and built the descriptor.

  • It infinitely tries once every 20 minutes and logs a message that the descriptor cannot be published (and my intention based on the options configured is exactly not to publish one even if the tests were successful).

What Tor should do:

  • Bypass the protocol to guess Address (the public IP address) when ORPort / DirPort is explicitly configured as a loopback address or NAT address. This will have a logic follow-up (which I think we already do, but want to make sure) like this:

  • Bypass self tests when ORPort / DirPort address is explicitly configured as a loopback address or NAT address (simplest thing would be to treat these cases as like AssumeReachable 1 is set). Such addresses cannot be tested from the public internet anyway.

  • PublishServerDescriptor 0 maybe should not even build a descriptor at all, or at least bypass the self tests in this case too, it does not make sense to try to test something we never want to publish. Or, only make 1 attempt to test and log a message stating success or failure.

#19919 (moved) is kind of related, it treats as it should the cases where ORPort is explicitly configured as a public address. In this ticket we cover an extension for cases where ORPort is a loopback or NAT address.

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#21044