title: Tailscale

description: Learn how to use Tailscale in your Coder workspace.

This guide walks you through configuring [Tailscale networking] for use inside

[Coder workspaces]. With Tailscale networking, you can access services running

inside Coder and services running on your [tailnet (Tailscale private network)].

[tailscale networking]: https://tailscale.com/

[tailnet (tailscale private network)]: https://tailscale.com/kb/1136/tailnet/

[coder workspaces]: ../../workspaces/index.md

As part of this tutorial, you'll create an image with the following that you'll

use to create new Coder workspaces. The container image will include:

- The Tailscale daemon (`tailscaled`)

- A transparent proxy tool (`proxychains4`)

- Environment variables to control proxy behavior for outbound connections

- A [SOCKS5 proxy] included in `tailscaled` to facilitate connections to the

tailnet, listening on `localhost:1080`

- An [HTTP proxy] included in `tailscaled` to facilitate connections to the

tailnet, listening on `localhost:3128`

[socks5 proxy]: https://en.wikipedia.org/wiki/SOCKS

[http proxy]: https://en.wikipedia.org/wiki/Proxy_server#Web_proxy_servers

This guide describes how to install Tailscale in a Ubuntu base image using the

package manager and running it in userspace networking mode. As such:

- The image (which you will create as part of this tutorial) requires

[container-based virtual machine] workspaces, so that `systemd` can start the

Tailscale daemon (`tailscaled`)

- Users will require `sudo` access to configure the Tailscale tunnel

- Inbound connections from other devices on the tailnet to your workspace will

appear to originate from `localhost`

- Outbound connections to other devices on the tailnet will require support for

HTTP proxies; otherwise, you'll need to use a wrapper such as `proxychains4`

- The example in this article applies to Ubuntu 20.04 LTS (Focal Fossa), so you

may need to adapt it for compatibility with your preferred base image

Tailscale does not require root access to operate in userspace networking mode,

and the requirement to use [container-based virtual machine] workspaces applies

only to the instructions in this guide. [Contact our support team] if you are

interested in using Tailscale in your Coder workspace without root access.

[contact our support team]: ../../feedback.md

[container-based virtual machine]: ../../workspaces/cvms.md

In Coder, developer workspaces are defined by a Dockerfile that contains the

apps, tools, and dependencies that you need to work on the project.

[custom image docs]: ../../images/writing

[guide to writing dockerfiles]:

https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

To simplify creating and maintaining the image, we recommend structuring your

source code so that files added or modified in the image match the hierarchy of

the target files, in a subdirectory called `files`:

While it is possible to configure everything directly in a single Dockerfile, we

recommend using a folder hierarchy, since this makes it easier to create a

reproducible image and examine the change history for individual files.

Create the folder hierarchy:

Then, create the following files (we'll walk you through the contents of each in

the following steps):

Add the Tailscale package repository to `tailscale.list` in the local path

`files/etc/apt/sources.list.d`. This will appear in `/etc/apt/sources.list.d` in

the resulting image, with the following contents:

This configures `apt` and `apt-get` to install packages from the Tailscale

repository and verify package signatures with the specified public key.

For improved security, you can configure `apt` to deny package installation from

a given repository by default and allow specific packages by name. To do this,

create `files/etc/apt/preferences.d/tailscale` with the following contents:

Retrieve the signing key from Tailscale, and store the binary (dearmored) key

file in `files/usr/share/keyrings/tailscale.gpg`:

By default, `tailscaled` will store its internal state in a **state file**

located at `/var/lib/tailscale/tailscaled.state` (this is is ephemeral in

Coder). We will need to modify the service settings to:

- Store the state file in the persistent home volume (`/home/coder`)

- Enable userspace networking

- Enable the SOCKS5 proxy (optional)

- Enable the HTTP proxy (optional)

If you do not require outbound connections from the workspace to other services

running in the tailnet, you may skip the steps where you configure the proxies.

Override the `ExecStart` setting for the `tailscaled` service by saving the

following to `files/etc/systemd/system/tailscaled.service.d/tailscale.conf`:

Create a `Dockerfile`, build it, and push to an external repository, such as

Docker Hub:

FROM codercom/enterprise-base:ubuntu

USER root

COPY files /

ARG DEBIAN_FRONTEND="noninteractive"

RUN apt-get update && \

apt-get install --no-install-recommends --yes --quiet \

netcat-openbsd \

proxychains4 \

python3 && \

apt-get install --no-install-recommends --yes --quiet \

tailscale && \

# Delete package cache to avoid consuming space in layer

apt-get clean && \

rm -rf /var/lib/apt/lists/*

USER coder

ENV ALL_PROXY=socks5://localhost:1080

ENV http_proxy=http://localhost:3128

[Create a workspace] using the container image. Initially, `tailscaled` should

be running, but it will indicate that it requires authentication:

Authenticate using `sudo tailscale up`, then verify that other network devices

are visible:

`tailscale` should maintain connectivity across workspace rebuilds, since we

chose to store the state file in a persistent volume.

[create a workspace]: ../../workspaces/getting-started.md

By creating two workspaces from the same image, both authenticated to Tailscale,

we can verify connectivity works as expected. In one workspace, run the Python

web server:

In another workspace, verify that `tailscaled` is listening for connections on

the configured proxy ports:

Check that the `http_proxy` environment variable is set to the address of the

local `tailscaled` proxy:

Run `curl` (which respects the `http_proxy` command) to connect to the webserver

running in the other workspace. Since we proxy the connection through the local

`tailscaled` instance, we can use the internal hostname:

For applications that do not respect the `http_proxy` or `ALL_PROXY` environment

variables, consider using a tool like `proxychains4` to intercept the socket

system calls and transparently route traffic through the proxy.

{

"path": "./guides/customization/tailscale.md"

},