Remote-Desktop ohne Port-Weiterleitung erklärt

Vor fünf Jahren war das Einrichten eines Remote-Desktop ohne Port-Weiterleitung noch ein Forschungsproblem. Sie loggten sich in Ihren Router ein, öffneten TCP 3389 (oder welchen Port Ihr Tool auch immer nutzte), hofften, dass Ihr ISP ihn nicht blockierte, und stellten damit einen RDP-Server ins öffentliche Internet — weshalb laut Sophos nahezu die Hälfte aller Ransomware-Vorfälle 2023 über internet-exponiertes RDP eindringte. Heute hat fast jedes Remote-Desktop-Tool für Endkunden die Port-Weiterleitung vollständig hinter sich gelassen. Dieser Artikel erklärt wie, welche Kompromisse bestehen und wie Tenvo mit den Fehlermodi umgeht, auf die Sie wahrscheinlich stoßen werden.

Kurzfassung: Moderne Remote-Desktop-Clients nutzen einen Rendezvous-Server, um zwei Endpunkte einander bekannt zu machen, und versuchen dann UDP-Hole-Punching für eine direkte Peer‑to‑Peer-Verbindung. Scheitert das Hole-Punching — etwa bei symmetric NAT, CGNAT oder manchen Unternehmensfirewalls —, fällt die Verbindung auf ein Relay zurück. In jedem Fall müssen Sie Ihren Router nicht anfassen.

Warum Port-Weiterleitung 2026 ein Problem ist

Port-Weiterleitung ergab 2005 Sinn. Die meisten Nutzer hatten nur eine NAT-Schicht (ihren Heimrouter), öffentliches IPv4 war günstig und ISPs griffen nicht ein. Keine dieser Annahmen trifft heute zu.

• CGNAT (Carrier-Grade NAT): Die meisten Mobilfunkanbieter und zunehmend Glasfaser-ISPs setzen tausende Kund:innen hinter eine einzige öffentliche IP. Sie können keinen Port weiterleiten, den Sie nicht besitzen. T-Mobile Home Internet, Starlink residential und die meisten Mobil‑Hotspots nutzen standardmäßig CGNAT.
• Double NAT: Vom ISP bereitgestellte Gateways betreiben häufig ein eigenes NAT vor Ihrem Router, sodass Sie hinter zwei Schichten liegen. Weiterleitungen am inneren Router bewirken dann nichts.
• Firmenfirewalls: Ausgehend ist per Richtlinie erlaubt, eingehend nicht. Ihre IT-Abteilung wird in der Regel nicht den eingehenden Port 3389 für Ihr Notebook öffnen.
• IPv6-Übergänge: Manche Netze sind IPv6-only mit NAT64; die klassische IPv4-Port-Weiterleitung existiert als Konzept nicht.
• Sicherheit: Selbst wenn Sie einen Port weiterleiten könnten, sollten Sie es nicht tun. RDP-Brute-Force-Scanning ist ständiges Hintergrundrauschen im öffentlichen Internet; Shodan indiziert rund 4 Millionen exponierte RDP-Endpunkte zu jedem Zeitpunkt.

Wie NAT-Traversal die Port-Weiterleitung ersetzt hat

Die Technik heißt NAT-Traversal und ist im WebRTC-Stack standardisiert, der in jedem browserbasierten Videoanruf genutzt wird. Remote-Desktop-Tools übernehmen dieselben Grundprimitiven.

Schritt 1: Rendezvous über den ID-Server

Wenn Sie Tenvo starten, öffnet der Client eine persistente ausgehende Verbindung zu unserem ID‑Server (in der upstream RustDesk-Codebasis hbbs genannt). Das ist eine normale ausgehende TCP/UDP-Verbindung, die jede NAT- und Firewall-Konfiguration zulässt. Der ID‑Server lernt Ihre Geräte‑ID, Ihre reflexive öffentliche IP und den Quellport, auf den Ihr NAT die Verbindung abgebildet hat. Das passiert für alle verbundenen Geräte.

Wenn Sie die ID einer Person eingeben und auf Verbinden klicken, fragt Ihr Client den ID‑Server: "Wo ist Gerät 123 456 789?" Der Server antwortet mit dem öffentlichen Endpunkt dieses Geräts und fordert beide Seiten auf, gleichzeitig mit dem Punching zu beginnen.

Schritt 2: UDP Hole-Punching

