Can another company's computer reach your server? Isolation, hop by hop
The seven checks a connection passes before it reaches a SpanDock server, which ones stop a stranger or another customer, and how to try it in the lab.
Security reviewers ask a fair question about any product that connects computers across the internet: could a computer belonging to someone else, including another customer, reach our server? This guide answers it by following a connection through the seven checks it must pass, and shows which check stops each kind of outsider. You can try every scenario yourself in the reachability lab.
Prerequisites
None to read this guide. To relate it to your own setup, it helps to know how computers pair with a server: see Pairing clients and Satellites and failover.
The seven hops
A connection from a computer to a SpanDock server passes these checks in order. Each one is independent: getting past one doesn't help with the next.
1. Identity
Every computer has a node key. Anyone can generate one, so a key alone proves nothing. SpanDock derives each computer's keys from its pairing or join code, so the server knows them before the computer first connects.
2. Relay admission
Traffic between computers and servers can travel through relays. SpanDock's managed relays check with spandock.com before admitting a key: unknown keys, and keys belonging to lapsed licenses, are refused. Relays only forward encrypted packets and can't read them.
Two limits are worth knowing. Managed relays admit any key registered by an active installation on a live license, whichever server that installation is, so admission is not tied to your server. And there is a public relay used as a last resort, which doesn't check registration at all. The hops after this one still apply in both cases.
3. Tunnel address and pre-shared key
To reach a server at all, a computer needs the server's tunnel address and its pre-shared key. These travel in pairing codes and, for satellites, in the hub's server list. The secret is never logged, shown or sent to spandock.com, and moving the tunnel to a new address replaces it.
4. Peer gate
The server decides which keys may become peers of its tunnel. From v0.46, each server keeps an allowed list: only the keys of the clients and satellites it paired become peers, and any other key is ignored. New keys are added at once, and a revoked key is gone within a minute.
Servers on releases before v0.46 accept any key that knows the tunnel address and pre-shared key, so update your server to get the allowed list.
5. Encrypted tunnel
A peer gets an encrypted tunnel to the one service the server exposes on the tunnel listener, not to the server's network. Everything is encrypted end to end.
6. Client authentication
Every route on the tunnel asks for a credential: a client token, a satellite's node token, or the hub's management credential. Tokens are stored only as hashes, revoked ones stop working at once, and you can make new computers wait for approval.
7. API access
Once authenticated, a caller can use only what its credential allows. A client sees only its own records and settings. Administration needs a separate management token, and some actions are never available over the tunnel.
Which scenario stops where
The lab plays four kinds of source against a server. Here is where each one stops on a server from v0.46.
| Source | Stops at | Why |
|---|---|---|
| A stranger with no license | Relay admission (managed relays) or the tunnel secret (public relay) | Its key isn't registered; and it doesn't know the server's address and pre-shared key |
| Another customer, without your tunnel secret | Tunnel address and pre-shared key | It can't even address your server |
| Another customer holding a leaked tunnel secret | Peer gate | Its key isn't on your server's allowed list, so your server never makes it a peer |
| Your own client | Not stopped | Confirmed: it reaches the routes for its own records |
On releases before v0.46, which have no allowed list, the third case gets through the peer gate and stops at client authentication instead: it has no valid credential for your server, so every protected route refuses it.
Revoking a computer
Revoking a computer stops its credential at once, at hop 6. It doesn't erase what that computer learned: it still holds the tunnel address and pre-shared key. If that matters, for example after a laptop is lost, move the tunnel to a new address with Settings → Encrypted tunnel → New address…, which replaces the secret. Every client must then be paired again.
Verify it in the lab
- Open the reachability lab.
- Choose a source, such as another customer with a leaked secret, and a destination.
- Follow the hops. Each one shows Confirmed, Expected, Blocked or Unknown, with the reason and what the next hop needs.
- Switch the peer gate between v0.46 and later and releases before v0.46 to see where it changes the outcome.
Troubleshooting your own reasoning
- "The relay admitted it, so it's in." No. Relay admission only means packets can be forwarded. The tunnel secret, peer gate and authentication still apply.
- "Encryption means isolation." Encryption protects traffic in transit. Isolation between customers comes from the secret, the peer gate and authentication.
- "Revoked means forgotten." Revocation stops the credential, not the knowledge of the address. Use New address when you need both.
Next steps
- Read section 3, network architecture, of the security whitepaper.
- Require approval for new computers: Pairing clients.
- Review how satellites join a hub: Satellites and failover.