Headscale: Eigenen Tailscale-Steuerserver selbst hosten

Was headscale ist

Headscale ist eine selbst gehostete Implementierung des Tailscale-Steuerungsservers. Dadurch ist der Server, der Ihr privates Netzwerk koordiniert, ein VPS, den Sie selbst besitzen. Das Projekt wird von der Community entwickelt und nicht von Tailscale Inc. betrieben. Auf jedem Rechner läuft weiterhin der offizielle tailscale-Client. Sie verweisen ihn mit einem einzigen Flag, --login-server, auf Ihren Server.

Der Steuerungsserver verwaltet die Informationen darüber, welche Geräte zum Netzwerk gehören. Er weist jedem Node eine Adresse aus 100.64.0.0/10 zu, verteilt öffentliche Schlüssel und teilt den Nodes mit, wo sie einander erreichen können. Die Tunnel bleiben WireGuard-Tunnel und werden direkt zwischen den Nodes aufgebaut. Der Netzwerkverkehr zwischen zwei Ihrer Rechner läuft nicht über den headscale-Server, sofern ein direkter Pfad aufgebaut werden kann. Andernfalls verwenden die Nodes ein Relay.

Jede headscale-Instanz stellt ein Tailnet (ein Tailscale-Netzwerk) bereit. Laut Projekt eignet sich das für die persönliche Nutzung oder eine kleine Organisation. Bei drei oder vier Rechnern ist ein einfaches WireGuard-VPN auf einem VPS, den Sie selbst besitzen weniger Software, die Sie betreiben müssen, und bietet weniger Fehlerquellen. Headscale lohnt sich, wenn Sie nicht mehr für jeden neuen Laptop von Hand einen [Peer]-Block schreiben möchten. Einen umfassenderen Vergleich der beiden Modelle finden Sie unter den Unterschieden zwischen WireGuard und Tailscale.

Was Sie vor der Installation benötigen

• Einen VPS mit Ubuntu 24.04, einer öffentlichen IPv4-Adresse und sudo-Zugriff. Wenn der Server neu ist, arbeiten Sie zuerst die ersten zehn Minuten auf einem neuen VPS durch.
• Einen DNS-A-Datensatz, der auf diese Adresse zeigt. Diese Anleitung verwendet headscale.example.com.
• Eine zweite Domain oder Subdomain für MagicDNS. Diese Anleitung verwendet tailnet.example.net. Sie darf nicht mit der Domain in server_url identisch sein.
• Einen Client zum Beitreten mit Linux, macOS, Windows, Android oder iOS.

headscale aus dem offiziellen .deb installieren

Das Projekt veröffentlicht .deb-Pakete auf seiner GitHub-Releases-Seite. Im Juli 2026 ist 0.29.3 die aktuelle Version. Prüfen Sie zuerst Ihre Architektur, da der Dateiname sie enthält.

sudo apt update
sudo apt install -y wget
dpkg --print-architecture

Der Befehl gibt amd64 auf einem gewöhnlichen x86-VPS und arm64 auf einem Ampere- oder Graviton-ähnlichen Tarif aus. Speichern Sie die Ausgabe in der folgenden Variable.

HEADSCALE_VERSION="0.29.3"
HEADSCALE_ARCH="amd64"
wget --output-document=headscale.deb \\
  "https://github.com/juanfont/headscale/releases/download/v${HEADSCALE_VERSION}/headscale_${HEADSCALE_VERSION}_linux_${HEADSCALE_ARCH}.deb"
sudo apt install -y ./headscale.deb
headscale version

Das vorangestellte ./ ist erforderlich. Ohne dieses sucht apt in Ihren Paketquellen nach einem Paket namens headscale.deb und schlägt fehl.

Das Paket legt einen headscale-Systembenutzer an, schreibt eine Standard-/etc/headscale/config.yaml und installiert eine systemd-Unit. Es startet den Dienst nicht. Das ist die richtige Reihenfolge. Die mitgelieferte Konfiguration verweist server_url auf http://127.0.0.1:8080. Das ist keine Adresse, die ein Client von Ihnen erreichen kann. Ein jetzt gestarteter Dienst wäre daher falsch konfiguriert, selbst wenn er starten würde. Wenn Sie jetzt sudo systemctl is-active headscale ausführen, wird inactive ausgegeben. Das ist erwartetes Verhalten und kein Fehler.

