Von VPN zu Zero Trust: Wie Headscale und Tailscale sichere Verbindungen ermöglichen

Jens Schanz

15 Dez. 2025 • 11 min read

Einleitung

Klassische VPN-Konzepte stoßen in modernen IT-Umgebungen zunehmend an ihre Grenzen. Hybride Infrastrukturen, verteilte Teams, Cloud-Dienste und steigende Sicherheitsanforderungen verlangen nach neuen Ansätzen, insbesondere im Bereich Zugriffskontrolle und Netzwerksicherheit.

Ein zentrales Problem klassischer VPN-Lösungen ist ihre Netzwerkzentrierung: Benutzer werden nach erfolgreicher Anmeldung meist pauschal in ein internes Netzwerksegment eingebunden. Das widerspricht modernen Sicherheitsanforderungen, da ein einmal aufgebauter VPN-Tunnel häufig weitreichende Zugriffe ermöglicht – unabhängig davon, ob diese tatsächlich erforderlich sind. Hinzu kommen komplexe Firewall-Regeln, schwer wartbare Split-Tunnel-Konfigurationen und eine steigende Angriffsfläche bei kompromittierten Endgeräten.

Zusätzlich verschärft Carrier Grade NAT (CGNAT) die Situation erheblich. Immer mehr Internetanschlüsse – insbesondere Mobilfunk- und private DSL-/Kabelanschlüsse – verfügen über keine öffentliche IPv4-Adresse mehr. Klassische VPNs, die auf eingehende Verbindungen oder Portfreigaben angewiesen sind, funktionieren unter diesen Bedingungen nur eingeschränkt oder gar nicht. Workarounds wie Portmapper, Double NAT oder zusätzliche Gateway-Server erhöhen die Komplexität, ebenso wie IPv6, weiter und wirken dem eigentlichen Ziel, einer sicheren, einfachen Anbindung, entgegen.

Zero Trust verfolgt hier einen grundlegend anderen Ansatz: „Never trust, always verify.“ Jeder Zugriff wird explizit geprüft – unabhängig davon, ob er aus dem internen Netzwerk oder von außen erfolgt. Identität, Gerätezustand und Richtlinien stehen im Mittelpunkt, nicht das Netzwerksegment.

Mit Tailscale und dem Open-Source-Controller Headscale lässt sich dieses Modell praxisnah umsetzen. Auf Basis von WireGuard entstehen direkte, verschlüsselte Punkt-zu-Punkt-Verbindungen zwischen Endgeräten – selbst dann, wenn diese sich hinter CGNAT oder restriktiven Firewalls befinden. Zentrale Identity-Provider, fein granulare Access-Control-Listen und der Verzicht auf klassische Portfreigaben machen die Architektur nicht nur sicherer, sondern auch deutlich wartungsärmer.

In diesem Beitrag werfen wir einen Blick darauf, wie Tailscale und Headscale funktionieren, warum sie klassische VPNs sinnvoll ablösen können und wie sie helfen, Zero-Trust-Prinzipien effektiv in der Praxis umzusetzen.

Vorbereitung: DNS-Grundlage für Headscale & Tailscale

Für den Betrieb von Headscale (insbesondere in Kombination mit TLS, Reverse Proxy oder MagicDNS-Alternativen) wird ein öffentlich erreichbarer DNS-Name benötigt. Idealerweise steht dafür eine eigene DNS-Zone zur Verfügung.

Ist dies nicht der Fall, kann ein Dynamic-DNS-Anbieter wie DuckDNS verwendet werden. DuckDNS stellt kostenfrei Subdomains zur Verfügung und eignet sich hervorragend für Test-, Home-Lab- und kleinere Produktionsumgebungen.

Um die DNS-Einträge automatisch aktuell zu halten, nutzen wir einen Docker-Container von linuxserver.io, der die Registrierung und Aktualisierung der IP-Adresse übernimmt.

Ressourcen

DuckDNS: https://www.duckdns.org
Docker-Image: https://docs.linuxserver.io/images/docker-duckdns/

Verzeichnisstruktur vorbereiten

