MyFavMirrors/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2025-07-14 19:31:53 -04:00
Code Issues Packages Projects Releases Wiki Activity

ci: fix golangci-lint flag for v2 compatibility (#2654)

Browse Source
This commit is contained in:
Kristoffer Dalby 2025-06-24 08:14:50 +02:00 committed by GitHub
parent 1553f0ab53
commit 081af2674b
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
8 changed files with 54 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.github/workflows/lint.yml vendored
View File

@ -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

2
.goreleaser.yml
View File

@ -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

6
CHANGELOG.md
View File

@ -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)

4
README.md
View File

@ -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

7
docs/about/faq.md
View File

@ -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

5
docs/ref/dns.md
View File

@ -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`"

40
docs/ref/oidc.md
View File

@ -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"
```

46
docs/ref/routes.md
View File

@ -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