Konfigurieren Sie server_url, bevor Sie den Dienst starten

Bearbeiten Sie /etc/headscale/config.yaml mit sudo nano /etc/headscale/config.yaml oder wenden Sie dieselben drei Änderungen mit sed an. Bewahren Sie eine Kopie des Originals auf, da die Datei lang und ausführlich kommentiert ist und die beste Referenz für die übrigen Einstellungen darstellt.

sudo cp /etc/headscale/config.yaml /etc/headscale/config.yaml.orig
sudo sed -i 's|^server_url:.*|server_url: https://headscale.example.com|' /etc/headscale/config.yaml
sudo sed -i 's|^listen_addr:.*|listen_addr: 127.0.0.1:8080|' /etc/headscale/config.yaml
sudo sed -i 's|^  base_domain:.*|  base_domain: tailnet.example.net|' /etc/headscale/config.yaml
sudo grep -E '^(server_url|listen_addr):|^  base_domain:' /etc/headscale/config.yaml

server_url ist die Adresse, die headscale in jede Clientregistrierung schreibt. Clients verbinden sich danach dauerhaft mit genau dieser Zeichenfolge. Deshalb muss dort der öffentliche Name mit vorangestelltem https:// stehen, niemals 127.0.0.1.

listen_addr legt fest, an welche Adresse der Prozess gebunden wird. Lassen Sie diese Einstellung auf loopback. Ein Reverse-Proxy auf demselben Server beendet TLS (Transport Layer Security) und leitet die Anfragen dorthin weiter. Daher muss Port 8080 außerhalb des Servers nicht erreichbar sein.

base_domain ist das MagicDNS-Suffix, also die Domain, unter der Ihre Nodes Namen erhalten. Es muss sich um einen vollqualifizierten Domainnamen ohne abschließenden Punkt handeln. Außerdem muss es sich von der Domain in server_url unterscheiden, da die beiden Namensräume sonst kollidieren würden.

Lassen Sie den Datenbankabschnitt unverändert. Standardmäßig wird SQLite unter /var/lib/headscale/db.sqlite verwendet. Das Verzeichnis wurde vom Paket erstellt und wird von ihm verwaltet. Für ein Tailnet dieser Größe ist SQLite ausreichend.

headscale starten und den laufenden Betrieb prüfen

sudo systemctl enable --now headscale
sudo systemctl is-active headscale
curl -sS -o /dev/null -w '%{http_code}\\n' http://127.0.0.1:8080/health

is-active gibt active aus, und curl gibt 200 aus. enable --now erledigt beide Aufgaben: Es startet den Dienst und aktiviert ihn für den Start nach einem Neustart.

Wenn is-active failed ausgibt, lesen Sie das Journal mit sudo journalctl -u headscale -n 50 --no-pager. Ein Fehler in dieser Phase wird fast immer durch die Konfigurationsdatei verursacht, weil headscale die gesamte Datei analysiert, bevor es einen Socket öffnet. Eine falsche Einrückung oder ein unbekannter Schlüssel beendet den Prozess, bevor irgendetwas auf einem Port lauscht. Korrigieren Sie die Datei und führen Sie anschließend sudo systemctl restart headscale aus. Jede spätere Änderung an der Konfiguration erfordert denselben Neustart. Die Clients verbinden sich danach selbstständig erneut. Wenn systemd-Units für Sie neu sind, behandelt eigene Dienste und Timer mit systemd ausführen die hier verwendeten Befehle.

Prüfen Sie die Zustandsdateien, solange Sie in der Shell sind:

stat -c '%U %n' /var/lib/headscale/db.sqlite /var/lib/headscale/noise_private.key

Beide Zeilen beginnen mit headscale, dem vom Paket angelegten Benutzer ohne privilegierte Rechte. noise_private.key ist die Identität des Servers gegenüber seinen Clients. Behalten Sie sie bei. Wenn Sie sie löschen, erzeugt headscale eine neue Identität, und jeder Node muss sich erneut registrieren.

TLS vor headscale schalten

Clients müssen server_url über HTTPS erreichen. Caddy ist der kürzeste Weg, weil es das Zertifikat selbst anfordert und erneuert.

