Capstone — Triaging Three Real Connectivity Tickets

One user, not many — everywhere, not one destination — total failure, not degraded — and it has never worked, since this is the machine's first connection. That combination points squarely at something local to this one machine, before DNS or any specific server is even worth testing.

A textbook link-local address with no gateway — DHCP never succeeded on this machine at all. A loose network cable, reseated, immediately resolves it; a fresh ipconfig /all shows a real address and gateway, and a ping to the gateway confirms it.

Many users, one destination, just started — since the new Wi-Fi went live this week. That specific combination (one app, one network, everyone affected) points toward something scoped by network and by destination — a strong early hint toward a firewall rule rather than DNS or the app itself.

From the new Wi-Fi network, DNS resolves the reporting app's name correctly, and a ping to its host succeeds cleanly. Both rungs check out — the problem sits higher up the ladder.

Same destination, same port, two different networks, two different results — exactly the pattern Chapter 7 flagged as pointing at a boundary rule. Handing off the wired subnet, the new Wi-Fi subnet, the destination, and the port to the network team confirms it directly: the reporting app's security-group rule was scoped to the old wired subnet during the original rollout, and was simply never updated to include the new Wi-Fi range when it launched — an oversight, not an intentional restriction this time.

The first instinct is to assume this is Chapter 8's own certificate-trust issue again — a script failing where a browser succeeds. Checking the actual failure rules that out immediately: curl -v shows the TLS handshake completing cleanly every time, and the failure itself is a genuine 504 Gateway Timeout — a real HTTP response, which per Chapter 9 already proves DNS, network reachability, the port, and TLS all worked on that specific attempt. This is a different problem wearing a familiar disguise.

Run from the batch server that actually executes the script — not from the colleague's own workstation — a traceroute to the partner API shows something the interactive browser test never would have surfaced:

The batch server's own traffic takes a genuinely different path than an ordinary workstation's — routed through a secondary, backup VPN tunnel reserved for server infrastructure, with real, measurable latency and packet loss under load. That path occasionally exceeds the partner API's own gateway timeout window, exactly as Chapter 9's 504 definition describes — not because the script or the API is broken, but because of where the traffic is actually routed from, per Chapter 8's own "the path isn't always what you'd expect" theme.