Kristoffer Dalby 5cba8ddc62 testdata: re-run tscap with populated approved_routes and tag fixes
Replaces the previous capture corpus with the output of a fresh tscap
batch built from:

  - kradalby/tscap@d2cd4f9 (anonymize: substitute tags too)
  - kradalby/tscap@3080147 (runner: capture autoApprover decisions in
    ApprovedRoutes)

Two regressions in the previous corpus are fixed:

  1. approved_routes was committed as [] on every node in all 617
     files because the runner never asked the SaaS API which routes had
     been auto-approved. The new corpus has 533/1296 routes_results and
     462/3765 grant_results entries with non-empty approved sets,
     matching what SaaS actually returned.

  2. Anonymization rewrote tag references in policy JSON
     (tag:exit-a → tag:pidgey, tag:router-a → tag:spearow, …) but left
     node.Tags untouched, so via-grant-* and other scenarios that use
     these collision-prone tag names had policies pointing at tag
     identifiers no node carried. The new corpus has node.Tags routed
     through the same substitution table.

Compat-test impact (subtest level):

                  before        after        delta
    Routes        1697 / 825    3397 / 13    -812 fail
    ACL           1799 /   8    1805 /  0      -8 fail
    Grants        3426 /  48    3463 / 11     -37 fail
    SSH            521 /  71     536 / 56     -15 fail
    ViaGrant         0 /   4      31 / 21      n/a (test now actually
                                                  loads files)
    Total         7443 / 956    9232 / 101   -855 fail (-89.4%)

Verified zero true accuracy regressions: every test that passed
against the old corpus and now fails against the new corpus is a
false-pass-becoming-true-fail. The single nominal regression
(grant-j3/beedrill) used to pass because both sides were empty under
the broken approved_routes; the new file exposes a real divergence in
filter.go srcIPsWithRoutes where headscale appends approved subnet
routes to wildcard SrcIPs and SaaS does not.

Updates #3157
Updates #3169
2026-04-09 06:20:03 +00:00
2026-03-11 03:18:14 -07:00
2026-03-31 13:36:31 +02:00
2022-03-19 09:23:03 +00:00
2021-10-26 20:37:37 +00:00
2026-03-25 22:30:03 +01:00
2024-09-04 07:55:16 +02:00
2026-03-11 03:18:14 -07:00
2026-03-11 03:18:14 -07:00
2026-03-14 02:52:28 -07:00
2026-03-14 02:52:28 -07:00
2026-03-14 02:52:28 -07:00
2020-06-21 11:21:07 +02:00
2026-03-01 09:24:52 +01:00

headscale logo

ci

An open source, self-hosted implementation of the Tailscale control server.

Join our Discord server for a chat.

Note: Always select the same GitHub tag as the released version you use to ensure you have the correct example configuration. The main branch might contain unreleased changes. The documentation is available for stable and development versions:

What is Tailscale

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

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

The control server works as an exchange point of Wireguard public keys for the nodes in the Tailscale network. It 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.

A Tailscale network (tailnet) is private network which Tailscale assigns to a user in terms of private users or an organisation.

Design goal

Headscale aims to implement a self-hosted, open source alternative to the Tailscale control server. Headscale's goal is to provide self-hosters and hobbyists with an open-source server they can use for their projects and labs. It implements a narrow scope, a single Tailscale network (tailnet), suitable for a personal use, or a small open-source organisation.

Supporting Headscale

If you like headscale and find it useful, there is a sponsorship and donation buttons available in the repo.

Features

Please see "Features" in the documentation.

Client OS support

Please see "Client and operating system support" in the documentation.

Running headscale

Please note that we do not support nor encourage the use of reverse proxies and container to run Headscale.

Please have a look at the documentation.

For NixOS users, a module is available in nix/.

Builds from main

Development builds from the main branch are available as container images and binaries. See the development builds documentation for details.

Talks

Disclaimer

This project is not associated with Tailscale Inc.

However, one of the active maintainers for Headscale is employed by Tailscale and he is allowed to spend work hours contributing to the project. Contributions from this maintainer are reviewed by other maintainers.

The maintainers work together on setting the direction for the project. The underlying principle is to serve the community of self-hosters, enthusiasts and hobbyists - while having a sustainable project.

Contributing

Please read the CONTRIBUTING.md file.

Requirements

To contribute to headscale you would need the latest version of Go and Buf (Protobuf generator).

We recommend using Nix to setup a development environment. This can be done with nix develop, which will install the tools and give you a shell. This guarantees that you will have the same dev env as headscale maintainers.

Code style

To ensure we have some consistency with a growing number of contributions, this project has adopted linting and style/formatting rules:

The Go code is linted with golangci-lint and formatted with golines (width 88) and gofumpt. Please configure your editor to run the tools while developing and make sure to run make lint and make fmt before committing any code.

The Proto code is linted with buf and formatted with clang-format.

The docs are formatted with mdformat.

The rest (Markdown, YAML, etc) is formatted with prettier.

Check out the .golangci.yaml and Makefile to see the specific configuration.

Install development tools

  • Go
  • Buf
  • Protobuf tools

Install and activate:

nix develop

Testing and building

Some parts of the project require the generation of Go code from Protobuf (if changes are made in proto/) and it must be (re-)generated with:

make generate

Note: Please check in changes from gen/ in a separate commit to make it easier to review.

To run the tests:

make test

To build the program:

make build

Development workflow

We recommend using Nix for dependency management to ensure you have all required tools. If you prefer to manage dependencies yourself, you can use Make directly:

With Nix (recommended):

nix develop
make test
make build

With your own dependencies:

make test
make build

The Makefile will warn you if any required tools are missing and suggest running nix develop. Run make help to see all available targets.

Contributors

Made with contrib.rocks.

S
Description
An open source, self-hosted implementation of the Tailscale control server
Readme BSD-3-Clause 88 MiB
Languages
Go 98.7%
Nix 1%
Shell 0.1%
CSS 0.1%