WireGuard zur Standortanbindung: Anlagen sicher verbinden

Verteilte Anlagen sicher fernwarten? WZ-IT baut souveräne Fernwartungs-Plattformen mit WireGuard-Backend und Browser-Gateway. Zur Remote-Management-Plattform

WireGuard verbindet verteilte Standorte und Anlagen über einen schlanken, verschlüsselten Tunnel: Jeder Standort wird zum Peer mit einem Schlüsselpaar, über AllowedIPs legen Sie fest, welche Subnetze hinter welchem Peer liegen, und der gesamte Verkehr läuft verschlüsselt über UDP. Baut der Standort den Tunnel aktiv nach außen auf, ist kein offener Inbound-Port nötig - ideal, um Maschinen und Anlagen hinter NAT und Firewall sicher anzubinden. Dieser Beitrag zeigt, wie das funktioniert und wie Sie eine Anlage Schritt für Schritt anbinden.

Inhaltsverzeichnis

• Wie WireGuard funktioniert
• Site-to-Site-Tunnel oder Full-Mesh?
• Outbound-only: Fernwartung ohne offenen Inbound-Port
• Mesh-Overlays für viele Standorte: NetBird und Headscale
• WireGuard vs. IPsec vs. OpenVPN
• Schlüsselverwaltung und Sicherheit
• Anlage anbinden: Schritt für Schritt
• WireGuard als Backend unter dem Browser-Gateway (Guacamole)
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

---

Wie WireGuard funktioniert

WireGuard ist seit Linux-Kernel 5.6 (März 2020) fester Teil des Mainline-Kernels (wireguard.com). Das Modell ist bewusst einfach: Jeder Teilnehmer ist ein Peer. Jeder Peer hat einen privaten Schlüssel, der das Gerät nie verlässt, und einen daraus abgeleiteten öffentlichen Schlüssel, den die Gegenstellen kennen. Eine Verbindung entsteht, sobald sich zwei Peers gegenseitig den öffentlichen Schlüssel eingetragen haben.

Das zentrale Konzept ist AllowedIPs (Cryptokey Routing). Pro Peer geben Sie an, welche IP-Bereiche über ihn erreichbar sind. AllowedIPs erfüllt dabei zwei Aufgaben gleichzeitig: Beim Senden entscheidet WireGuard anhand der Ziel-IP, an welchen Peer verschlüsselt wird; beim Empfang werden nur Pakete akzeptiert, deren Quell-IP zu den AllowedIPs dieses Peers passt. Für die Standortanbindung tragen Sie auf der Zentrale also das LAN-Subnetz der Anlage ein (z. B. 192.168.50.0/24) und auf der Anlage das erreichbare Subnetz der Zentrale.

Der Transport läuft ausschließlich über UDP (konventioneller Standardport 51820, frei wählbar). Es gibt keinen TCP-Fallback und keine Cipher-Aushandlung - die Kryptografie ist fest verdrahtet: Curve25519 für den Schlüsselaustausch, ChaCha20-Poly1305 für die authentifizierte Verschlüsselung, BLAKE2s zum Hashing (wireguard.com/protocol). Diese feste Wahl entfernt eine ganze Klasse von Fehlkonfigurationen.

Site-to-Site-Tunnel oder Full-Mesh?

Für die Standortanbindung gibt es zwei Grundmuster:

• Site-to-Site (Hub-and-Spoke): Ein zentraler Konzentrator in der Zentrale oder beim Hoster ist der Hub, jeder Standort ist ein Spoke. Aller Verkehr zwischen Standorten läuft über den Hub. Das ist einfach zu verwalten, gut zu auditieren und für Fernwartung meist völlig ausreichend, weil der Zugriff ohnehin zentral gebündelt sein soll.
• Full-Mesh: Jeder Standort spricht direkt mit jedem anderen. Das minimiert Latenz zwischen Standorten, erzeugt aber bei n Standorten bis zu n*(n-1)/2 Verbindungen und damit erheblichen Verwaltungsaufwand bei den Schlüsseln und AllowedIPs.

