docs: add context for wireguard in places referencing tailscale (#15901)

> We do not use Tailscale (product) but instead import Tailscale OSS
libraries which has some nice ways of handling Wireguard. We also use
Tailscale's logo in our architecture, but calling it only `Tailscale`
seems to throw people off when they're considering Coder and how it
works.

I've left it wherever it seems to make sense (such as when we talk about
[DERP](https://coder.com/docs/admin/networking#relayed-connections)),
and sprinkled some `Wireguard` and `websocket/HTTPS` where I could
This commit is contained in:
Edward Angert
2024-12-17 15:13:12 -05:00
committed by GitHub
parent 8de3cd6400
commit bcb15aab42
4 changed files with 19 additions and 17 deletions

View File

@ -9,9 +9,10 @@ but otherwise, all topologies _just work_ with Coder.
When possible, we establish direct connections between users and workspaces.
Direct connections are as fast as connecting to the workspace outside of Coder.
When NAT traversal fails, connections are relayed through the coder server. All
user <-> workspace connections are end-to-end encrypted.
user-workspace connections are end-to-end encrypted.
[Tailscale's open source](https://tailscale.com) backs our networking logic.
[Tailscale's open source](https://tailscale.com) backs our websocket/HTTPS
networking logic.
## Requirements
@ -128,12 +129,13 @@ but this can be disabled or changed for
By default, your Coder server also runs a built-in DERP relay which can be used
for both public and [offline deployments](../../install/offline.md).
However, Tailscale has graciously allowed us to use
However, our Wireguard integration through Tailscale has graciously allowed us
to use
[their global DERP relays](https://tailscale.com/kb/1118/custom-derp-servers/#what-are-derp-servers).
You can launch `coder server` with Tailscale's DERPs like so:
```bash
$ coder server --derp-config-url https://controlplane.tailscale.com/derpmap/default
coder server --derp-config-url https://controlplane.tailscale.com/derpmap/default
```
#### Custom Relays

View File

@ -33,12 +33,12 @@ counterpart can be reached. Once communication succeeds in one direction, we can
inspect the source address of the received packet to determine the return
address.
At a high level, STUN works like this:
> The below glosses over a lot of the complexity of traversing NATs. For a more
> in-depth technical explanation, see
> [How NAT traversal works (tailscale.com)](https://tailscale.com/blog/how-nat-traversal-works).
At a high level, STUN works like this:
- **Discovery:** Both the client and agent will send UDP traffic to one or more
configured STUN servers. These STUN servers are generally located on the
public internet, and respond with the public IP address and port from which