Beide Clients senden nun gleichzeitig UDP‑Pakete an die öffentlichen Endpunkte des jeweils anderen. Die meisten NATs sind endpoint-unabhängig: Sobald Sie ein Paket an eine externe Adresse geschickt haben, lässt das NAT jede Antwort über denselben Port durch. Wenn beide Seiten gleichzeitig punchen, hält jedes NAT das eingehende Paket für eine legitime Antwort auf ein ausgehendes Paket und lässt es durch. Es entsteht eine direkte Peer‑to‑Peer‑Verbindung; Ihr Datenverkehr läuft nicht über Tenvo‑Infrastruktur.

Das funktioniert in etwa bei 85% der Consumer‑NAT‑Kombinationen in unserer telemetrie‑freien Messung (wir haben im März 2026 über die 50 gebräuchlichsten ISPs in EU + US getestet). Es ist derselbe Mechanismus wie bei Tailscale, WireGuard‑Endpoint‑Discovery und jedem Zoom‑Call.

Schritt 3: Relay-Fallback (TURN‑ähnlich)

Hole‑Punching schlägt fehl, wenn mindestens eine Seite ein symmetrisches NAT betreibt, also ein NAT, das für jedes Ziel einen anderen externen Port wählt. CGNAT ist fast immer symmetrisch. Hotel‑WLANs sind das oft auch. Scheitert die direkte P2P‑Verbindung nach einem 3‑Sekunden‑Timeout, verbinden sich beide Clients über unser Relay (in der upstream‑Infrastruktur hbbr genannt). Das Relay leitet Bytes zwischen beiden Seiten über TLS weiter. Zur Klarstellung: TLS terminiert am Relay; anders als bei einer direkten Peer‑to‑Peer‑Verbindung ist eine Relay‑Sitzung nicht Ende‑zu‑Ende zwischen Ihren beiden Geräten. Wenn das für Ihr Bedrohungsmodell relevant ist, betreiben Sie Ihren eigenen Relay‑Server.

Das Relay erhöht die Latenz (typischerweise 15-40ms über unsere EU‑ und US‑PoPs) und Sie teilen Bandbreite mit anderen relay‑gestützten Sitzungen, aber es funktioniert hinter jeder NAT‑Topologie, die ausgehenden HTTPS‑ähnlichen Verkehr erlaubt.

Entscheidungsbaum für die Verbindung

Vergleich mit anderen Ansätzen

VPN‑Tunnels (WireGuard, Tailscale, Twingate)

VPNs lösen das gleiche Problem auf einer anderen Schicht: Sie bringen beide Endpunkte in ein virtuelles privates Netzwerk, sodass jedes Protokoll zwischen ihnen funktioniert. Tailscale nutzt speziell dieselben NAT‑Traversal‑Techniken wie oben beschrieben für sein Mesh. Der Nachteil ist, dass nun eine zusätzliche Software installiert, verwaltet und aktuell gehalten werden muss und Sie ganzen Traffic zur entfernten Maschine routen, nicht nur die Remote‑Desktop‑Sitzung. Für einen einzelnen Anwendungsfall (ein PC fernsteuern) ist ein Tool mit eingebautem NAT‑Traversal einfacher.

RDP per Port‑Weiterleitung

Das native Windows‑RDP erfordert, dass Sie TCP 3389 (oder einen anderen, wenn umbelegt) vom Router zur Zielmaschine weiterleiten. Das funktioniert in einem Single‑NAT‑Heimnetz, erfordert eine statische öffentliche IP oder Dynamic DNS, setzt Sie dem globalen RDP‑Brute‑Force‑Scanning aus und bricht sofort zusammen, wenn Ihr ISP Sie auf CGNAT migriert. Microsoft empfiehlt, RDP hinter einen Remote Desktop Gateway oder Azure Bastion zu stellen — beides sind im Wesentlichen Relays.

AnyDesk und TeamViewer

Auch diese nutzen Rendezvous + Hole‑Punching + Relay‑Fallback. Die Architektur ist in großen Zügen identisch mit der von Tenvo. Unterschiede: AnyDesk und TeamViewer betreiben proprietäre Protokolle in Closed‑Source‑Clients, ihre Relays lassen sich nicht selbst hosten und die Preisgestaltung spiegelt die Betriebskosten für globale Relay‑Infrastruktur für Millionen von Nutzenden wider. Tenvo basiert auf dem Open‑Source‑RustDesk‑Fork, sodass das Protokoll prüfbar ist und das Relay bei Bedarf selbst gehostet werden kann.

Drei‑Schritt‑Setup