Wir trennen Applikationen und persistente Daten sauber voneinander. Das erleichtert Wartung, Backups und spätere Migrationen.

mkdir -p /opt/docker/apps/duckdns
mkdir -p /opt/docker/apps/headscale
mkdir -p /opt/docker/volumes

/opt/docker/
├── apps/
│   ├── duckdns/
│   │   └── docker-compose.yml
│   └── headscale/
│       └── docker-compose.yml
└── volumes/
    └── duckdns/
        └── config/

DuckDNS Docker-Container deployen

Als Nächstes erstellen wir die Docker-Compose-Datei für DuckDNS unter:

/opt/docker/apps/duckdns/docker-compose.yml

docker-compose.yml

services:
  duckdns:
    image: lscr.io/linuxserver/duckdns:latest
    container_name: duckdns
    environment:
      TZ: Europe/Berlin

      # Kommagetrennte Liste der DuckDNS-Subdomains
      SUBDOMAINS: 82qqhpjqxz3w,82qqhpjqxz3w-traefik,82qqhpjqxz3w-ui

      # DuckDNS Token aus dem Benutzerkonto
      TOKEN: <INSERT_DUCKDNS_TOKEN>

      # Optional: Logfile deaktivieren (true/false)
      LOG_FILE: "false"
    volumes:
      - /opt/docker/volumes/duckdns/config:/config
    restart: unless-stopped