sudo apt install -y caddy

Ersetzen Sie /etc/caddy/Caddyfile durch den Block aus der headscale-Dokumentation:

headscale.example.com {
    reverse_proxy 127.0.0.1:8080 {
        header_up True-Client-IP {remote_host}
        header_up X-Real-IP {remote_host}
    }
}

sudo caddy validate --adapter caddyfile --config /etc/caddy/Caddyfile
sudo systemctl restart caddy
sudo systemctl is-active caddy

validate gibt adapted config to JSON aus, wenn die Datei syntaktisch korrekt ist. Eine Warnung, dass die Datei nicht formatiert ist, ist nur kosmetisch. Von Ihrem Laptop aus sollte curl -sS -o /dev/null -w '%{http_code}\\n' https://headscale.example.com/health ebenfalls 200 ausgeben. Diese einzelne Prüfung bestätigt, dass DNS, die Firewall, das Zertifikat und der Proxy zusammen funktionieren.

Hier liegt das Proxy-Detail, das oft einen ganzen Abend kostet. Die Tailscale-Steuerungsverbindung ist ein HTTP-Upgrade. Sie wird mit POST statt mit GET gestartet, und der Wert des Headers Upgrade ist tailscale-control-protocol. Caddy leitet dies ohne zusätzliche Konfiguration weiter. nginx tut das nicht. Ein nginx-Frontend benötigt daher die Upgrade-Zuordnung:

map $http_upgrade $connection_upgrade {
    default keep-alive;
    ''      close;
}

server {
    listen 443 ssl;
    server_name headscale.example.com;
    location / {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_buffering off;
        proxy_pass http://127.0.0.1:8080;
    }
}

Wenn Sie diese Zeilen weglassen, funktionieren normale Anfragen weiterhin. Deshalb gibt /health 200 zurück und alles sieht korrekt aus. Die langlebige Steuerungsverbindung wird jedoch nie hergestellt, und Ihre Knoten registrieren sich und bleiben anschließend offline. Wenn Sie nginx verwenden, behandelt Certbot unter Ubuntu 24.04 mit nginx den Teil mit dem Zertifikat.

Welche Ports in UFW geöffnet werden müssen

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Port 443 überträgt die gesamte Client-Kommunikation. Port 80 wird nur für die HTTP-Challenge von ACME (automatische Zertifikatsverwaltung) und die Weiterleitung zu HTTPS verwendet. Caddy benötigt Port 80 außerdem, um überhaupt ein Zertifikat zu erhalten.

Port 8080 bleibt geschlossen. listen_addr ist 127.0.0.1:8080. Daher erreicht der Proxy headscale über die Loopback-Schnittstelle, und es ist keine Firewall-Regel erforderlich. Wenn Sie Port 8080 für das Internet öffnen, erhalten Clients einen unverschlüsselten Steuerkanal, ohne dass dies einen Vorteil bietet. Beachten Sie, dass die meisten Anbieter in ihrem Control Panel eine zweite Firewall betreiben, die von UFW getrennt ist. Daher kann ein Port auf dem Server geöffnet und am Netzwerkrand trotzdem geschlossen sein. Grundlagen der UFW-Firewall auf einem VPS erläutert die Syntax der Regeln ausführlicher.

Benutzer und einen Preauth-Key erstellen

sudo headscale users create alice
sudo headscale users list

Der Befehl headscale ist ein Client. Er kommuniziert über den Unix-Socket unter /var/run/headscale/headscale.sock mit dem laufenden Daemon. Der Socket hat den Modus 0770 und gehört zur Gruppe headscale. Daraus folgen zwei Dinge. Der Befehl schlägt fehl, solange der Dienst gestoppt ist. Das ist ein weiterer Grund für die Reihenfolge in dieser Anleitung. Außerdem benötigen Sie sudo, sofern Sie Ihr eigenes Konto nicht zur Gruppe headscale hinzufügen.

users list gibt neben jedem Namen eine ID aus. Sie benötigen diese Zahl, weil der Key-Befehl eine numerische Benutzer-ID und keinen Namen erwartet.

sudo headscale preauthkeys create --user 1 --expiration 24h

