diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml index 43bec0fb..918c6194 100644 --- a/.github/workflows/lint.yml +++ b/.github/workflows/lint.yml @@ -34,7 +34,7 @@ jobs: - name: golangci-lint if: steps.changed-files.outputs.files == 'true' - run: nix develop --command -- golangci-lint run --new-from-rev=${{github.event.pull_request.base.sha}} --out-format=colored-line-number + run: nix develop --command -- golangci-lint run --new-from-rev=${{github.event.pull_request.base.sha}} --format=colored-line-number prettier-lint: runs-on: ubuntu-latest diff --git a/.goreleaser.yml b/.goreleaser.yml index 134974f9..bb6a8ac8 100644 --- a/.goreleaser.yml +++ b/.goreleaser.yml @@ -93,7 +93,7 @@ nfpms: preremove: ./packaging/deb/prerm deb: lintian_overrides: - - no-changelog # Our CHANGELOG.md uses a different formatting + - no-changelog # Our CHANGELOG.md uses a different formatting - no-manual-page - statically-linked-binary diff --git a/CHANGELOG.md b/CHANGELOG.md index d241434d..9cf62ae3 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -9,8 +9,7 @@ ### Changes -- Remove policy v1 code - [#2600](https://github.com/juanfont/headscale/pull/2600) +- Remove policy v1 code [#2600](https://github.com/juanfont/headscale/pull/2600) - Refactor Debian/Ubuntu packaging and drop support for Ubuntu 20.04. [#2614](https://github.com/juanfont/headscale/pull/2614) - Support client verify for DERP @@ -20,8 +19,7 @@ ### Changes -- Ensure nodes are matching both node key and machine key - when connecting. +- Ensure nodes are matching both node key and machine key when connecting. [#2642](https://github.com/juanfont/headscale/pull/2642) ## 0.26.0 (2025-05-14) diff --git a/README.md b/README.md index 8bfd2586..61a2c92c 100644 --- a/README.md +++ b/README.md @@ -11,8 +11,8 @@ to ensure you have the correct example configuration. The `main` branch might contain unreleased changes. The documentation is available for stable and development versions: -* [Documentation for the stable version](https://headscale.net/stable/) -* [Documentation for the development version](https://headscale.net/development/) +- [Documentation for the stable version](https://headscale.net/stable/) +- [Documentation for the development version](https://headscale.net/development/) ## What is Tailscale diff --git a/docs/about/faq.md b/docs/about/faq.md index f9b43373..6d66297e 100644 --- a/docs/about/faq.md +++ b/docs/about/faq.md @@ -61,12 +61,12 @@ of Headscale: 1. An environment with 1000 servers - - they rarely "move" (change their endpoints) - - new nodes are added rarely + - they rarely "move" (change their endpoints) + - new nodes are added rarely 2. An environment with 80 laptops/phones (end user devices) - - nodes move often, e.g. switching from home to office + - nodes move often, e.g. switching from home to office Headscale calculates a map of all nodes that need to talk to each other, creating this "world map" requires a lot of CPU time. When an event that @@ -122,7 +122,6 @@ help to the community. Running headscale on a machine that is also in the tailnet can cause problems with subnet routers, traffic relay nodes, and MagicDNS. It might work, but it is not supported. - ## Why do two nodes see each other in their status, even if an ACL allows traffic only in one direction? A frequent use case is to allow traffic only from one node to another, but not the other way around. For example, the diff --git a/docs/ref/dns.md b/docs/ref/dns.md index 01f48e0a..dc151825 100644 --- a/docs/ref/dns.md +++ b/docs/ref/dns.md @@ -9,10 +9,10 @@ Headscale allows to set extra DNS records which are made available via [MagicDNS](https://tailscale.com/kb/1081/magicdns). Extra DNS records can be configured either via static entries in the [configuration file](./configuration.md) or from a JSON file that Headscale continuously watches for changes: -* Use the `dns.extra_records` option in the [configuration file](./configuration.md) for entries that are static and +- Use the `dns.extra_records` option in the [configuration file](./configuration.md) for entries that are static and don't change while Headscale is running. Those entries are processed when Headscale is starting up and changes to the configuration require a restart of Headscale. -* For dynamic DNS records that may be added, updated or removed while Headscale is running or DNS records that are +- For dynamic DNS records that may be added, updated or removed while Headscale is running or DNS records that are generated by scripts the option `dns.extra_records_path` in the [configuration file](./configuration.md) is useful. Set it to the absolute path of the JSON file containing DNS records and Headscale processes this file as it detects changes. @@ -25,7 +25,6 @@ hostname and port combination "http://hostname-in-magic-dns.myvpn.example.com:30 Currently, [only A and AAAA records are processed by Tailscale](https://github.com/tailscale/tailscale/blob/v1.78.3/ipn/ipnlocal/local.go#L4461-L4479). - 1. Configure extra DNS records using one of the available configuration options: === "Static entries, via `dns.extra_records`" diff --git a/docs/ref/oidc.md b/docs/ref/oidc.md index 871b20a2..c2586d30 100644 --- a/docs/ref/oidc.md +++ b/docs/ref/oidc.md @@ -179,35 +179,43 @@ However if you don't have a domain, or need to add users outside of your domain, You can also use `allowed_domains` and `allowed_users` to restrict the users who can authenticate. ## Authelia -Authelia since v4.39.0, has removed most claims from the `ID Token`, they are still available when application queries [UserInfo Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo). + +Authelia since v4.39.0, has removed most claims from the `ID Token`, they are still available when application queries [UserInfo Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo). Following config restores sending 'default' claims in the `ID Token` For more information please read: [Authelia restore functionality prior to claims parameter](https://www.authelia.com/integration/openid-connect/openid-connect-1.0-claims/#restore-functionality-prior-to-claims-parameter) - ```yaml identity_providers: oidc: claims_policies: default: - id_token: ['groups', 'email', 'email_verified', 'alt_emails', 'preferred_username', 'name'] + id_token: + [ + "groups", + "email", + "email_verified", + "alt_emails", + "preferred_username", + "name", + ] clients: - - client_id: 'headscale' - client_name: 'headscale' - client_secret: '' + - client_id: "headscale" + client_name: "headscale" + client_secret: "" public: false - claims_policy: 'default' - authorization_policy: 'two_factor' + claims_policy: "default" + authorization_policy: "two_factor" require_pkce: true - pkce_challenge_method: 'S256' + pkce_challenge_method: "S256" redirect_uris: - - 'https://headscale.example.com/oidc/callback' + - "https://headscale.example.com/oidc/callback" scopes: - - 'openid' - - 'profile' - - 'groups' - - 'email' - userinfo_signed_response_alg: 'none' - token_endpoint_auth_method: 'client_secret_basic' + - "openid" + - "profile" + - "groups" + - "email" + userinfo_signed_response_alg: "none" + token_endpoint_auth_method: "client_secret_basic" ``` diff --git a/docs/ref/routes.md b/docs/ref/routes.md index 44f74bac..9f32d9bc 100644 --- a/docs/ref/routes.md +++ b/docs/ref/routes.md @@ -1,4 +1,5 @@ # Routes + Headscale supports route advertising and can be used to manage [subnet routers](https://tailscale.com/kb/1019/subnets) and [exit nodes](https://tailscale.com/kb/1103/exit-nodes) for a tailnet. @@ -10,11 +11,13 @@ and [exit nodes](https://tailscale.com/kb/1103/exit-nodes) for a tailnet. from a specific IP address. ## Subnet router + The setup of a subnet router requires double opt-in, once from a subnet router and once on the control server to allow its use within the tailnet. Optionally, use [`autoApprovers` to automatically approve routes from a subnet router](#automatically-approve-routes-of-a-subnet-router). ### Setup a subnet router + #### Configure a node as subnet router Register a node and advertise the routes it should handle as comma separated list: @@ -31,7 +34,6 @@ $ sudo tailscale set --advertise-routes=10.0.0.0/8,192.168.0.0/24 Finally, [enable IP forwarding](#enable-ip-forwarding) to route traffic. - #### Enable the subnet router on the control server The routes of a tailnet can be displayed with the `headscale nodes list-routes` command. A subnet router with the @@ -72,6 +74,7 @@ documentation](https://tailscale.com/kb/1019/subnets#use-your-subnet-routes-from router on different operating systems. ### Restrict the use of a subnet router with ACL + The routes announced by subnet routers are available to the nodes in a tailnet. By default, without an ACL enabled, all nodes can accept and use such routes. Configure an ACL to explicitly manage who can use routes. @@ -91,18 +94,15 @@ denied. "acls": [ { "action": "accept", - "src": [ - "node" - ], - "dst": [ - "service.example.net:80,443" - ] + "src": ["node"], + "dst": ["service.example.net:80,443"] } ] } ``` ### Automatically approve routes of a subnet router + The initial setup of a subnet router usually requires manual approval of their announced routes on the control server before they can be used by a node in a tailnet. Headscale supports the `autoApprovers` section of an ACL to automate the approval of routes served with a subnet router. @@ -114,15 +114,11 @@ owned by the user `alice` and that also advertises the tag `tag:router`. ```json title="Subnet routers owned by alice and tagged with tag:router are automatically approved" { "tagOwners": { - "tag:router": [ - "alice@" - ] + "tag:router": ["alice@"] }, "autoApprovers": { "routes": { - "192.168.0.0/24": [ - "tag:router" - ] + "192.168.0.0/24": ["tag:router"] } }, "acls": [ @@ -141,11 +137,13 @@ Please see the [official Tailscale documentation](https://tailscale.com/kb/1337/ information on auto approvers. ## Exit node + The setup of an exit node requires double opt-in, once from an exit node and once on the control server to allow its use within the tailnet. Optionally, use [`autoApprovers` to automatically approve an exit node](#automatically-approve-an-exit-node-with-auto-approvers). ### Setup an exit node + #### Configure a node as exit node Register a node and make it advertise itself as an exit node: @@ -162,7 +160,6 @@ $ sudo tailscale set --advertise-exit-node Finally, [enable IP forwarding](#enable-ip-forwarding) to route traffic. - #### Enable the exit node on the control server The routes of a tailnet can be displayed with the `headscale nodes list-routes` command. An exit node can be recognized @@ -202,8 +199,9 @@ Please refer to the official [Tailscale documentation](https://tailscale.com/kb/ how to use an exit node on different operating systems. ### Restrict the use of an exit node with ACL + An exit node is offered to all nodes in a tailnet. By default, without an ACL enabled, all nodes in a tailnet can select -and use an exit node. Configure `autogroup:internet` in an ACL rule to restrict who can use *any* of the available exit +and use an exit node. Configure `autogroup:internet` in an ACL rule to restrict who can use _any_ of the available exit nodes. ```json title="Example use of autogroup:internet" @@ -211,18 +209,15 @@ nodes. "acls": [ { "action": "accept", - "src": [ - "..." - ], - "dst": [ - "autogroup:internet:*" - ] + "src": ["..."], + "dst": ["autogroup:internet:*"] } ] } ``` ### Automatically approve an exit node with auto approvers + The initial setup of an exit node usually requires manual approval on the control server before it can be used by a node in a tailnet. Headscale supports the `autoApprovers` section of an ACL to automate the approval of a new exit node as soon as it joins the tailnet. @@ -234,14 +229,10 @@ is automatically approved: ```json title="Exit nodes owned by alice and tagged with tag:exit are automatically approved" { "tagOwners": { - "tag:exit": [ - "alice@" - ] + "tag:exit": ["alice@"] }, "autoApprovers": { - "exitNode": [ - "tag:exit" - ] + "exitNode": ["tag:exit"] }, "acls": [ // more rules @@ -272,6 +263,7 @@ availability](https://tailscale.com/kb/1115/high-availability#subnet-router-high interruptions for clients. See [issue 2129](https://github.com/juanfont/headscale/issues/2129) for more information. ## Troubleshooting + ### Enable IP forwarding A subnet router or exit node is routing traffic on behalf of other nodes and thus requires IP forwarding. Check the