Ward Vandewege b34e90c45d Fix bug in preauthkeys: namespace object was not populated in the return
value from CreatePreAuthKey and GetPreAuthKeys. Add tests for that bug,
and the rest of the preauthkeys functionality.

Fix path in `compress` Makefile target.
2021-05-02 14:58:05 -04:00
2021-04-30 09:55:39 +02:00
2020-07-27 22:07:23 +10:00
2021-02-21 01:31:50 +01:00
2021-04-28 16:55:29 +02:00
2021-02-20 23:57:06 +01:00
2020-06-21 11:21:07 +02:00
2021-04-24 11:26:50 -04:00
2021-04-30 09:53:44 +02:00
2021-04-28 16:55:29 +02:00
2021-02-21 22:11:27 +01:00

Headscale

Join the chat at https://gitter.im/headscale-dev/community

An open source implementation of the Tailscale coordination server.

Overview

Tailscale is a modern VPN built on top of Wireguard. It works like an overlay network between the computers of your networks - using all kinds of NAT traversal sorcery.

Everything in Tailscale is Open Source, except the GUI clients for proprietary OS (Windows and macOS/iOS), and the 'coordination/control server'.

The control server works as an exchange point of cryptographic public keys for the nodes in the Tailscale network. It also assigns the IP addresses of the clients, creates the boundaries between each user, enables sharing machines between users, and exposes the advertised routes of your nodes.

Headscale implements this coordination server.

Status

  • Basic functionality (nodes can communicate with each other)
  • Node registration through the web flow
  • Network changes are relied to the nodes
  • Multiuser Namespace support
  • Basic routing (advertise & accept)
  • Share nodes between users namespaces
  • Node registration via pre-auth keys
  • ACLs
  • DNS

... and probably lots of stuff missing

Roadmap 🤷

Basic multiuser support (multinamespace, actually) is now implemented. No node sharing or ACLs between namespaces yet though...

Pre-auth keys should also be feasible.

Suggestions/PRs welcomed!

Running it

  1. Compile the headscale binary
make
  1. Get yourself a PostgreSQL DB running (yes, I know)
docker run --name headscale -e POSTGRES_DB=headscale -e \
  POSTGRES_USER=foo -e POSTGRES_PASSWORD=bar -p 5432:5432 -d postgres
  1. Set some stuff up (headscale Wireguard keys & the config.json file)
wg genkey > private.key
wg pubkey < private.key > public.key  # not needed 
cp config.json.example config.json
  1. Create a namespace (equivalent to a user in tailscale.com)
./headscale namespace create myfirstnamespace
  1. Run the server
./headscale serve
  1. Add your first machine
tailscale up -login-server YOUR_HEADSCALE_URL
  1. Navigate to the URL you will get with tailscale up, where you'll find your machine key.

  2. In the server, register your machine to a namespace with the CLI

./headscale -n myfirstnamespace register YOURMACHINEKEY

Configuration reference

Headscale's configuration file is named config.json or config.yaml. Headscale will look for it in /etc/headscale, ~/.headscale and finally the directory from where the Headscale binary is executed.

    "server_url": "http://192.168.1.12:8000",
    "listen_addr": "0.0.0.0:8000",

server_url is the external URL via which Headscale is reachable. listen_addr is the IP address and port the Headscale program should listen on.

    "private_key_path": "private.key",

private_key_path is the path to the Wireguard private key. If the path is relative, it will be interpreted as relative to the directory the configuration file was read from.

    "derp_map_path": "derp.yaml",

derp_map_path is the path to the DERP map file. If the path is relative, it will be interpreted as relative to the directory the configuration file was read from.

    "db_host": "localhost",
    "db_port": 5432,
    "db_name": "headscale",
    "db_user": "foo",
    "db_pass": "bar",

The fields starting with db_ are used for the PostgreSQL connection information.

Running the service via TLS (optional)

    "tls_cert_path": ""
    "tls_key_path": ""

Headscale can be configured to expose its web service via TLS. To configure the certificate and key file manually, set the tls_cert_path and tls_cert_path configuration parameters. If the path is relative, it will be interpreted as relative to the directory the configuration file was read from.

    "tls_letsencrypt_hostname": "",
    "tls_letsencrypt_cache_dir": ".cache",
    "tls_letsencrypt_challenge_type": "HTTP-01",

To get a certificate automatically via Let's Encrypt, set tls_letsencrypt_hostname to the desired certificate hostname. This name must resolve to the IP address(es) Headscale is reachable on (i.e., it must correspond to the server_url configuration parameter). The certificate and Let's Encrypt account credentials will be stored in the directory configured in tls_letsencrypt_cache_dir. If the path is relative, it will be interpreted as relative to the directory the configuration file was read from. The certificate will automatically be renewed as needed. The default challenge type HTTP-01 requires that Headscale listens on port 80 for the Let's Encrypt automated validation, in addition to whatever port is configured in listen_addr. Alternatively, tls_letsencrypt_challenge_type can be set to TLS-ALPN-01. In this configuration, Headscale must be reachable via port 443, but port 80 is not required.

Disclaimer

  1. I have nothing to do with Tailscale, or Tailscale Inc.
  2. The purpose of writing this was to learn how Tailscale works.
  3. I don't use Headscale myself.
Description
An open source, self-hosted implementation of the Tailscale control server
Readme
Languages
Go 97.7%
HTML 1.4%
Nix 0.6%
Shell 0.2%
Makefile 0.1%