Reines, handkonfiguriertes Full-Mesh skaliert schlecht. Sobald viele Standorte ins Spiel kommen, übernimmt ein Overlay (siehe unten) das Mesh automatisch, ohne dass Sie jede Verbindung von Hand pflegen.

Outbound-only: Fernwartung ohne offenen Inbound-Port

Der entscheidende Vorteil für Industrieanlagen: WireGuard braucht am Standort keinen aus dem Internet erreichbaren Port. Der Standort-Peer baut den Tunnel aktiv nach außen zum zentralen Endpunkt auf. Da WireGuard die Gegenstelle aus eingehenden Paketen lernt (Endpoint-Roaming) und mit PersistentKeepalive (typisch 25 Sekunden) regelmäßig leere Pakete sendet, bleibt die NAT- und Firewall-Zuordnung dauerhaft offen.

Praktisch heißt das: Die Anlage steht hinter NAT, der Router muss keine Portweiterleitung haben, und in der Firewall ist nur ausgehender UDP-Verkehr erlaubt. Nur der zentrale Konzentrator (oder ein Relay) braucht einen öffentlich erreichbaren UDP-Endpunkt. Das verkleinert die Angriffsfläche am Standort drastisch und ist die Basis für Fernwartung ohne VPN-Client.

Mesh-Overlays für viele Standorte: NetBird und Headscale

Ab einer zweistelligen Zahl von Standorten wird die manuelle Pflege von Schlüsseln, Peers und AllowedIPs mühsam. Hier setzen Mesh-Overlays an, die WireGuard als Datenebene nutzen und eine Steuerungsebene (Control Plane) darüber legen:

• NetBird: Vollständig self-hostbarer WireGuard-Mesh-Stack (Open Source; Clients unter BSD-3, die Server-Komponenten Management, Signal und Relay unter AGPLv3) mit eigener Control Plane, Clients, Dashboard und Relays. Peers werden automatisch verbunden, Zugriff erfolgt regelbasiert (Zero-Trust, keine Freigabe per Default), inklusive SSO-Anbindung (z. B. Keycloak) und Audit-Trail. NAT-Traversal mit direkter Verbindung wo möglich, Relay als Fallback.
• Headscale: Quelloffene Eigenimplementierung der Tailscale-Koordinationsserver-API. Sie hosten die Steuerungsebene selbst und nutzen die offiziellen Tailscale-Clients auf den Geräten. Gut, wenn Sie das Tailscale-Ökosystem ohne dessen Cloud betreiben wollen.

Beide automatisieren Schlüsselverteilung, Routen-Verteilung und NAT-Traversal über viele Standorte hinweg - genau das, was Full-Mesh von Hand teuer macht. Mehr Hintergrund zur Datenebene auf unserer WireGuard-Expertise.

WireGuard vs. IPsec vs. OpenVPN

WireGuard ist schlank, modern und performant - die kleine Codebasis von rund 4.000 Zeilen reduziert Angriffsfläche und Auditaufwand erheblich (wireguard.com/performance). IPsec bleibt der Standard in Carrier- und Appliance-Umgebungen mit Hardware-Offload, OpenVPN punktet mit breiter Legacy-Kompatibilität und TCP-Fallback. Für neue, souverän betriebene Standortverbünde ist WireGuard in der Regel die richtige Wahl.

Schlüsselverwaltung und Sicherheit

Sicherheit steht und fällt mit den Schlüsseln:

• Pro Standort ein eigenes Schlüsselpaar. Private Schlüssel werden lokal erzeugt, verlassen das Gerät nie und liegen mit restriktiven Dateirechten (chmod 600).
• AllowedIPs eng fassen. Nur die wirklich benötigten Subnetze freigeben, nicht 0.0.0.0/0, wenn nur ein HMI erreichbar sein soll. So segmentieren Sie pro Standort.
• Rotation und Entzug. Schlüssel regelmäßig rotieren; bei Personalwechsel oder kompromittiertem Gerät den Peer sofort aus der Konfiguration entfernen. Ein Mesh-Overlay automatisiert das.
• Auditierbarkeit. Wer wann auf welche Anlage zugreift, gehört protokolliert - mehr dazu unter RBAC und Audit für Fernzugriff.

