A plea for help with dysfunctional bridge

Support Relay Operator
1

Trying to get a bridge back online after my external IP was changed by my service provider.
The bridge ran successfully and carried traffic for 60 days or so. The ISP changed my external IP while I was out of town and I wasn’t able to repair the bridge till I got home, so it was running in a non-sensical state for 4 or 5 days.
In order to prevent this problem in the future I registered with a ddns service and changed my torrc file to use the newly registered domain name rather than a hardcoded ip. The next time my ip changes, a monitor I’m running will detect the change, update the ddns entry on the external service, and then restart the bridge.
But in the meantime, after I restarted the bridge with the updated torrc file, the bridge appears to be in limbo (or perhaps purgatory). Logs from the bridge appear normal: it starts up, reports success on verifying reach-ability, etc. When I use nyx to examine it I often see many established circuits (mostly hs_vanguards and conflux), with an occasional general purpose circuit.
But reported traffic (i.e. bytes written and read) increase only a very small amount from day to day, so the bridge is carrying very little traffic.
And the Tor external tools that report on bridges tell a mixed story.
The TCP Reachability page always reports the bridge is reachable.
But, the Relay Search page almost always reports the bridge as down, and it shows no bytes transferred in or out over the past many days, and no reported users.
And, the bridges.torproject.status page always reports the bridge as “dysfunctional.”

The bridge’s hashed fingerprint is 744DA6E2E2BCB93999C8B16C1C185BA06DFFA447
The bridges/status page is here: https://bridges.torproject.org/status?id=744DA6E2E2BCB93999C8B16C1C185BA06DFFA447
Tor Metrics Relay Search page: Relay Search

Is there someone who can look at this bridge from the “system” side as opposed to my bridge-side view? It feels like the network-side of things doesn’t believe this bridge is operational, whereas the bridge itself clearly does. I hate to abandon this bridge and start over with a new one, but I’m at a loss about how to proceed.

Thanks for any help–

2

Did you try to connect to your bridge with torbrowser? (client)

Did it connect with no problems?

If you send me the bridge line per DM, I’d be happy to test as well.

3

After some assistance from lars-skuggi I’ve got this bridge operational again. I thought I’d summarize what took the bridge offline, how I solved that issue, what prevented the bridge from coming back online successfully until lars-skuggi stepped in and helped me escape the tunnel-vision I was stuck in.

The bridge is in an environment where the external ip that it sits behind can change arbitrarily and without warning. When I first setup the bridge I imagined this might not even happen and I didn’t take any steps to mitigate it, so when it did happen (ISP assigned a new ip) I wasn’t in a position to respond for a few days, so the bridge sat in a mode where it advertised itself as being at an ip it was no longer at.

When I was able to work on it, I explored options. I wanted a solution that would deal with exactly what happened—the external IP the bridge sits behind gets changed, and I’m not in a position where I can deal with it for days or weeks, and I want the bridge and related services to self-heal without intervention from me.

The working solution looks like this:

  1. Register with a free dynamic dns service, e.g. DuckDNS.org. Create a domain name to your liking, and set the ip field to your current external ip
  2. edit your torrc file, and in place of the external ip, enter the domain name you created in step 1. Restart tor and verify your domain name is resolving correctly.
  3. Use a monitoring service to keep an eye on your external ip. If the ip changes:
    1. Update the ddns service with your new ip. These services offer restful api’s so that you can update your existing domain name with the new ip via http PUSH.
    2. After you’ve updated the ddns service, send tor a HUP (or use whatever is appropriate on your bridge host) to restart tor. It will re-read torrc, find your existing domain name, resolve it (and thereby receive your newly assigned ip) and come up happily.

This solution all works. (One very useful tool I discovered and made use of is Uptime Kuma, a self-hosted monitoring service. You can train it to do the external IP monitoring, and trigger scripts or whatever mechanism you want to push the new IP out to the ddns service, and to trigger the tor restart.)

After I got all that working, the problem that caused my bridge to remain dysfunctional for multiple days was caused by misconfiguration on my part. When the external ip got changed by the ISP, the router/modem also got reset, and port-forwarding rules got erased. When i recreated those port-forwarding rules, I did it incorrectly. (I had forgotten that it’s not enough to expose the ORPort; since I’m running obfs4 I also have to expose the port the transport is listening on.) Once I started staring at tor logs, and everything looked very close to working, I kept insisting that something must be wrong either in my torrc or something was stale in the network related to my bridge. That was the tunnel-vision I developed, and wasn’t able to see past till I finally got someone else involved who asked pretty basic questions like “can you configure a tor browser to successfully use your bridge???”.

I apologize for the length of this post; hopefully someone else finds it useful or instructive.

Thanks again to lars-skuggi for being willing to spend time looking at this with me.