Der Key wird nur einmal ausgegeben. Kopieren Sie ihn jetzt. Ein Preauth-Key kann nur einmal verwendet werden und ist eine Stunde lang gültig, sofern Sie nichts anderes angeben. Daher sollten Sie --expiration 24h setzen, solange Sie noch testen. Fügen Sie --reusable hinzu, um mit einem Key mehrere Rechner zu registrieren. Behandeln Sie diesen Key wie ein Passwort, weil jeder, der ihn besitzt, Ihrem Netzwerk beitreten kann.

Ihren ersten Client mit --login-server verbinden

Auf dem Rechner, den Sie dem Netzwerk hinzufügen möchten:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --login-server https://headscale.example.com --auth-key 'hskey-auth-PASTE-YOUR-KEY-HERE'
tailscale status
tailscale ip -4

tailscale ip -4 gibt die von headscale zugewiesene Adresse aus, zum Beispiel 100.64.0.1. Wechseln Sie zurück zum Server. sudo headscale nodes list zeigt den Node mit seiner ID, seinem Benutzer und seinem Online-Status.

Der Wert von --login-server muss exakt mit server_url übereinstimmen, einschließlich des Schemas und ohne abschließenden Schrägstrich. Die Werte werden als Zeichenfolgen verglichen. Bei einer Abweichung registriert sich der Client bei einer Adresse und erhält anschließend die Anweisung, mit einer anderen Adresse zu kommunizieren.

Ein Rechner, der zuvor beim gehosteten Dienst von Tailscale angemeldet war, behält diese Anmeldung. Führen Sie dort zuerst sudo tailscale logout aus. Führen Sie anschließend tailscale up mit --login-server aus.

Wenn Sie --auth-key weglassen, gibt der Client stattdessen eine URL aus. Öffnen Sie sie. Die Seite zeigt die Kennung dieses Registrierungsversuchs an. Diesen Versuch genehmigen Sie auf dem Server:

sudo headscale auth register --user alice --auth-id PASTE-THE-ID-FROM-THE-PAGE

Diese Methode eignet sich besser für Ihren eigenen Laptop. Preauth-Schlüssel sind für alles besser, was per Skript ausgeführt wird, da niemand den Vorgang überwachen muss.

DERP und die Weiterleitung des Datenverkehrs, wenn ein direkter Pfad fehlschlägt

DERP (designated encrypted relay for packets) ist der Ausweichpfad. Wenn zwei Knoten keine direkte WireGuard-Verbindung herstellen können, meist weil sich beide hinter einem strikten NAT (network address translation) befinden, senden sie die Pakete stattdessen über ein Relay. Das Relay besitzt keine Schlüssel und kann Ihren Datenverkehr daher nicht lesen. Es sieht jedoch, welche Knoten miteinander kommunizieren und wie viele Daten übertragen werden.

Beachten Sie genau, was die Standardkonfiguration bewirkt. Headscale wird mit dem Verweis auf https://controlplane.tailscale.com/derpmap/default sowie mit auto_update_enabled: true und update_frequency: 3h ausgeliefert. Dadurch gehört Ihre Steuerungsebene Ihnen, während die Relays Tailscale gehören. Für die meisten Betreiber ist das ein sinnvoller Kompromiss. Wenn das für Sie nicht infrage kommt, betreiben Sie eigene Relays.

Um ein eigenes Relay zu betreiben, setzen Sie enabled: true unter derp.server in config.yaml, starten Sie headscale neu und öffnen Sie den STUN-Port (session traversal utilities for NAT) mit sudo ufw allow 3478/udp. Die Konfigurationsdatei stellt die Anforderung eindeutig fest: server_url muss https verwenden, weil DERP TLS benötigt. Wenn Sie die Liste derp.urls leeren, werden die Relays von Tailscale aus der Zuordnung entfernt. Wenn Sie dies ohne ein funktionierendes eingebettetes Relay tun, können sich alle Knotenpaare, die keine direkte Verbindung herstellen können, überhaupt nicht verbinden.

Auf einem Client gibt tailscale netcheck die Latenz zu jeder bekannten Relay-Region aus. tailscale status kennzeichnet jeden Peer entweder als direct mit einer Adresse oder als relay mit einem Regionscode. Ein Peer im Zustand relay weist auf ein NAT-Problem hin, nicht auf ein Problem mit headscale.

