Fernwartung ohne VPN-Client bedeutet: Ihre Technikerinnen und Techniker brauchen auf dem eigenen Rechner keine installierte VPN-Software und keinen Fernwartungs-Agenten mehr. Sie öffnen einen Browser, melden sich an einem zentralen Gateway an und arbeiten direkt auf Anlage, Maschine oder Server. Möglich macht das ein clientloses Browser-Gateway wie Apache Guacamole (aktuell Version 1.6.0, veröffentlicht am 22. Juni 2025, Release Notes), das RDP, VNC und SSH vollständig im Browser darstellt. Die Verbindung zum Standort läuft im Hintergrund über einen einmalig eingerichteten WireGuard-Tunnel, nicht über einen VPN-Client pro Person.
Der Effekt ist eine andere Betriebslogik: Zugang wird zentral vergeben und zentral entzogen, jede Sitzung ist protokolliert, und es gibt keine Sammlung halb gepflegter VPN-Profile mehr, die auf Dutzenden Laptops verteilt sind.
Was "ohne VPN-Client" wirklich heißt
Klassische Fernwartung kennt zwei Spielarten, die beide schlecht skalieren. Entweder bekommt jeder Techniker einen VPN-Client mit eigenem Profil und Schlüssel pro Standort, oder auf jedes Zielgerät wird ein Agent wie TeamViewer oder AnyDesk installiert. Beides erzeugt Wildwuchs: Profile veralten, Agenten laufen unkontrolliert weiter, und beim Offboarding muss jemand daran denken, an vielen Stellen aufzuräumen.
Clientloser Zugriff dreht das um. Das Gateway ist der einzige Einstiegspunkt. Es spricht serverseitig die Fernwartungsprotokolle (RDP für Windows-Systeme, VNC für HMIs und Linux-Desktops, SSH für die Kommandozeile) und rendert die Sitzung als HTML5 im Browser (Guacamole-Handbuch). Auf dem Endgerät läuft nur der Browser, ohne Plug-in, ohne Agent, ohne lokal gespeicherten Schlüssel. Genau das meint "clientless".
Die Architektur: ein WireGuard-Tunnel, ein Browser-Gateway
Eine saubere Fernwartung ohne VPN-Client besteht aus zwei klar getrennten Schichten:
- Backend, einmalig pro Standort: Ein WireGuard-Tunnel verbindet das entfernte Netz (Maschinennetz, Anlage, IoT-Segment) verschlüsselt mit dem Gateway. WireGuard ist seit Linux-Kernel 5.6 (März 2020) fester Bestandteil des Mainline-Kernels (wireguard.com), schlank, auf moderner Kryptografie (Curve25519, ChaCha20-Poly1305) aufgebaut und damit performant und gut auditierbar. Diese Anbindung richten Sie einmal ein.
- Frontend, für das Personal: Das Browser-Gateway veröffentlicht die erreichbaren Geräte als benannte Verbindungen. Wer eine Rolle hat, sieht genau die Geräte, für die er berechtigt ist, und nichts darüber hinaus.
Der entscheidende Punkt: Die Tunnel-Komplexität bleibt im Backend. Das Personal interagiert nie direkt mit WireGuard. Mehr zur reinen Standortanbindung erklären wir auf unserer Seite zu WireGuard.
Warum clientless den VPN- und TeamViewer-Wildwuchs ablöst
| Aspekt | VPN-Client pro Techniker | Agent pro Gerät (TeamViewer/AnyDesk) | Clientloses Gateway |
|---|---|---|---|
| Verteilung / Onboarding | Profil + Schlüssel je Person und Standort | Installation auf jedem Zielgerät | Konto + Rolle, kein Software-Rollout |
| Zugang entziehen | Auf jedem Endgerät einzeln | Agent deinstallieren / sperren | Einmal zentral deaktivieren |
| Audit-Trail | Fragmentiert, pro Client | Beim Hersteller, teils begrenzt | Ein durchgängiges Protokoll |
| Angriffsfläche | Viele VPN-Endpunkte | Viele dauerhaft laufende Agenten | Ein gehärteter Einstiegspunkt |
| Datenhoheit | Eigene Infrastruktur | Hersteller-Cloud | Eigene Infrastruktur |
Der Unterschied wird im Alltag spürbar: Scheidet jemand aus oder wechselt das Projekt, ist der Zugang in Sekunden weg, ohne dass jemand zu zehn Laptops oder zwanzig Maschinen laufen muss.
Sicherheit: Rollen, kurzlebige Sessions, ein Audit-Trail
Clientloser Zugriff ist nicht automatisch sicher, er macht Sicherheit aber zentral umsetzbar. In der Praxis gehören dazu:
- Rollenbasierter Zugriff (RBAC): Jede Rolle erhält nur die Geräte und Protokolle, die sie wirklich braucht, nach dem Prinzip der minimalen Rechte. Details dazu im Artikel RBAC und Audit für Fernzugriff.
- Multi-Faktor-Authentifizierung (MFA): Am Gateway erzwungen, nicht optional auf einzelnen Clients.
- Kurzlebige Sessions: Zugriffe sind zeitlich begrenzt und laufen automatisch ab, statt dauerhaft offen zu stehen. Externe Dienstleister bekommen Zugang nur für das konkrete Wartungsfenster.
- Lückenloser Audit-Trail: Wer war wann auf welchem Gerät? Sitzungen lassen sich protokollieren und auf Wunsch aufzeichnen, was Nachvollziehbarkeit und Forensik erheblich vereinfacht.
Diese Eigenschaften zahlen direkt auf regulatorische Anforderungen ein. Das deutsche NIS2-Umsetzungsgesetz (NIS2UmsuCG) ist am 6. Dezember 2025 in Kraft getreten und verpflichtet rund 29.500 Unternehmen in 18 Sektoren (Schwelle in der Regel 50 Beschäftigte oder 10 Mio. Euro Jahresumsatz) zu Risikomanagement-Maßnahmen, darunter Zugriffskontrolle, Kryptografie und Multi-Faktor-Authentifizierung; Verstöße können mit Bußgeldern von bis zu 10 Mio. Euro geahndet werden. Auch IEC 62443 macht in der 2024er-Fassung (IEC 62443-2-1:2024) den Anlagenbetreiber dafür verantwortlich, Fernzugriff zu standardisieren, abzusichern und zu dokumentieren. Ein zentrales Gateway mit RBAC, MFA und Audit erfüllt diese Punkte deutlich leichter als verteilte VPN-Clients. Wie sich das konkret umsetzen lässt, vertiefen wir unter NIS2-konformer Fernzugriff. Dieser Beitrag ist allgemeine Information und keine Rechtsberatung.
Abgrenzung: Consumer-Tools und Hardware-Router
Zwei Alternativen begegnen einem im Feld immer wieder, und beide lösen ein anderes Problem als ein souveränes Gateway:
- Consumer- und Helpdesk-Tools (TeamViewer, AnyDesk): Schnell für den Einzelfall, aber pro Gerät installiert und über die Hersteller-Cloud geleitet. Zentrale Rollen, einheitliches Audit und Datenhoheit fehlen oder sind nur eingeschränkt möglich. Für regulierte Fernwartung über viele Standorte hinweg skaliert das nicht.
- Hardware-Router (Ewon Cosy von HMS Networks, IXON IXrouter): Je Maschine wird ein Router installiert, der nach außen in die jeweilige Hersteller-Cloud wählt; der Zugriff erfolgt über deren Portal. Das ist robust für einzelne Maschinen, bindet aber an proprietäre Hardware und eine fremde Cloud-Plattform, deren Daten häufig außerhalb der EU verarbeitet werden.
| Kriterium | TeamViewer / AnyDesk | Ewon / IXON | WireGuard + Browser-Gateway |
|---|---|---|---|
| Pro Person/Gerät nötig | Agent je Gerät | Router je Maschine | Nur Browser |
| Datenfluss | Hersteller-Cloud | Hersteller-Cloud | Eigene Infrastruktur |
| Vendor-Lock-in | Hoch | Hoch (Hardware + Cloud) | Keiner |
| Zentrale Rollen & Audit | Begrenzt | Plattformabhängig | Vollständig |
| Souveränität / DSGVO | Eingeschränkt | Eingeschränkt | Voll, aus Deutschland |
Ein WireGuard-Tunnel plus Browser-Gateway kombiniert das Beste: die einmalige, robuste Standortanbindung der Router-Welt und die zentrale, clientlose Bedienung, ohne sich an eine Consumer-Cloud zu binden.
Aus der Praxis
Genau diese Architektur betreiben wir produktiv. Für ABCO Water Systems in Australien warten wir industrielle Wasseraufbereitungsanlagen über verteilte Standorte hinweg: HMIs und Steuerungen sind nicht im Internet erreichbar, sondern hinter WireGuard-Tunneln, und das Personal arbeitet rollenbasiert im Browser. Für nextGYM verwalten wir eine IoT-Geräteflotte über dieselbe clientlose Logik, ohne pro Gerät einen Agenten auszurollen.
Wenn Sie den VPN- und TeamViewer-Wildwuchs durch einen sauberen, souveränen Zugang ersetzen wollen, bauen und betreiben wir die passende Remote-Management-Plattform für Sie, von der WireGuard-Anbindung über das Browser-Gateway bis zu Rollen und Audit. Wird für den Netzzugang ein Mesh-VPN benötigt, betreibt WZ-IT es als Managed NetBird ab 349,90 € netto im Monat; das Basispaket enthält Monitoring, Updates, Backups und Support. Lernen Sie uns unverbindlich kennen.