WireGuard selbst liefert moderne Kryptografie out of the box, ersetzt aber kein Sicherheitskonzept. Für regulierte Betreiber ist die Netzsegmentierung pro Standort auch im Hinblick auf die NIS2-Richtlinie relevant; Details dazu im Beitrag NIS2-konformer Fernzugriff. Dieser Beitrag ist allgemeine Information und keine Rechtsberatung.

Anlage anbinden: Schritt für Schritt

So binden Sie eine einzelne Anlage an einen bestehenden Konzentrator an:

1. Schlüssel erzeugen (auf der Anlage): wg genkey | tee privatekey | wg pubkey > publickey. Den öffentlichen Schlüssel an die Zentrale übermitteln, den privaten behalten.
2. Adressplan festlegen. Der Anlage eine Tunnel-IP aus dem Overlay-Netz zuweisen (z. B. 10.10.0.7/32) und das erreichbare LAN der Anlage bestimmen (z. B. 192.168.50.0/24).
3. Konzentrator konfigurieren. Auf dem Hub einen [Peer] mit dem öffentlichen Schlüssel der Anlage und AllowedIPs = 10.10.0.7/32, 192.168.50.0/24 ergänzen.
4. Anlage konfigurieren. Lokale [Interface] mit privatem Schlüssel und Tunnel-IP, dazu ein [Peer] für den Hub mit dessen öffentlichem Schlüssel, Endpoint = vpn.example.com:51820, AllowedIPs = 10.10.0.0/24 (plus benötigte Zentral-Subnetze) und PersistentKeepalive = 25.
5. Routing freischalten. Soll die Anlage ihr LAN bereitstellen, auf dem Anlagen-Gateway IP-Forwarding aktivieren (net.ipv4.ip_forward=1) und ggf. NAT setzen.
6. Tunnel starten und prüfen: wg-quick up wg0, dann wg show - die letzte Handshake-Zeit und Transferzähler bestätigen die Verbindung.

Bei vielen Standorten ersetzen Sie die Schritte 1, 3 und 4 durch das Onboarding im Mesh-Overlay, das Schlüssel und Routen automatisch verteilt.

WireGuard als Backend unter dem Browser-Gateway (Guacamole)

WireGuard ist die Transportschicht, nicht das Zugriffsportal. In einer souveränen Fernwartungs-Plattform liegt darüber ein Browser-Gateway wie Apache Guacamole, das RDP, VNC und SSH clientlos im Browser bereitstellt. Der Techniker meldet sich am Webportal an, das Gateway verbindet sich über den WireGuard-Tunnel zur Steuerung oder zum HMI an der Anlage - WireGuard bleibt unsichtbares Backend. Was Guacamole dabei leistet, erklärt der Beitrag Was ist Apache Guacamole?.

Dieser Aufbau trennt sauber: WireGuard kümmert sich um verschlüsselten Transport und Outbound-only-Anbindung, das Gateway um Authentifizierung, Sitzungsaufzeichnung und clientlosen Zugriff.

Unser Vorgehen bei WZ-IT

Wir bauen die WireGuard-Schicht als Fundament souveräner Fernwartungs-Plattformen: Standorte werden outbound-only angebunden, Schlüssel und Routen zentral verwaltet, der Zugriff läuft über ein auditierbares Browser-Gateway. Für verteilte Industrieanlagen mit HMI-Zugriff zeigt die Case Study ABCO Water Systems, wie das in Australien produktiv läuft; für IoT-Flotten-Rollouts steht die Case Study nextGYM. Konzeption, Aufbau und Betrieb übernehmen wir auf Wunsch komplett - im Rahmen unserer Remote-Management-Plattformen.

Weiterführende Guides

• WireGuard-Expertise - Datenebene und Betrieb
• NetBird und Headscale - Mesh-Overlays für viele Standorte
• Fernwartung ohne VPN-Client
• Was ist Apache Guacamole?

Verteilte Standorte sauber anbinden? Lernen Sie uns kennen oder sehen Sie sich unsere Remote-Management-Plattformen an.