Warum wird ein Node als offline angezeigt?

Der Proxy verwirft das Upgrade. Das ist der häufigste Fall. Das typische Anzeichen ist, dass alles andere ordnungsgemäß funktioniert: /health liefert 200, headscale nodes list zeigt den Node an, und der Node wird nie online angezeigt. Die Steuerungsverbindung ist ein POST mit Upgrade: tailscale-control-protocol. Ein Proxy, der diese Verbindung nicht weiterleitet, unterbricht den einzigen Kanal, der den Status des Nodes meldet. Vergleichen Sie Ihre nginx-Konfiguration mit dem obigen map-Block, oder wechseln Sie zu Caddy, um den Proxy als Ursache auszuschließen.

server_url wurde geändert, nachdem die Nodes registriert wurden. Nodes verwenden weiterhin den Wert, den sie bei der Registrierung erhalten haben. Wenn Sie ihn bearbeitet haben, führen Sie auf jedem Node sudo tailscale up --login-server https://headscale.example.com --force-reauth aus.

Der Client läuft nicht. Führen Sie auf dem Node sudo systemctl is-active tailscaled und sudo journalctl -u tailscaled -n 50 --no-pager aus. Ein Client, der Ihre Domain nicht auflösen oder erreichen kann, protokolliert dort seine erneuten Verbindungsversuche.

Der Schlüssel ist abgelaufen. Dies wird im nächsten Abschnitt behandelt.

Um die Serverseite während des Tests zu überwachen, führen Sie sudo journalctl -u headscale -f auf dem VPS aus und starten Sie tailscaled auf dem Client neu. Ein Node, der headscale erreicht, erzeugt sofort Logeinträge. Wenn keine Einträge erscheinen, kommt die Anfrage nicht an. Prüfen Sie daher DNS, die Firewall und den Proxy, bevor Sie headscale untersuchen.

Ablauf von Schlüsseln und ein Node, der Wochen später nicht mehr funktioniert

Es gibt zwei verschiedene Abläufe. Wenn Sie sie verwechseln, verlieren Sie Zeit.

Preauth-Schlüssel laufen absichtlich schnell ab. Der Standardwert beträgt eine Stunde und eine Verwendung. Wenn tailscale up den Schlüssel ablehnt, erzeugen Sie auf dem Server einen neuen Schlüssel, statt etwas auf dem Client zu bearbeiten.

Node-Schlüssel sind der langfristige Teil. Der Abschnitt node von config.yaml legt expiry: 0 fest. 0 bedeutet, dass kein Standardablauf festgelegt ist: Ein registrierter Node bleibt gültig, bis Sie ihn ablaufen lassen. Nodes mit Tags laufen unabhängig davon nie ab. Setzen Sie expiry: 180d, wenn Registrierungen automatisch ablaufen sollen. Machen Sie sich klar, was das bedeutet: Jeder Node ohne Tag benötigt dann nach diesem Zeitplan sudo tailscale up --login-server https://headscale.example.com --force-reauth. Ein headless Server, bei dem sich niemand erneut authentifiziert, verliert dadurch selbstständig den Netzwerkzugriff.

Führen Sie das manuell durch, wenn jemand einen Laptop verliert. sudo headscale nodes list zeigt Ihnen die ID. Danach meldet sudo headscale nodes expire -i 3 diesen Node ab. sudo headscale nodes delete -i 3 entfernt ihn vollständig aus dem Netzwerk.

Backups und Upgrades

/var/lib/headscale und /etc/headscale bilden zusammen den gesamten Server. Stoppen Sie den Dienst, bevor Sie die Dateien kopieren. SQLite kann noch Schreibvorgänge ausführen. Eine während der Belastung kopierte Datenbank kann inkonsistent sein.

sudo systemctl stop headscale
sudo tar czf /root/headscale-state.tgz -C /var/lib headscale
sudo tar czf /root/headscale-config.tgz -C /etc headscale
sudo systemctl start headscale
sudo chmod 600 /root/headscale-*.tgz

