Typische Situationen aus dem Alltag
Montagmorgen, 7:15 Uhr. Ein Kunde ruft an: Die Maschine zeigt einen Fehlercode, die Produktion steht. Der Bediener liest Ihnen die Meldung vor, aber ohne Zugriff auf die Logs können Sie nur raten. "Können Sie jemanden vorbeischicken?" — Der nächste Techniker ist drei Stunden entfernt.
Mittwochnachmittag. Sie haben ein Software-Update fertig, das einen bekannten Bug behebt. 47 Maschinen im Feld brauchen das Update. Jede einzeln besuchen? Unrealistisch. Jeden Kunden bitten, einen USB-Stick einzustecken? Fehleranfällig und langsam.
Freitagabend. Ein Techniker vor Ort braucht Unterstützung. Er könnte das Problem lösen, wenn Sie ihm über die Schulter schauen könnten — aber Sie sitzen 500 Kilometer entfernt.
Das sind keine hypothetischen Szenarien. Das ist der Alltag für OEMs, die Maschinen an Kunden ausliefern.
Was heute im Einsatz ist — und wo es hakt
Die meisten Unternehmen arbeiten mit einer Mischung aus Workarounds:
TeamViewer, AnyDesk & Co. funktionieren, aber: Lizenzkosten summieren sich, gegebenenfalls muss jemand vor Ort die Verbindung annehmen, und der Umgang fühlt sich häufig etwas sperrig an.
Kunden-VPN wäre ideal — wenn Sie es bekommen. In der Praxis bedeutet das wochenlange Abstimmung mit der IT-Abteilung, unterschiedliche Systeme bei jedem Kunden, und oft genug ein "Nein" aus Sicherheitsgründen.
Mobilfunk-Router mit statischer IP kosten monatlich, sind carrier-abhängig, und offene Ports im Internet sind ein Sicherheitsrisiko, das kein IT-Verantwortlicher gerne eingeht.
Vor-Ort-Besuche bleiben oft die letzte Option — teuer, zeitaufwändig, und bei dringenden Problemen einfach zu langsam.
Was wir brauchten: Eine Lösung, tief in unsere IoT-Lösungen integrierbar, bei der jede Maschine jederzeit erreichbar ist, ohne dass wir Ports öffnen, Kunden-IT involvieren oder auf Drittanbieter vertrauen müssen.
Warum IoT-Sicherheit nicht verhandelbar ist
Internet der Dinge (IoT) erlaubt uns, viele verschiedene Geräte und Maschinen miteinander zu verbinden und Daten über das Internet zu sammeln und auszutauschen. Dies erlaubt einen schnellen Datenaustausch durch die ganze Welt, jedoch bringt dieses System auch Risiken mit sich. Werden Daten unverschlüsselt übertragen, können sie von Angreifern abgefangen und missbraucht werden. Deswegen ist es wichtig, dass vernetzte Geräte nicht ungeschützt mit dem Internet verbunden sind, sondern durch Sicherheitsmassnahmen abgesichert werden.
Eine Möglichkeit, Geräte sicher miteinander zu verbinden, ist es, Virtual Private Networks (VPNs) zu benutzen. VPN ermöglicht es, ein virtuelles Netzwerk zu erschaffen, in dem die Kommunikation so geschützt ist, als ob sich Geräte im selben lokalen Netzwerk befinden würden. Wichtig zu beachten ist, dass sich die Geräte physikalisch nicht in einem Netzwerk befinden und die Daten trotzdem durch das öffentliche Internet übertragen werden. Wie kann es dann trotzdem sein, dass keiner auf die Daten zugreifen kann?
Der Grund dafür ist die Verschlüsselung. Die Daten werden so verschlüsselt, dass nur autorisierte Geräte innerhalb des privaten Netzwerks die Daten wieder entschlüsseln können. Dadurch entsteht ein "privates" Netzwerk über das öffentliche Internet.
Warum WireGuard?
Konkret wird das WireGuard-Protokoll verwendet. WireGuard sorgt dafür, dass die Daten zwischen zwei Geräten sicher verschlüsselt übertragen werden. Man kann sich einen digitalen Tunnel zwischen zwei Geräten vorstellen — alles was durch diesen Tunnel geschickt wird, kann von aussen niemand lesen oder verändern.
Im Vergleich zu manchen älteren VPN-Technologien ist WireGuard schneller, einfacher aufgebaut und verwendet trotzdem moderne Verschlüsselungsverfahren, was es besonders sicher und effizient macht.
Warum Headscale?
Auf Basis von WireGuard gibt es mehrere Lösungen, mit denen man ein eigenes VPN aufbauen und Geräte miteinander verbinden kann. Wir haben uns für Headscale entschieden — aus drei Gründen:
- Offen: Headscale ist Open Source. Wir können den Code einsehen, anpassen und sind nicht von einem Anbieter abhängig.
- Leichtgewichtig: Der Server läuft problemlos auf einer kleinen VM. Der Tailscale-Client auf den Endgeräten braucht minimale Ressourcen — ideal für Edge-Devices mit begrenzter Rechenleistung.
- Integrierbar: Headscale lässt sich tief in unsere IoT-Lösungen einbetten. Pre-Auth Keys ermöglichen vollautomatische Registrierung, ohne dass jemand vor Ort eingreifen muss.
Architektur-Übersicht
Die Architektur ist simpel: Ein zentraler Headscale-Server koordiniert das Mesh-Netzwerk. Alle Geräte — ob Edge-Device beim Kunden oder Techniker-Laptop — verbinden sich zu diesem Server und können dann direkt miteinander kommunizieren.
Das Entscheidende: Alle Verbindungen gehen nach aussen. Die Maschine beim Kunden baut die Verbindung zum Server auf, nicht umgekehrt. Deshalb brauchen Sie keine Ports zu öffnen und keine Firewall-Regeln beim Kunden.
Wichtig: Headscale selbst überträgt keine Nutzdaten. Der Server übernimmt nur die Koordination — also IP-Adressen verteilen, Geräte authentifizieren und Verschlüsselungsschlüssel austauschen. Sobald die Geräte im Netzwerk registriert sind, fliesst der eigentliche Datenverkehr direkt zwischen ihnen — Peer-to-Peer über WireGuard, ohne den Headscale-Server. Nur wenn keine direkte Verbindung möglich ist (z.B. bei striktem NAT auf beiden Seiten), springt ein DERP-Server als Relay ein — aber auch dann bleibt die Kommunikation Ende-zu-Ende-verschlüsselt.
Sobald das Netzwerk steht, liefert ein zentrales Dashboard eine Live-Übersicht aller verbundenen Nodes — über alle Kunden und Benutzer hinweg:
Praktische Einrichtung
Server-Setup mit Docker Compose
Der Headscale-Server läuft in einem Docker-Container auf einer Cloud-VM. Die Konfiguration ist minimal:
services:
headscale:
image: headscale/headscale:0.26.1
container_name: headscale
command: serve
restart: unless-stopped
ports:
- '80:80'
- '443:443'
volumes:
- ~/headscale/config:/etc/headscale
- ~/headscale/lib:/var/lib/headscale
- ~/headscale/run:/var/run/headscale
Die eigentliche Konfiguration erfolgt in config.yaml. Die wichtigsten Einstellungen:
# Server URL und TLS
server_url: 'https://headscale.example.com'
listen_addr: '0.0.0.0:443'
# Automatisches Let's Encrypt
tls_letsencrypt_hostname: 'headscale.example.com'
tls_letsencrypt_challenge_type: HTTP-01
tls_letsencrypt_listen: ':http'
# Embedded DERP für NAT-Traversal
derp:
server:
enabled: true
region_id: 999
region_name: 'Headscale DERP'
stun_listen_addr: '0.0.0.0:3478'
automatically_add_embedded_derp_region: true
# Magic DNS für einfache Adressierung
dns:
magic_dns: true
base_domain: devices.example.com
# OIDC für Benutzer-Authentifizierung (z.B. Azure AD)
oidc:
issuer: 'https://login.microsoftonline.com/{tenant-id}/v2.0'
client_id: '{client-id}'
client_secret: '{client-secret}'
scope: ['openid', 'profile', 'email']
Embedded DERP ist wichtig: Wenn zwei Geräte keine direkte Verbindung aufbauen können (z.B. beide hinter striktem NAT), leitet der DERP-Server den Traffic weiter — natürlich weiterhin Ende-zu-Ende-verschlüsselt.
Maschinen-Authentifizierung mit Pre-Auth Keys
Für Maschinen verwenden wir Pre-Authentication Keys. Diese werden einmalig auf dem Server generiert und dann in der Docker-Konfiguration des Edge-Geräts hinterlegt:
# Auf dem Headscale-Server: User erstellen und Key generieren
headscale users create kunde-abc
headscale preauthkeys create -u kunde-abc --reusable --expiration 99y
Auf dem Edge-Gerät läuft Tailscale als Container:
tailscale:
image: tailscale/tailscale:stable
container_name: tailscale
network_mode: 'host'
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
volumes:
- /var/lib/tailscale:/var/lib/tailscale
environment:
TS_AUTHKEY: 'your-preauth-key-here'
TS_EXTRA_ARGS: >-
--login-server=https://headscale.example.com
--accept-dns=true
TS_STATE_DIR: /var/lib/tailscale
TS_AUTH_ONCE: 'true'
restart: unless-stopped
Das Gerät meldet sich beim Start automatisch am Headscale-Server an. Kein manueller Eingriff nötig.
Benutzer-Authentifizierung mit OIDC
Techniker authentifizieren sich über den Browser — in unserem Fall via Azure AD:
# Tailscale installieren (macOS, Linux, Windows)
# Dann: Login mit eigenem Headscale-Server
tailscale up --login-server https://headscale.example.com
Ein Browserfenster öffnet sich, der Benutzer meldet sich mit seinem Azure-Account an, und ist verbunden.
Zugriffskontrolle mit ACLs
Mit Access Control Lists (ACLs) definieren Sie, wer auf was zugreifen darf. Ein Beispiel:
{
"groups": {
"group:techniker": ["[email protected]", "[email protected]"],
"group:maschinen": ["kunde-abc", "kunde-xyz"]
},
"acls": [
{
"action": "accept",
"src": ["group:techniker"],
"dst": ["group:maschinen:*"]
}
]
}
Techniker können auf alle Maschinen zugreifen. Maschinen können nicht untereinander kommunizieren. Einfach und übersichtlich.
In der Admin-Oberfläche wird das als visuelle Access Map dargestellt, die genau zeigt, welche Gruppen und Benutzer auf welche Maschinen zugreifen können:
Was Sie damit erreichen
Mit diesem Setup können Sie:
- SSH auf Edge-Geräte — Debugging und Wartung, ohne Ports zu öffnen
- Dashboards erreichen — Node-RED, Grafana, Portainer direkt im Browser
- OTA-Updates pushen — Software-Aktualisierungen über den sicheren Kanal
- Telemetrie sammeln — Daten von der Maschine abrufen, ohne sie zu exponieren
Alles über eine einzige, sichere Verbindung. Keine offenen Ports, keine Firewall-Regeln beim Kunden, keine Cloud-Abhängigkeit.
Aus Sicht des Technikers zeigt die Netzwerkansicht das eigene Gerät sowie alle erreichbaren Maschinen — mit direkten Links zu Dashboards, SSH und Management-Tools:
Was dies nicht löst
Um Erwartungen realistisch zu halten:
- Bei direkter Shopfloor-Integration sind zusätzliche Massnahmen wie Netzwerksegmentierung und Just-in-Time-Access erforderlich.
- Keine Zero-Trust-Lösung — Innerhalb des VPN vertrauen sich Geräte. ACLs helfen, aber es ist kein Zero-Trust-Modell.
- Kein Monitoring — Headscale sagt Ihnen nicht, ob ein Gerät offline ist. Dafür brauchen Sie zusätzliche Monitoring-Tools.
- Eigene Infrastruktur nötig — Sie brauchen eine VM für den Headscale-Server und müssen diese warten.
Fazit
Headscale löst ein reales Problem für OEMs und Maschinenbauer: Sichere Fernwartung ohne Kompromisse bei Sicherheit oder Kontrolle. Die Einrichtung braucht initialen Aufwand, aber danach läuft das System wartungsarm.
Wir setzen dieses Pattern bei PREKIT für alle Edge-Deployments ein. Die Kombination aus WireGuard-Sicherheit, Self-Hosting und der Tailscale-Kompatibilität macht es zur idealen Lösung für industrielle Anwendungen.
Headscale ist Open Source und auf GitHub verfügbar. Die offizielle Dokumentation finden Sie unter headscale.net. Für Fragen zur Implementierung in Ihrer Umgebung, kontaktieren Sie uns.