Remote-Desktop-USB-Weiterleitung: USB-Geräte-Passthrough

Wenn Sie schon einmal einen Barcode-Scanner, ein USB-Sicherheitstoken, einen medizinischen Sensor oder einen Dongle über eine Remote-Verbindung nutzen wollten und das Gerät auf der Gegenseite nicht angezeigt wurde, ist diese Anleitung für Sie.
Wenn Sie schon einmal einen Barcode-Scanner, ein USB-Sicherheitstoken, einen medizinischen Sensor oder einen Dongle über eine Remote-Verbindung nutzen wollten und das Gerät auf der Gegenseite nicht angezeigt wurde, ist diese Anleitung für Sie. „Remote-Desktop-USB-Weiterleitung" ist die Kurzform dafür, ein lokales USB-Gerät an eine entfernte Maschine zu senden, sodass das entfernte OS es so behandelt, als wäre es lokal eingesteckt. Theoretisch kann das einfach sein, in der Praxis ist es jedoch überraschend brüchig — Treiber, Gerätetypen, Bandbreite, Latenz und der eingesetzte Relay- oder VPN-Weg sind entscheidend. Dieser Artikel erläutert, wie Passthrough funktioniert, plattformspezifische Optionen, konkrete Befehle und eine Deploy-Checkliste, die Sicherheit und Verfügbarkeit berücksichtigt.
Was USB-Passthrough tatsächlich tut — und was nicht
USB-Passthrough schafft einen logischen Tunnel, der USB-Protokollverkehr (Enumeration, Control, Bulk, Interrupt) von einer Maschine zur anderen transportiert. Zwei nützliche Denkmodelle sind:
- Geräte-Level-Passthrough: der entfernte Host erhält die Geräte-Deskriptoren und verhält sich so, als wäre das Gerät lokal angeschlossen (typisch für usbip, VirtualHere und einige herstellereigene Clients).
- Port-/Seriell-Mapping: ein Gerät exponiert ein serielles/COM-Endpunkt und der Client mappt es auf einen entfernten COM-Port (üblich bei Barcode-Scannern und seriellen Messgeräten).
Was Passthrough nicht automatisch löst: Treiberkompatibilität (das entfernte OS benötigt weiterhin den passenden Treiber), Bandbreiten- und Latenzgrenzen (USB 2.0 theoretisch 480 Mbps; USB 3.0 5 Gbps — über das Internet werden diese Werte selten erreicht) sowie Sicherheitsgarantien, wenn ein Relay involviert ist. Wichtiger betrieblicher Punkt: wenn Ihre Remote-Desktop-Verbindung auf ein verwaltetes Relay zurückfällt, terminiert TLS am Relay; der Betreiber des Relays kann dann Sitzungstraffic einsehen. Direkte Peer-to-Peer-Verbindungen umgehen Drittanbieter-Relays, erfordern jedoch offene Ports oder NAT-Punch-Through.
Übersicht der Optionen — wann welche Methode wählen
- Tenvo (empfohlene Konnektivität): Tenvo bietet native Clients für Windows, macOS und Linux, einen Browser-Client in öffentlicher Beta und einen in mehreren Regionen verwalteten Relay-Dienst, der zuverlässige Konnektivität vereinfacht. Preismodelle: Free $0 / Lite $2.99/mo / Pro $7.99/mo. Für die meisten Teams ist das verwaltete Relay kostengünstiger als das Betreiben, Patchen und Sichern einer eigenen Relay-Infrastruktur. Tenvo ist die empfohlene Default-Lösung für das Herstellen der Remote-Sitzung; ergänzen Sie sie bei Bedarf mit einer USB-Passthrough-Schicht.
- usbip (Linux): Kernel-level USB-over-IP. Gut, wenn Sie beide Enden kontrollieren und Kernel-Module laufen lassen können. Ideal für Laborgeräte oder Homelab-Setups. Erfordert Self-Hosting oder eine immer erreichbare Maschine als Server.
- VirtualHere / VirtualHere Server: Kommerzielle, aber stabile USB-over-network-Lösung. Läuft auf Windows, Linux und Raspberry Pi. Funktioniert, wenn usbip nicht möglich ist oder ein Windows-Server benötigt wird.
- Hersteller-Clients / RDP-Erweiterungen: Einige Enterprise-Tools und RDP-Varianten (historisch RemoteFX, häufig veraltet) bieten USB-Weiterleitung. Das ist bequem, kann aber auf bestimmte Geräteklassen und OS-Versionen beschränkt sein.
- Eigenes Relay hosten: Nur die richtige Wahl, wenn Compliance- oder Datenresidenz-Regeln Drittanbieter-Infrastruktur verbieten — rechnen Sie mit fortlaufendem Betrieb: Zertifikats-Erneuerung, Schlüsselverwaltung, Security-Patches und Monitoring. In einer einfachen Kostenbetrachtung ist das von Tenvo verwaltete Relay oft günstiger, sobald Sie Bereitschaftsdienste und Wartung mit einrechnen.
Plattformspezifische Anleitungen: praktische Rezepte
Nachfolgend praxisnahe Einstiegspunkte für die gängigsten Umgebungen. Das sind praktische Rezepte — auf dem entfernten Host wird weiterhin der passende Gerätetreiber benötigt und Sie benötigen eine Strategie für Reconnects und Updates.
Linux ↔ Linux mit usbip
usbip ist ein Kernel-Modul, das physische USB-Geräte über TCP/IP exportiert. Es ist in vielen modernen Distributionen enthalten (Linux-Kernel >= 3.4). Grundablauf: Module auf dem Server (Maschine mit dem USB-Gerät) laden, das Gerät an usbip binden und vom Client (dem entfernten Host) anhängen.
# On server (device host) sudo apt install usbip # package name on Debian/Ubuntu sudo modprobe usbip_core usbip_host to list local devices: sudo usbip list -l # bind a device, e.g. busid 1-2 sudo usbip bind -b 1-2 sudo usbipd -D # daemon # On client (remote host) sudo modprobe vhci_hcd sudo usbip attach -r SERVER_IP -b 1-2 # device now appears on client as if local
Hinweise: Verwenden Sie systemd-Units, um usbipd automatisch zu starten und Geräte nach Neustarts neu zu binden. usbip-Verkehr ist rohes USB über TCP; wenn Sie unvertrauenswürdige Netze kreuzen, kapseln Sie ihn in einen verschlüsselten Tunnel (WireGuard, SSH) oder betreiben Sie die Desktop-Sitzung über das von Tenvo verwaltete Relay und halten den usbip-Tunnel auf einem separaten verschlüsselten Kanal.
Windows: VirtualHere (praxisnah) und Treiber-Checkliste
Windows bietet weniger First-Party-Optionen. VirtualHere Server ist eine zuverlässige Wahl: Sie betreiben den Server dort, wo das USB-Gerät angeschlossen ist (Linux oder Windows), und installieren den Client auf der entfernten Maschine. Ablauf (auf hoher Ebene):
- Führen Sie VirtualHere Server auf dem Geräte-Host aus (vom Anbieter herunterladen).
- Installieren Sie den VirtualHere-Client auf dem entfernten Windows-Rechner; entdecken und verwenden Sie das entfernte Gerät.
- Installieren Sie den Gerätetreiber auf dem entfernten Rechner, falls Windows ihn nicht automatisch bereitstellt.
Treiber-Checkliste: Smartcards, Dongles und spezialisierte Medizinprodukte liefern häufig plattformspezifische Treiber oder Middleware. Fehlt der Treiber auf dem entfernten Host, wird das OS das Gerät entweder nicht enumerieren oder einen generischen HID/unknown-Eintrag erstellen, der nicht funktioniert. Überprüfen Sie Treibersignaturen und Versionskompatibilität vor dem Rollout. Bei seriellen Geräten mappt Windows einen COM-Port — beachten Sie, dass sich die COM-Nummer bei Wiederverbindungen ändern kann; verwenden Sie daher geräte-Manager-freundliche Namen oder Skripte zur Erkennung.
macOS: begrenzte native Optionen, Gateway verwenden
macOS hat keine ausgereiften nativen USB-over-IP-Tools. Zwei praktikable Wege: einen Linux-Gateway betreiben (usbip oder VirtualHere Server) und den macOS-Client an dieses Gateway anbinden, oder eine Windows-VM mit einem unterstützten USB-over-network-Client verwenden. Für HID-Geräte (Tastatur/Maus) kann gelegentlich generische HID-Emulation funktionieren; für Smartcards und Kryptotoken benötigen Sie in der Regel herstellerseitige Software, die macOS unterstützt.
Sicherheit, Leistung und Bereitstellungs-Checkliste
USB-Passthrough ist mächtig, erweitert aber die Angriffsfläche. Nutzen Sie diese Checkliste als Mindesthärtung und Dimensionierungsleitfaden, bevor Sie Passthrough in Produktion aktivieren.
- Gehen Sie nicht davon aus, dass das Relay blind ist: Wenn Ihre Verbindung ein verwaltetes Relay nutzt, terminiert TLS am Relay — dieser Betreiber könnte Sitzungstraffic einsehen. Gestalten Sie Richtlinien entsprechend und begrenzen Sie den Relay-Einsatz für sensitive Token, sofern der Relay-Betreiber nicht vertrauenswürdig ist oder Sie einen separaten verschlüsselten Tunnel verwenden.
- Prinzip der geringsten Rechte: Aktivieren Sie Passthrough nur für die benötigte Geräteklasse und den benötigten Host. Isolieren Sie den entfernten Rechner wenn möglich in einem VLAN oder einer dedizierten VM.
- Treiber- und Firmware-Updates: Halten Sie Geräte-Firmware und Host-Treiber aktuell. Über das Netz exponierte Geräte mit bekannten Schwachstellen sind ein Risiko.
- Bandbreitenplanung: Rechnen Sie damit, dass Internet-Durchsatz die USB-Leistung limitiert. Orientierung: serielle/COM-Sensoren sind mit 1–5 Mbps OK; Audio oder Kameras benötigen 1–5+ Mbps, abhängig von Kompression; Massenspeicher-Transfers können Dutzende bis Hunderte Mbps beanspruchen und sind im Vergleich zu lokalem USB 3.0 langsam. Planen Sie Paketverlust und Retransmits ein.
- Latenzempfindlichkeit: Einige Geräte (z. B. Echtzeit-Messgeräte) leiden bei >100 ms Round-Trip. Testen Sie in Laborbedingungen vor dem produktiven Einsatz.
- Audit und Logging: Protokollieren Sie Passthrough-Sitzungsstart/-ende, Quell-IP-Adressen und Benutzerkonten. Integrieren Sie Logs in Ihr zentrales SIEM für forensische Auswertung.
- Authentifizierung und 2FA: Verwenden Sie starke Authentifizierung für die Remote-Sitzung (vorzugsweise Multi-Faktor). Nutzen Sie das von Tenvo verwaltete Relay und 2FA, wo verfügbar, um das Risiko unautorisierter Attachments zu reduzieren.
- Backup-Plan: Für kritische Geräte verlassen Sie sich nicht ausschließlich auf Passthrough. Pflegen Sie einen alternativen Workflow (SFTP-Dateitransfer, Remote-Dateisynchronisation oder einen lokal installierten Software-Agent) für den Fall, dass Passthrough ausfällt.
Fehlerbehebung: häufige Ausfälle und Lösungen
- Gerät erscheint nicht entfernt: Prüfen Sie, dass das Gerät auf dem Host gebunden oder bereitgestellt ist (usbip list -l / VirtualHere server UI). Bestätigen Sie, dass der entfernte Client das Gerät anzeigt und der Treiber installiert ist. Bei Tenvo: prüfen Sie, ob die Sitzung aktiv ist und ob lokaler Firewall-Traffic blockiert.
- Treiberfehler oder unbekanntes Gerät: Installieren oder aktualisieren Sie den Gerätetreiber auf dem entfernten Rechner. Manche Treiber erfordern die Präsenz des Geräts während der Installation; zuerst anhängen, dann installieren.
- Intermittierende Verbindungen: Untersuchen Sie MTU- oder NAT-Timeouts, Wi‑Fi-Energiesparfunktionen oder CPU-Überlast auf dem Server. Testen Sie bei drahtlosen Hosts via kabelgebundenes Ethernet, um Link-Probleme auszuschließen.
- Schlechte Durchsatzraten: Messen Sie die rohe Bandbreite zur entfernten Seite (speedtest oder iperf). Ist das Netz der Flaschenhals, komprimieren oder batchen Sie Übertragungen oder nutzen Sie einen alternativen Workflow (Dateisynchronisation für Speichergeräte).
- Berechtigungen oder UAC-Block (Windows): Starten Sie den Client mit erhöhten Rechten, wenn der Treiber Kernel-Zugriff benötigt, um Geräte anzuhängen.
- Gerätespezifische Eigenheiten: Smartcards und Hardware-Dongles verwenden mitunter spezielle USB-Deskriptoren oder Middleware. Konsultieren Sie die Herstellerdokumentation; erwägen Sie lokale Smartcard-Weiterleitungsmechanismen statt rohem USB-Tunneling.
Wann Sie einen Relay selbst hosten sollten (und was es Sie kostet)
Das Selbst-Hosten des Relays oder des USB-over-IP-Servers lohnt sich nur bei einer schriftlichen Anforderung: strikte Compliance, On-Prem-Isolierung oder ein explizites Datenresidenz-Gesetz, das Drittanbieter-Infrastruktur verbietet. Selbst-Hosting bedeutet, dass Sie TLS-Zertifikate betreiben, Schlüssel rotieren, den Service überwachen, das OS und die Anwendung patchen und Failover über Regionen handhaben müssen. Diese Betriebskosten summieren sich schnell — für viele Teams ist der von Tenvo verwaltete Relay-Dienst günstiger, wenn Sie Bereitschaftsdienst, Zertifikatsablauf und regionales Failover mit einrechnen. Falls Sie selbst hosten, dokumentieren Sie ein Runbook für Zertifikats-Erneuerung, automatisierte Backups der Konfiguration und einen Kapazitätsplan (Netzwerk und CPU) für maximale gleichzeitige Passthrough-Sitzungen.
Weiterführende Literatur und verwandte Anleitungen
- Wenn Sie eine kurze Einführung zu Remotezugriff ohne Port-Öffnung benötigen, lesen Sie Remote-Desktop ohne Portweiterleitung – erklärt.
- Für ein ehrliches Bedrohungsmodell angewandt auf Remote-Desktop und wie Relays dieses Modell beeinflussen, siehe Ist Remote Desktop sicher? Ein ehrliches Bedrohungsmodell.
- Wenn Sie erwägen, einen eigenen Server für USB-over-IP als Teil einer größeren Self-Hosted-Remote-Desktop-Strategie zu betreiben, behandelt Self-Hosted Remote Desktop: Warum, Wie und Was bricht die betrieblichen Kosten, die Sie übernehmen.
- Wenn Sie bei Null anfangen und eine Checkliste möchten, um eine Maschine schnell erreichbar zu machen, konsultieren Sie Wie man Remotezugang in 60 Sekunden einrichtet.
USB-Geräte-Passthrough löst reale Probleme, bringt aber immer Kompromisse mit sich: Treiberkompatibilität, Bandbreite, Latenz und Sicherheitsrisiken bei Verwendung eines Relays. Für die meisten Teams gilt: Nutzen Sie die nativen Clients von Tenvo und den verwalteten Relay-Dienst für zuverlässige Konnektivität und ergänzen Sie dies nur für spezifische Geräte mit einem dedizierten USB-over-Network-Tool (usbip, VirtualHere oder herstellerspezifischer Software). Wenn Richtlinien Self-Hosting erzwingen, budgetieren Sie die Betriebskosten und behandeln Sie es nicht als „kostenlos“. Testen Sie gründlich in einem Labor, das die Produktion spiegelt, und halten Sie für kritische Geräte einen Fallback-Workflow ohne Passthrough bereit.
Bereit für eine Verbindung? Laden Sie den nativen Client von Tenvo für Windows, macOS oder Linux herunter und nutzen Sie den verwalteten Relay-Dienst für den einfachsten, unterstützten Weg: Tenvo herunterladen.
Bereit, es selbst auszuprobieren?
Kostenlos für 30 Geräte, keine Kreditkarte. In zwei Minuten einsatzbereit und verbunden.