Tailscale Field Guide

Run on real hardware

Labs: what actually happened.

Every lab here was executed against a live tailnet of real machines across multiple providers, not sketched from documentation. The output is the output, including the runs that produced an answer nobody expected. Hostnames and addresses are genericized; the findings are not.

Read only labs versus disruptive labs read only observes, measures, proves changes nothing, safe to run on a network you did not build disruptive breaks a working path on purpose every one states its blast radius and how to put it back start read only. always.

3 published · 2 read only · 1 disruptive

  1. 01 Take a path census of your own tailnet A read only survey of every peer to find out which connections are direct and which are relayed, run on a real 47 node tailnet, which turned up a fleet wide finding the operator did not know about. run 2026-08-12 read only
  2. 02 Capture both ends at once to find out why a direct path never forms The measurement lab 01 said it needed. Two simultaneous packet captures on a permanently relayed pair, which showed both hosts transmitting probes and neither receiving any, and turned up a NAT the operator did not know was there. run 2026-08-12 read only
  3. 03 Stand up a peer relay, and find out first whether you even can The remedy for labs 01 and 02. Survey the fleet for a host that is genuinely reachable, enable relay duty on it, and discover that the last step is a policy decision with a real cost rather than a command. run 2026-08-12 disruptive