Use MagicDNS and test the path

MagicDNS gives every tailnet device a private DNS name. New tailnets have it enabled by default, so your server already has one.

A short hostname such as lab-server is much easier to use than 100.101.9.23. The full name includes your tailnet domain, something like lab-server.tail4a5b6.ts.net, but inside the tailnet the short form resolves too.

Test the name

Start with a plain connection by name:

ssh ubuntu@lab-server

If SSH connects, the name resolved to the Tailscale address and the private path works. From now on, use names in every config file you write. Names survive device replacement, and they make policies and logs readable. An IP tells you nothing at 2am. lab-server does.

Test the path, not just reachability

Ordinary ping tells you the IP is reachable. It does not tell you how the packets got there. tailscale ping does:

tailscale ping lab-server

pong from lab-server (100.101.9.23) via 203.0.113.40:41641 in 14ms

via <ip>:<port> means a direct connection. If you see via DERP(fra) instead, traffic is going through Tailscale’s Frankfurt relay. Still encrypted, still working, just not direct. The first ping often goes through DERP while the direct path is being negotiated. Run it again and watch it switch.

Prove the old path was not used

Connecting by name is not proof that you used the tailnet. Maybe the name resolved to something else. Ask the server which addresses the connection came from:

ssh ubuntu@lab-server 'echo $SSH_CONNECTION'

100.87.12.44 52441 100.101.9.23 22

The four values are client address, client port, server address, server port. Both addresses start with 100., so both are tailnet addresses. The connection entered through the Tailscale interface, not the public one. Now you have proof, not a guess.

When the name fails

If name resolution fails, check two things: MagicDNS is enabled on the DNS page of the admin console, and the client accepts DNS settings. When tailscale ping 100.101.9.23 works but tailscale ping lab-server does not, the problem is DNS, not connectivity. That distinction saves you from debugging the wrong layer, and it comes back in the troubleshooting lesson.