```

Konfigurationsparameter im Überblick

Parameter	Beschreibung
`SUBDOMAINS`	Alle DuckDNS-Subdomains, die aktualisiert werden sollen (kommagetrennt)
`TOKEN`	Persönlicher DuckDNS-Token (aus dem Webinterface)
`TZ`	Zeitzone für Logs
`LOG_FILE`	Aktiviert/deaktiviert Logdateien im Volume
`restart`	Automatischer Neustart des Containers

Empfehlung

Lege separate Subdomains für:

Headscale (z. B. 82qqhpjqxz3w.duckdns.org)
Reverse Proxy (z. B. 82qqhpjqxz3w-traefik.duckdns.org)
Web-UI (z. B. 82qqhpjqxz3w-ui.duckdns.org)

an, um später saubere TLS-Zertifikate und Routing-Regeln zu ermöglichen.

Container starten

In den Beispielen verwenden wie Docker Compose V2. Wer Docker Compose V1 verwendet, muss in den folgenden Befehlen docker compose durch docker-compose ersetzen.

cd /opt/docker/apps/duckdns
docker compose up -d

Anschließend kannst du prüfen, ob die DNS-Einträge korrekt gesetzt wurden:

Headscale

dig 82qqhpjqxz3w.duckdns.org

Traefik (Reverse Proxy / Routing)

dig 82qqhpjqxz3w-traefik.duckdns.org

Headscale Web-UI

dig 82qqhpjqxz3w-ui.duckdns.org

Ergebnis

Nach erfolgreichem Start:

zeigt die DuckDNS-Subdomain auf die aktuelle öffentliche IP
funktioniert das Setup auch hinter CGNAT
steht eine stabile Grundlage für Headscale, TLS & Zero-Trust-Zugriffe zur Verfügung

Reverse Proxy & TLS-Basis: Traefik mit Let’s Encrypt und DuckDNS

Für den sicheren Betrieb von Headscale, Web-UIs und weiteren Diensten ist eine zuverlässige TLS-Terminierung unerlässlich. Statt Zertifikate manuell zu verwalten oder Services direkt ins Internet zu exponieren, bietet sich ein zentraler Reverse Proxy an.

Traefik hat sich hier als leichtgewichtige, cloud-native Lösung etabliert: Es integriert sich nahtlos in Docker-Umgebungen, erkennt Services automatisch über Labels und übernimmt die vollständige TLS-Zertifikatsverwaltung mit Let’s Encrypt.

In diesem Abschnitt richten wir Traefik so ein, dass:

Zertifikate automatisch über die HTTP-01-Challenge bezogen werden
DuckDNS als dynamischer DNS-Dienst genutzt wird

Verzeichnisstruktur anlegen

mkdir -p /opt/docker/apps/traefik
mkdir -p /opt/docker/volumes/traefik/letsencrypt
mkdir -p /opt/docker/volumes/traefik/logs

Docker-Netzwerk erstellen (einmalig)

Traefik sollte in einem dedizierten externen Netzwerk laufen, damit andere Container sich gezielt einklinken können.

docker network create traefik

Traefik – docker-compose.yml

Pfad:

/opt/docker/apps/traefik/docker-compose.yml

HTTP-01 Challenge + DuckDNS

services:
  traefik:
    image: traefik:latest
    container_name: traefik
    restart: unless-stopped

    command:
      # -------------------------------------------------
      # Global / API
      # -------------------------------------------------
      - "--api.dashboard=true"
      - "--api.insecure=false"

      # -------------------------------------------------
      # EntryPoints
      # -------------------------------------------------
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"

      # HTTP → HTTPS Redirect
      - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
      - "--entrypoints.web.http.redirections.entrypoint.scheme=https"

      # -------------------------------------------------
      # Docker Provider
      # -------------------------------------------------
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"

      # -------------------------------------------------
      # ACME / Let's Encrypt – HTTP Challenge
      # -------------------------------------------------
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web"
      - "--certificatesresolvers.letsencrypt.acme.email=email@domain.tld"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"

      # -------------------------------------------------
      # Logging
      # -------------------------------------------------
      - "--log.level=INFO"
      # - "--log.level=DEBUG"

      - "--accesslog=true"
      - "--accesslog.filepath=/var/log/traefik/access.log"
      - "--accesslog.format=json"
      - "--accesslog.bufferingsize=100"

    ports:
      - "80:80"
      - "443:443"

    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /opt/docker/volumes/traefik/letsencrypt:/letsencrypt
      - /opt/docker/volumes/traefik/logs:/var/log/traefik

    labels:
      - "traefik.enable=true"

      # -------------------------------------------------
      # Traefik Dashboard
      # -------------------------------------------------
      - "traefik.http.routers.traefik.rule=Host(`82qqhpjqxz3w-traefik.duckdns.org`)"
      - "traefik.http.routers.traefik.entrypoints=websecure"
      - "traefik.http.routers.traefik.service=api@internal"
      - "traefik.http.routers.traefik.tls=true"
      - "traefik.http.routers.traefik.tls.certresolver=letsencrypt"

      # -------------------------------------------------
      # Basic Auth für Dashboard
      # -------------------------------------------------
      - "traefik.http.routers.traefik.middlewares=auth"
      - "traefik.http.middlewares.auth.basicauth.users=admin:<HASHED_PASSWORD>"

    networks:
      - traefik

networks:
  traefik:
    external: true

Wichtig: Passwort korrekt hashen

Kein Klartext-Passwort verwenden!
Erzeuge den Hash z. B. mit:

htpasswd -nb admin 'MEIN_SICHERES_PASSWORT'

Beispiel-Ergebnis:

admin:$apr1$H6uskkkW$IgXLP6ewTrSuBkTrqE8wj/

-> exakt so in das Label für die Basic-Auth übernehmen.

Warum HTTP-01 statt DNS-01?

In einem Szenario mit DuckDNS ist HTTP-01 die bessere Wahl, weil:

Thema	DNS-01	HTTP-01
DuckDNS API nötig	❌	❌
Öffentliche IPv4 nötig	❌	❌
Port 80 erreichbar	❌	✅
Einfachheit	⚠️	✅
Debugging	⚠️	✅

Voraussetzung:
Die DuckDNS-Subdomain zeigt korrekt auf die öffentliche IP.

Traefik starten

cd /opt/docker/apps/traefik
docker compose up -d

Logs prüfen:

docker logs -f traefik

Zertifikat prüfen:

ls -l /opt/docker/volumes/traefik/letsencrypt/acme.json

Ergebnis

TLS-Zertifikat automatisch von Let’s Encrypt
Erreichbar über https://82qqhpjqxz3w-traefik.duckdns.org
Keine Portfreigaben auf einzelne Services nötig
Perfekte Basis für Headscale über HTTPS

Headscale als Zero-Trust-Control-Plane betreiben

Mit Headscale lässt sich Tailscale vollständig self-hosted betreiben, ohne Abhängigkeit von einem SaaS-Control-Plane. Headscale übernimmt dabei die Rolle der zentralen Identity- und Policy-Instanz und ist damit ein kritischer Bestandteil einer Zero-Trust-Architektur.

In Kombination mit Traefik als Reverse Proxy sorgen wir dafür, dass:

Headscale ausschließlich verschlüsselt (HTTPS) erreichbar ist
TLS-Zertifikate automatisch über Let’s Encrypt (HTTP-01) ausgestellt werden
die Lösung problemlos mit DuckDNS und CGNAT funktioniert
sowohl API (Headscale) als auch Web-UI (Headplane) sauber getrennt erreichbar sind

Headscale & Headplane – docker-compose.yml

Pfad:

/opt/docker/apps/headscale/docker-compose.yml

services:
  headscale:
    image: docker.io/headscale/headscale:latest
    container_name: headscale
    restart: unless-stopped
    command: serve

    healthcheck:
      test: ["CMD", "headscale", "health"]

    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=traefik"

      # -------------------------------------------------
      # HTTPS – Headscale API
      # -------------------------------------------------
      - "traefik.http.routers.headscale.rule=Host(`82qqhpjqxz3w.duckdns.org`)"
      - "traefik.http.routers.headscale.entrypoints=websecure"
      - "traefik.http.routers.headscale.tls=true"
      - "traefik.http.routers.headscale.tls.certresolver=letsencrypt"

      - "traefik.http.services.headscale.loadbalancer.server.port=8080"
      - "traefik.http.services.headscale.loadbalancer.server.scheme=http"

      # -------------------------------------------------
      # HTTP → HTTPS Redirect
      # -------------------------------------------------
      - "traefik.http.routers.headscale-http.rule=Host(`82qqhpjqxz3w.duckdns.org`)"
      - "traefik.http.routers.headscale-http.entrypoints=web"
      - "traefik.http.routers.headscale-http.middlewares=redirect-to-https"

      - "traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https"

      # Headplane Auto-Discovery
      - "me.tale.headplane.target=headscale"

    networks:
      - traefik
      - backend

    ports:
      # optional – nur lokal
      - "127.0.0.1:8080:8080"
      - "127.0.0.1:9090:9090"

    volumes:
      - /opt/docker/volumes/headscale/config:/etc/headscale
      - /opt/docker/volumes/headscale/lib:/var/lib/headscale
      - /opt/docker/volumes/headscale/run:/var/run/headscale

  headplane:
    image: ghcr.io/tale/headplane:latest
    container_name: headplane
    restart: unless-stopped

    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=traefik"

      # -------------------------------------------------
      # HTTPS – Headplane UI
      # -------------------------------------------------
      - "traefik.http.routers.headplane.rule=Host(`82qqhpjqxz3w-ui.duckdns.org`)"
      - "traefik.http.routers.headplane.entrypoints=websecure"
      - "traefik.http.routers.headplane.tls=true"
      - "traefik.http.routers.headplane.tls.certresolver=letsencrypt"

      - "traefik.http.services.headplane.loadbalancer.server.port=3000"
      - "traefik.http.services.headplane.loadbalancer.server.scheme=http"

      # -------------------------------------------------
      # HTTP → HTTPS Redirect
      # -------------------------------------------------
      - "traefik.http.routers.headplane-http.rule=Host(`82qqhpjqxz3w-ui.duckdns.org`)"
      - "traefik.http.routers.headplane-http.entrypoints=web"
      - "traefik.http.routers.headplane-http.middlewares=redirect-to-https"

    networks:
      - traefik

    volumes:
      - /opt/docker/volumes/headplane/config/config.yaml:/etc/headplane/config.yaml
      - /opt/docker/volumes/headplane/data:/var/lib/headplane

      # Headscale Config Read-Only für UI
      - /opt/docker/volumes/headscale/config:/etc/headscale:ro

networks:
  traefik:
    external: true
  backend:
    driver: bridge

Ergebnis

Nach dem Start:

docker compose up -d

Headscale API: https://82qqhpjqxz3w.duckdns.org
Headplane UI: https://82qqhpjqxz3w-ui.duckdns.org
Zertifikate automatisch via Let’s Encrypt
Funktioniert zuverlässig mit DuckDNS & CGNAT
Zero-Trust-ready Control Plane

Headscale konfigurieren: Zero-Trust-Grundlagen & Reverse-Proxy-Betrieb

Nachdem Headscale erfolgreich per Docker und Traefik bereitgestellt wurde, folgt nun der zentrale Schritt: die Konfiguration der Control Plane.

Da Headscale in diesem Setup nicht selbst TLS terminiert, sondern vollständig hinter Traefik als Reverse Proxy betrieben wird, muss die config.yaml gezielt darauf abgestimmt werden. Ziel ist eine klare Trennung der Verantwortlichkeiten:

Traefik: TLS, Zertifikate, öffentliche Exponierung
Headscale: Identity, Node-Management, ACLs, DNS, Policies

Dieses Design ist robuster, übersichtlicher und besser wartbar – insbesondere in Zero-Trust-Architekturen.

Wichtige Design-Entscheidung

Headscale ACME / Let’s Encrypt deaktivieren

Da:

Traefik bereits HTTP-01 + Let’s Encrypt übernimmt
Port 80/443 nicht direkt von Headscale genutzt wird
Doppeltes ACME häufig zu Fehlern führt

Headscale sollte keine Zertifikate selbst anfordern.

Empfohlene `config.yaml`

Pfad:

/opt/docker/volumes/headscale/config/config.yaml

Headscale - config.yml

server_url: https://82qqhpjqxz3w.duckdns.org

listen_addr: 0.0.0.0:8080

# Metriken & Debug – nur intern nutzen!
metrics_listen_addr: 127.0.0.1:9090

# gRPC nur intern / lokal
grpc_listen_addr: 127.0.0.1:50443
grpc_allow_insecure: false

noise:
  private_key_path: /var/lib/headscale/noise_private.key

prefixes:
  v4: 100.64.0.0/10
  v6: fd7a:115c:a1e0::/48
  allocation: sequential

# -------------------------------------------------
# DERP
# -------------------------------------------------
# Embedded DERP deaktiviert – wir nutzen die offiziellen Tailscale DERPs
derp:
  server:
    enabled: false

  urls:
    - https://controlplane.tailscale.com/derpmap/default

  auto_update_enabled: true
  update_frequency: 3h

disable_check_updates: false
ephemeral_node_inactivity_timeout: 30m

# -------------------------------------------------
# Datenbank
# -------------------------------------------------
database:
  type: sqlite
  debug: false

  gorm:
    prepare_stmt: true
    parameterized_queries: true
    skip_err_record_not_found: true
    slow_threshold: 1000

  sqlite:
    path: /var/lib/headscale/db.sqlite
    write_ahead_log: true
    wal_autocheckpoint: 1000

# -------------------------------------------------
# TLS – vollständig durch Traefik erledigt
# -------------------------------------------------
acme_url: ""
acme_email: ""
tls_letsencrypt_hostname: ""
tls_letsencrypt_cache_dir: ""
tls_letsencrypt_challenge_type: ""
tls_letsencrypt_listen: ""

tls_cert_path: ""
tls_key_path: ""

# -------------------------------------------------
# Logging
# -------------------------------------------------
log:
  level: info
  format: text

# -------------------------------------------------
# ACL / Policy
# -------------------------------------------------
policy:
  mode: file
  path: /etc/headscale/acl.hujson

# -------------------------------------------------
# DNS & MagicDNS
# -------------------------------------------------
dns:
  magic_dns: true
  base_domain: ztna.k42s.de
  override_local_dns: true

  nameservers:
    global:
      - 9.9.9.9
      - 149.112.112.112
      - 2620:fe::fe
      - 2620:fe::9

  search_domains: []
  extra_records: []

# -------------------------------------------------
# Unix Socket für CLI
# -------------------------------------------------
unix_socket: /var/run/headscale/headscale.sock
unix_socket_permission: "0770"

# -------------------------------------------------
# Logtail
# -------------------------------------------------
logtail:
  enabled: false

randomize_client_port: false

Änderungen & Begründungen

TLS / ACME

Punkt	Entscheidung
ACME in Headscale	deaktiviert
TLS	ausschließlich via Traefik
Challenge	HTTP-01
Vorteil	keine Port-/Zertifikatskonflikte

server_url

server_url: https://82qqhpjqxz3w.duckdns.org

muss exakt dem öffentlichen DNS-Namen entsprechen
wird von Tailscale-Clients hart verwendet
falscher Wert = Join-Probleme

Ergebnis

Headscale sauber hinter Traefik
Zero-Trust-ready
CGNAT-kompatibel
ACME-Konflikte vermieden
perfekte Basis für ACLs & OIDC

Headplane: Zentrale Verwaltung und UI für Headscale

Während Headscale selbst als robuste Control Plane im Hintergrund arbeitet, fehlt ihm bewusst eine grafische Benutzeroberfläche. Genau hier setzt Headplane an: Als moderne Web-UI ermöglicht es die komfortable Verwaltung von Users, Nodes, ACLs, DNS-Einstellungen und Policies – vollständig webbasiert und ohne CLI-Zwang.

In diesem Abschnitt richten wir Headplane so ein, dass alle relevanten Konfigurationen zentral über das Web-Interface vorgenommen werden können. Der Fokus liegt dabei auf einer klaren Benutzerführung, einer sauberen Integration in Headscale sowie einer sicheren Bereitstellung über Traefik und HTTPS.

Die folgenden Screenshots zeigen Schritt für Schritt, wie Headplane genutzt wird, um:

Benutzer und Geräte zu verwalten
Netzwerkrichtlinien (ACLs) zu pflegen
DNS- und MagicDNS-Einstellungen zu kontrollieren
den Zustand des Zero-Trust-Netzwerks transparent zu überwachen

Damit wird Headplane zur zentralen Schaltstelle für den täglichen Betrieb von Headscale – insbesondere für Administratoren, die Konfigurationen nachvollziehbar und revisionssicher über eine Oberfläche steuern möchten.

Empfohlene Headplane-Erstkonfiguration

Nach dem ersten Aufruf der Headplane-Weboberfläche dient die Erstkonfiguration dazu, Headscale betriebsbereit, sicher und wartbar aufzusetzen. Ziel ist es, die grundlegenden Strukturen festzulegen, auf denen später alle Zero-Trust-Zugriffe basieren.

Die folgenden Schritte haben sich in der Praxis bewährt.

API-Key für Erstanmeldung erstellen

https://82qqhpjqxz3w-ui.duckdns.org/admin

Docker | Headplane

Install Headplane with Docker.

Headplane

docker exec -it headscale headscale apikeys create --expiration 90d

1. Verbindung zu Headscale prüfen

Ziel: Sicherstellen, dass Headplane korrekt mit Headscale kommuniziert.

Was prüfen:

Status „Connected“ oder „Healthy“
Headscale-Version wird korrekt angezeigt
Keine Verbindungs- oder Authentifizierungsfehler

Hinweis:
Headplane nutzt die bereitgestellte Headscale-Konfiguration. Änderungen an ACLs oder DNS werden direkt an Headscale weitergereicht.

2. Benutzer (Users) anlegen

Ziel: Klare Trennung von Identitäten und Verantwortlichkeiten.

Empfohlene Struktur:

ein User pro Person oder technischer Einheit
keine gemeinsamen Accounts
sprechende Namen (z. B. admin, server, home, laptop-des-benutzers)

Zero-Trust-Gedanke:
Zugriffsrechte werden nicht über Netzwerke, sondern über Identitäten vergeben.

3. Geräte (Nodes) überprüfen und zuordnen

Nach dem ersten tailscale up melden sich Geräte automatisch bei Headscale.

Empfohlene Aktionen:

Geräten sprechende Namen geben
Nodes eindeutig einem User zuordnen
nicht benötigte oder alte Nodes deaktivieren oder löschen

Best Practice:
Geräte regelmäßig prüfen – jedes aktive Gerät ist ein potenzieller Zugriffspunkt.

4. MagicDNS & DNS-Einstellungen kontrollieren

Ziel: Einheitliche Namensauflösung innerhalb des Tailnets.

Empfohlene Einstellungen:

MagicDNS aktiv
korrekte Base-Domain (z. B. ztna.82qqhpjqxz3w.duckdns.org)
globale Resolver sauber definiert
Split-DNS nur gezielt einsetzen

Mehrwert:
Dienste sind unter konsistenten Hostnamen erreichbar – unabhängig vom Standort.

5. ACLs (Zugriffsrichtlinien) initial festlegen

Ziel: Minimale, transparente Zugriffskontrolle nach Zero-Trust-Prinzipien.

Empfohlener Startpunkt:

zunächst deny all
gezielte Freigaben pro User / Gruppe
keine pauschalen „allow all“-Regeln

Faustregel:
Jeder Zugriff muss bewusst erlaubt werden – alles andere bleibt verboten.

6. Namespaces / logische Trennung nutzen (falls vorhanden)

Falls du mehrere Umgebungen betreibst (z. B. prod, lab, home):

Empfehlung:

logische Trennung über User, ACLs oder Gruppen
keine Vermischung von Test- und Produktivsystemen
klare Namenskonventionen

7. Monitoring & Überblick behalten

Ziel: Transparenz über den Zustand des Zero-Trust-Netzwerks.

Regelmäßig prüfen:

aktive vs. inaktive Nodes
letzte Verbindungszeit
neue Geräte
Policy-Änderungen

Ergebnis der Erstkonfiguration

Nach diesen Schritten ist Headplane:

sauber strukturiert
Zero-Trust-konform
identitätsbasiert
leicht verständlich für Admins
transparent im Betrieb

Damit ist die Grundlage geschaffen, um Zugriffe gezielt zu erweitern, ohne die Sicherheit des Gesamtsystems zu gefährden.

Einleitung

Vorbereitung: DNS-Grundlage für Headscale & Tailscale

Ressourcen

Verzeichnisstruktur vorbereiten

DuckDNS Docker-Container deployen

docker-compose.yml

Konfigurationsparameter im Überblick

Empfehlung

Container starten

Ergebnis

Reverse Proxy & TLS-Basis: Traefik mit Let’s Encrypt und DuckDNS

Verzeichnisstruktur anlegen

Docker-Netzwerk erstellen (einmalig)

Traefik – docker-compose.yml

HTTP-01 Challenge + DuckDNS

Wichtig: Passwort korrekt hashen

Warum HTTP-01 statt DNS-01?

Traefik starten

Ergebnis

Headscale als Zero-Trust-Control-Plane betreiben

Headscale & Headplane – docker-compose.yml

Ergebnis

Headscale konfigurieren: Zero-Trust-Grundlagen & Reverse-Proxy-Betrieb

Wichtige Design-Entscheidung

Empfohlene config.yaml

Headscale - config.yml

Änderungen & Begründungen

TLS / ACME

server_url

Ergebnis

Headplane: Zentrale Verwaltung und UI für Headscale

Empfohlene Headplane-Erstkonfiguration

API-Key für Erstanmeldung erstellen

1. Verbindung zu Headscale prüfen

2. Benutzer (Users) anlegen

3. Geräte (Nodes) überprüfen und zuordnen

4. MagicDNS & DNS-Einstellungen kontrollieren

5. ACLs (Zugriffsrichtlinien) initial festlegen

6. Namespaces / logische Trennung nutzen (falls vorhanden)

7. Monitoring & Überblick behalten

Ergebnis der Erstkonfiguration

Empfohlene `config.yaml`