Skip to content

Implement a mechanism for PT reachability testing

Non-vanilla bridges currently have no way to automatically test their reachability. Vanilla bridges self-test the reachability of their ORPort by creating a circuit that includes themselves, but we cannot do this for, say, obfs4. In practice, this is problematic because obfs4 operators won't know if their bridge is unreachable; for example due to NAT. In fact, BridgeDB is distributing obfs4 bridges that aren't actually reachable.

We need to build a mechanism that allows non-vanilla bridges to test their reachability. Ideally, something would create a circuit over the bridge while speaking its respective transport protocol but even a simple TCP or UDP-based reachability test would already go a long way.

Looking at the discussion over in #30331, tor seems to be the right component to trigger the reachability test. In its log files, it can then yell at the operator if the test failed. The question is: how should we design the mechanism that implements the reachability test?

One solution would be a simple HTTP API that takes as input an address, port, a transport type, and optional parameters, and then tells you if the given bridge is reachable, e.g.: the URL https://pt-reachable.torproject.org/obfs4/1.2.3.4/9002 may respond with something along the lines of obfs4_reachable: true. Ideally, if the reachability test fails, we should provide details, to help the operator figure out what went wrong.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information