Notifications
Clear all
Topic starter
02/08/2026 12:11 pm
TL;DR: Blacksmith describes a transparent proxy that reroutes GitHub traffic through Tailscale Services and Squid when ISP degradation stalls CI jobs, with no customer code changes and traffic limited to GitHub endpoints. The architecture shows how routing resilience, authenticated service access, and least-privilege network paths increasingly intersect in modern platform operations.
NHIMG editorial — based on content published by Tailscale: How Blacksmith used Tailscale Services to work around ISP degradation
By the numbers:
- The problem took 16 hours to isolate to the problematic ISP.
Questions worth separating out
Q: How should teams design failover for critical developer services?
A: Design failover around the smallest reachable scope that restores service, not around full-network redundancy.
Q: Why does authenticated service reachability matter in resilience design?
A: Because an alternate path that is open to everyone is just another exposed control surface.
Q: What breaks when failover paths are not scoped to specific services?
A: Broad failover paths create unnecessary exposure, more complex troubleshooting, and harder logging.
Practitioner guidance
- Define service-specific failover paths Document which upstream dependencies are allowed to bypass normal routing during degradation, and keep the exception list limited to critical destinations such as GitHub, package registries, or artifact stores.
- Gate fallback endpoints with identity controls Require tailnet membership, device trust, or equivalent service authentication before any proxy or alternate route can be used by automation.
- Use atomic updates for destination policy Load destination IP ranges into a single policy set and swap the set atomically so active connections are not dropped during list changes.
What's in the full article
Tailscale's full article covers the implementation detail this post intentionally leaves for the source:
- Kernel-level packet rewriting logic using iptables and SO_ORIGINAL_DST to preserve original destinations
- Squid proxy configuration and tailnet service registration commands for the GitHub failover path
- How GitHub CIDRs are loaded into ipset and atomically swapped during IP range changes
- Operational notes on why the proxy design avoids public IP exposure and separate load balancers
👉 Read Tailscale's analysis of GitHub traffic failover with Tailscale Services →
GitHub traffic failover: what it means for IAM and service access?
Explore further
02/08/2026 1:15 pm
Routing resilience is becoming an access control problem, not just an availability problem. When build systems depend on third-party services such as GitHub, the question is not only whether the network is up. It is whether critical paths remain reachable through controlled, authenticated channels when upstream routing degrades. That matters to IAM and NHI programmes because service reachability, service authentication, and workload identity are increasingly coupled. Practitioners should treat resilience paths as governed access paths, not emergency exceptions.
A question worth separating out:
Q: Which frameworks help teams govern alternate network paths and service access?
A: NIST SP 800-207 fits the zero trust side because it emphasizes continuous verification and controlled access to resources. NIST SP 800-53 Rev 5 also applies where teams need access control, system integrity, and configuration management around proxying, routing changes, and service reachability.
👉 Read our full editorial: GitHub traffic failover shows why routing resilience needs identity controls