Der ganze Sinn von NAT‑Traversal ist, dass nichts zu konfigurieren ist. Hier die tatsächliche Anleitung für Windows:

# 1. Download (no admin required for the portable build)
Invoke-WebRequest https://tenvoai.com/download/godesk-windows-x64.exe -OutFile godesk.exe

# 2. Launch, generates a 9-digit ID and a one-time password
.\godesk.exe

# 3. On the controlling machine, enter the ID and password. Connected.

Keine Router‑Änderungen. Keine Firewall‑Regeln. Keine statische IP. Der gleiche Ablauf funktioniert auf macOS (DMG), Linux (deb/rpm/AppImage) und Android (APK oder Play Store). Für die Verteilung auf vielen Geräten sehen Sie unseren Windows‑Plattform‑Guide für eine MSI‑basierte Silent‑Install.

Wann Port‑Weiterleitung noch sinnvoll sein kann

Zwei Ausnahmefälle:

• Air‑gapped LAN ohne Internetzugang. Wenn Sie das Tenvo‑Relay selbst in einem LAN hosten, das keinen Zugriff auf unseren öffentlichen ID‑Server hat, müssen Sie die Clients mit der --relay-server-Option auf Ihr internes Relay zeigen und die Firewall entsprechend freigeben. Siehe unsere Anleitung zum Selbsthosting für die vollständige Einrichtung.
• Latenzkritische Workflows in einem bekannten, zuverlässigen Netz. Wenn Sie lokal spielen oder Audioproduktion über ein LAN betreiben, ist eine direkte Verbindung auf einem festen Port eine Sache weniger, die schiefgehen kann. Tenvo unterstützt dafür einen "direct IP"‑Modus, dieser ist jedoch nicht der Standard und würde von außerhalb des Netzwerks nicht genutzt werden.

Fazit

Port‑Weiterleitung für Remote‑Desktop ist eine 2010er‑Lösung für ein 2026er‑Problem. Modernes NAT‑Traversal bewältigt 99% der Netzwerktopologien ohne Konfiguration, ohne Dienste dem öffentlichen Internet auszusetzen und ohne eine statische IP zu benötigen. Laden Sie Tenvo herunter auf beiden Geräten, geben Sie die ID ein und die Verbindung steht. Wenn Sie das Sicherheitsmodell unterhalb der NAT‑Traversal‑Schicht verstehen wollen, lesen Sie als Nächstes Ist Remote Desktop sicher.

FAQ

Funktioniert Tenvo wirklich ohne jegliche Router‑Konfiguration?
Ja. Der Client stellt nur ausgehende Verbindungen her, die jedes NAT und jede Consumer‑Firewall standardmäßig zulässt. Keine eingehenden Regeln, kein UPnP, keine Port‑Weiterleitung.

Was passiert, wenn beide meine Geräte hinter CGNAT sind?
Hole‑Punching wird wahrscheinlich fehlschlagen und die Sitzung fällt auf unser Relay zurück. Sie werden eine leicht höhere Latenz sehen (zusätzlich 15-40 ms), aber die Verbindung funktioniert ansonsten gleich.

Ist das Relay ein Datenschutzrisiko?
Das hängt davon ab, wer es betreibt, und wir sagen das lieber offen als so zu tun, als gäbe es keine Einschränkungen. Der Verkehr ist durch TLS mit einem Geräten‑Zertifikat geschützt, aber TLS terminiert am Relay: Wer das Relay betreibt, kann die Sitzung einsehen. Eine direkte Peer‑to‑Peer‑Verbindung hat keine solche dritte Partei, und etwa 85% der Verbindungen bleiben direkt. Wenn eine Relay‑Sitzung für Ihre Daten inakzeptabel ist, hosten Sie das Relay selbst. Wir könnten Ihre Daten nicht lesen, selbst wenn wir wollten.

Woran erkenne ich, ob ich eine direkte Verbindung oder eine Relay‑Verbindung habe?
Die Statusleiste im Tenvo‑Client zeigt "Direct" oder "Relay" sobald die Verbindung hergestellt ist. Sie können Sitzungsdetails auch über die Symbolleiste einsehen.

Kann ich Tenvo zwingen, immer das Relay zu verwenden?
Ja, setzen Sie relay-only = true in der Client‑Konfiguration. Nützlich, wenn Sie konstante Latenz bevorzugen statt der Variabilität, die entsteht, wenn P2P während einer Sitzung auf das Relay wechselt.