Verschieben Sie beide Dateien vom Server. Sie enthalten die privaten Schlüssel und alle Registrierungen. Behandeln Sie sie daher genauso sorgfältig wie den Server selbst. restic-Backups von einem VPS beschreibt, wie Sie dies regelmäßig und verschlüsselt durchführen.

Bei Upgrades wiederholen Sie die Installation: Laden Sie das neue .deb und sudo apt install ./headscale.deb herunter. Starten Sie den Dienst anschließend neu und führen Sie die Prüfungen is-active und /health erneut aus. Seit 0.29 ist der Upgrade-Pfad strikt. Das Überspringen einer Minor-Version ist nicht möglich. Ein Downgrade auf eine ältere Minor-Version ist ebenfalls nicht möglich. Führen Sie jeweils nur ein Upgrade um eine Minor-Version durch. Erstellen Sie vor jedem Schritt ein Backup. Lesen Sie außerdem zuerst die Release Notes der jeweiligen Version. In dieser Version wurde das Verhalten der ACL-Richtlinie geändert. Mehrere Konfigurationsschlüssel wurden verschoben.

FAQ

Warum startet headscale direkt nach der Installation der .deb-Datei nicht?

Das Paket installiert die Unit, lässt den Dienst jedoch gestoppt. Außerdem ist /etc/headscale/config.yaml standardmäßig eine Vorlage und keine funktionsfähige Konfiguration. Bearbeiten Sie zuerst server_url, listen_addr und base_domain. Führen Sie anschließend sudo systemctl enable --now headscale aus und bestätigen Sie das Ergebnis mit sudo systemctl is-active headscale. Wenn der Dienst weiterhin nicht startet, nennt sudo journalctl -u headscale -n 50 --no-pager das Problem. In diesem Stadium handelt es sich fast immer um einen YAML-Fehler, weil headscale die gesamte Datei analysiert, bevor es einen Port bindet.

Muss ich den normalen Tailscale-Client weiterhin auf meinen Rechnern installieren?

Ja. Headscale ersetzt nur den Control-Server. Jeder Node verwendet den offiziellen Client von Tailscale. Verweisen Sie den Client mit sudo tailscale up --login-server https://headscale.example.com auf Ihren Server. Dieses Flag ist im Standardclient vorhanden. Sie müssen daher nichts patchen oder neu kompilieren.

Läuft mein Datenverkehr über den headscale-Server?

Normalerweise nicht. Headscale koordiniert das Netzwerk und verteilt Schlüssel und Adressen. Der Datenpfad verläuft über WireGuard direkt zwischen Ihren Nodes. Der Datenverkehr nimmt nur dann einen Umweg, wenn zwei Nodes einander nicht direkt erreichen können und auf ein DERP-Relay zurückgreifen. Bei der mitgelieferten Konfiguration sind dies die öffentlichen Relays von Tailscale. Führen Sie auf einem Node tailscale status aus, um zu prüfen, ob ein bestimmter Peer direct oder über relay verbunden ist.

Warum bleibt mein Node offline, nachdem er registriert wurde?

Ein Node, der in headscale nodes list erscheint, aber nie online geht, hat normalerweise seine Control-Verbindung am Reverse-Proxy verloren. Diese Verbindung verwendet ein HTTP-Upgrade, das als POST mit dem Header Upgrade: tailscale-control-protocol gesendet wird. nginx verwirft die Verbindung, wenn Sie nicht den Block map $http_upgrade $connection_upgrade und die passenden proxy_set_header-Zeilen hinzufügen. Caddy leitet die Verbindung ohne zusätzliche Konfiguration weiter. Damit lässt sich schnell prüfen, ob der Proxy die Ursache ist.

Benötige ich für headscale einen Domainnamen und TLS?

In der Praxis ja. Clients verbinden sich mit der Zeichenfolge, die Sie in server_url eintragen. Zertifikate werden für Namen und nicht für reine IP-Adressen ausgestellt. Außerdem legt die Konfigurationsdatei fest, dass DERP TLS benötigt. Eine Domain zusammen mit Caddy ist in etwa fünf Minuten eingerichtet und stellt einen HTTPS-Endpunkt bereit, der sich selbst erneuert. Wenn Sie den Control-Server über reines HTTP betreiben, wird jede Client-Kommunikation mit ihm unverschlüsselt über das Internet übertragen.