Erste Schritte
Aktivieren Sie WorksLink Access und verbinden Sie sich Schritt für Schritt mit Ihrem ersten entfernten Dienst.
Vorbereitung
| Rolle | Installationsort | Aufgabe |
|---|---|---|
| Zugriffsgateway | Auf dem Zielserver, Industrie-PC, Edge-Gerät oder Bürorechner | Stellt freigegebene Dienste lokal oder im selben LAN bereit |
| Zugriffsclient | Auf dem Techniker-PC oder Sprungserver | Ordnet autorisierte Dienste lokalen Ports zu oder öffnet SSH-, SFTP- oder Remotedesktopsitzungen |
Beide Endpunkte benötigen nur ausgehenden Zugriff auf WorksLink, ohne öffentliche IP oder Portweiterleitung. Bei eingeschränktem Netzausgang hilft Test connection im Windows-Gateway-Installer; auf anderen Plattformen workslink doctor.
Die Systemzeit darf höchstens etwa 2 Minuten abweichen, sonst lehnt der Replay-Schutz Verbindungsanfragen ab.
Erste Verbindung
- 1
Aktivieren
Ein Organisationsadministrator öffnet Secure Remote Access in der WorksLink-Konsole und aktiviert den Dienst. Vorhandene Konten und Mitgliederrechte gelten weiter.
- 2
Gateway hinzufügen
Gateway-Token erstellen. Unter Linux den Installationsbefehl der Konsole ausführen; unter Windows Adresse und Token im Installer eintragen. Das Gerät erscheint unter Gateways.
- 3
Dienste freigeben
SSH, Remotedesktop oder Datenbankports in die Freigabeliste aufnehmen. Ziele können das Gateway oder andere LAN-Geräte sein. Alle anderen Ports bleiben unerreichbar.
- 4
Clients hinzufügen
Token für Mitarbeiter erzeugen. Diese installieren den Client und tragen Adresse und Token ein; der Rechner erscheint unter Connectors.
- 5
Zugriffsregeln festlegen
Per Tags bestimmen, welche Clients auf welche Gateways und Dienste zugreifen. Vorschau prüfen und Regel speichern.
- 6
Verbinden und prüfen
Mit workslink ssh, Portzuordnung oder eigenen Werkzeugen verbinden. Administratoren sehen Sitzungen und Ereignisse unter Activity.
Gateway installieren
Windows
- workslink-access-gateway-setup.exe starten und Adresse sowie Token eintragen. Mit Test connection den Netzausgang prüfen.
- Enthält OpenSSH Server und schließt die eingehende Regel für Port 22. Mit /NOSSH lässt sich die SSH-Installation überspringen.
- Systemdienst läuft vor der Benutzeranmeldung. Grün: verbunden; Gelb: nicht registriert oder getrennt; Grau: Dienst gestoppt.
- Für Massenverteilung unbeaufsichtigt installieren:
Linux
- Nach Tokenerstellung den Befehl aus der Konsole ausführen. Das Skript erkennt die Architektur, prüft das Paket, erstellt den unprivilegierten Benutzer workslink und registriert einen systemd-Dienst.
- x86_64 und ARM64, statisch kompiliert und unabhängig von Systembibliotheksversionen.
Für weitere LAN-Geräte deren Adresse als Ziel eintragen, etwa 192.168.1.100:3306. Dort ist keine Installation nötig; sie müssen vom Gateway erreichbar und freigegeben sein.
Ohne Token installierte Gateways lassen sich lokal unter http://127.0.0.1:8586/ui/setup ohne Dienstneustart aktivieren.
Client installieren
Windows
- workslink-access-client-setup.exe starten. Standardmäßig im Infobereich; Portweiterleitungen lokal unter 127.0.0.1:8585 verwalten.
- Für Tunnel ohne Benutzeranmeldung den Windows-Dienstmodus wählen oder /SERVICE bei stiller Installation angeben.
- Die workslink-Verknüpfung im Startmenü öffnet eine vorbereitete Befehlszeile.
macOS
- Das passende .pkg für Apple Silicon oder Intel wählen. Nach Installation die Konsole über das Menüleistensymbol öffnen.
- Das Befehlszeilenwerkzeug liegt unter /Applications/workslink.app/Contents/MacOS/workslink.
Linux
- workslink-conn öffnet Tunnel bei Bedarf und beendet sich danach. Für dauerhafte Zuordnungen die erzeugte systemd-Vorlage verwenden.
- Teamfreigabe (workslink ui --mode=cloud) lauscht auf HTTPS- und Weiterleitungsports. Für Team-Sprungserver vorgesehen; erlaubte Quellen und Zertifikate vorab planen.
Verbindungsarten
Die grafische Konsole ist lokal unter 127.0.0.1:8585 erreichbar. Häufige Befehle:
| workslink list | Autorisierte Gateways, Status und Dienste auflisten |
| workslink connect <device-id> <service> | Remote-Dienst auf einen wiederverwendeten lokalen Port abbilden |
| workslink ssh <device-id> | SSH-Sitzung direkt öffnen; sftp und rdp ebenso |
| workslink rdp <device-id> | System-Remotedesktopclient für einen Windows-Zielrechner öffnen |
| workslink proxy <device-id> ssh | Als SSH ProxyCommand ohne lokalen Listener verwenden |
| workslink exec <device-id> --timeout 2m -- <command> | Remote-Befehl mit Live-Ausgabe und unverändertem Exitcode ausführen |
Für VS Code Remote-SSH und weitere SSH-Werkzeuge:
Häufige Fragen
Muss jedes Gerät die Software erhalten?
Nein. Ein Gateway kann lokale Dienste und Dienste anderer LAN-Geräte bereitstellen, sofern diese erreichbar und freigegeben sind.
Wird das gesamte Netz geöffnet?
Nein. Nur Dienste in der Freigabeliste, die eine Regel für den Client erlaubt, sind erreichbar. Alles andere wird abgewiesen; das Subnetz bleibt geschlossen.
Brauche ich eine öffentliche IP oder Portweiterleitung?
Nein. Gateway und Client verbinden sich nur ausgehend; die Dienste benötigen weder öffentliche IP noch Router-Portweiterleitung.
Was unterscheidet es vom Remotedesktop?
Remote Desktop dient zur Bildschirmanzeige und Bedienung. WorksLink Access verbindet Server, Datenbanken und interne Systeme oder führt Befehle aus. Beide nutzen dieselbe Konsole.
Wie schnell ist die Verbindung, und was passiert ohne Direktweg?
Wenn möglich erfolgt sie direkt, sonst automatisch verschlüsselt per Relay. Geschwindigkeit hängt von Netzen, Route und Ausgangsrichtlinien ab. workslink doctor hilft bei der Diagnose.
Wann wirkt ein Widerruf?
Neue Anfragen folgen sofort der Richtlinie. Online-Geräte übernehmen Änderungen meist in Sekunden und schließen Verbindungen; ohne Push oder bei Offline-Geräten erfolgt die Synchronisation beim nächsten Abruf, nach etwa zwei Minuten.
Werden Zugriffe und Befehle protokolliert?
Die Konsole erfasst Registrierung, Autorisierung, Ablehnungen, Token- und Regeländerungen sowie Trennungen. Befehlsdetails bleiben lokal auf dem Gateway; eine vollständige Sitzungsaufzeichnung ist das nicht.
Werden Ports auf meinem Rechner geöffnet?
Portzuordnungen lauschen nur auf 127.0.0.1; SSH ProxyCommand öffnet keinen lokalen Port. Der Linux-Teammodus lauscht auf HTTPS- und Weiterleitungsports und muss separat geplant werden.
Fehlerdiagnose
workslink doctor prüft diese neun Punkte und schlägt konkrete Lösungen vor:
- Berechtigungen des Konfigurationsverzeichnisses
- Integrität des lokalen Schlüsselpaars
- Konsolenkonfiguration und Rolle
- HTTPS-Erreichbarkeit der Konsole
- Zeitabweichung unter 2 Minuten
- Signaturauthentifizierung
- Syntax der Gateway-Freigabeliste
- Test der Direktverbindung
- Abruf der autorisierten Geräteliste
Noch Fragen?