Bureau à distance sans redirection de port : comment ça marche réellement

Il y a cinq ans, configurer un bureau à distance sans redirection de port était un problème de recherche. Vous vous connectiez à votre routeur, ouvriez le TCP 3389 (ou le port utilisé par votre outil), espériez que votre FAI ne le bloquait pas, et exposiez un serveur RDP sur l'internet public — ce qui explique aussi pourquoi près de la moitié des incidents de ransomware en 2023 sont passés par des RDP exposés, selon Sophos. Aujourd'hui, presque tous les outils consommateurs de bureau à distance ont totalement abandonné la redirection de ports. Cet article explique comment, quels sont les compromis, et comment GoDesk gère chaque mode de panne que vous êtes susceptible de rencontrer.

En bref : Les clients modernes de bureau à distance utilisent un serveur de rendez-vous pour présenter deux points de terminaison, puis tentent un UDP hole punching pour une connexion peer-to-peer directe. Si le perçage échoue — ce qui arrive avec les NAT symétriques, le CGNAT et certains pare-feux d'entreprise — ils basculent vers un relais. Dans tous les cas, vous ne touchez pas à votre routeur.

Pourquoi la redirection de ports est problématique en 2026

La redirection de ports avait du sens en 2005. La plupart des utilisateurs n'avaient qu'une seule couche NAT (leur routeur domestique), l'IPv4 publique était abordable, et les FAI n'intervenaient pas. Aucune de ces hypothèses ne tient aujourd'hui.

• CGNAT (Carrier-Grade NAT) : La plupart des opérateurs mobiles et un nombre croissant de fournisseurs fibre placent des milliers de clients derrière une seule IP publique. Vous ne pouvez pas rediriger un port que vous ne possédez pas. T-Mobile Home Internet, Starlink résidentiel et la plupart des hotspots cellulaires sont en CGNAT par défaut.
• Double NAT : Les passerelles fournies par les FAI exécutent souvent leur propre NAT devant votre routeur, vous laissant derrière deux couches. Une redirection sur le routeur interne ne sert à rien.
• Pare-feux d'entreprise : Politique « sortie uniquement ». Vous n'obtiendrez pas que votre service informatique ouvre le port entrant 3389 pour votre laptop.
• Transitions IPv6 : Certaines réseaux sont IPv6-only avec NAT64 ; la redirection de port IPv4 n'existe plus en tant que concept applicable.
• Sécurité : Même si vous pouvez rediriger un port, vous ne devriez pas le faire. Le balayage par force brute sur RDP est un bruit de fond constant sur l'internet public — Shodan indexe environ 4 millions de endpoints RDP exposés à tout moment.

Comment la traversée de NAT a remplacé la redirection de ports

La technique s'appelle la traversée de NAT, et elle a été standardisée dans la pile WebRTC utilisée par tous les appels vidéo basés sur navigateur. Les outils de bureau à distance réutilisent les mêmes primitives.

Étape 1 : rendez‑vous via le serveur d'ID

Quand vous lancez GoDesk, le client ouvre une connexion persistante sortante vers notre serveur d'ID (appelé hbbs dans la base de code RustDesk upstream). Il s'agit d'une connexion TCP/UDP sortante classique, que tout NAT et pare-feu autorise. Le serveur d'ID apprend votre ID d'appareil, votre IP publique réflexive et le port source que votre NAT vous a attribué. Il fait cela pour tous les clients connectés.

Quand vous saisissez l'ID de quelqu'un et cliquez sur Connect, votre client demande au serveur d'ID : "Où est l'appareil 123 456 789 ?" Le serveur répond avec le endpoint public de cet appareil et demande aux deux côtés de commencer le perçage simultanément.

Étape 2 : UDP hole punching

Les deux clients envoient maintenant des paquets UDP vers les endpoints publics de l'autre en même temps. La plupart des NAT sont endpoint-independent : une fois que vous avez envoyé un paquet vers une adresse externe, le NAT laissera revenir toute réponse sur le même port. Quand les deux côtés percutent simultanément, chaque NAT prend le paquet entrant pour une réponse légitime à un paquet sortant et le laisse passer. Une connexion peer-to-peer directe se forme — votre trafic ne transite pas par l'infrastructure GoDesk.

Cela fonctionne pour environ 85% des appariements de NAT grand public dans notre mesure sans télémétrie (nous avons testé sur les 50 FAI les plus communs en EU + US en mars 2026). C'est le même mécanisme derrière Tailscale, la découverte d'endpoints de WireGuard, et chaque appel Zoom.

Étape 3 : bascule sur relais (style TURN)

Le perçage échoue quand au moins un côté exécute un NAT symétrique — un NAT qui choisit un port externe différent pour chaque destination. Le CGNAT est presque toujours symétrique. Le Wi‑Fi d'hôtel l'est souvent aussi. Quand le P2P direct échoue après un timeout de 3 secondes, les deux clients se reconnectent via notre relais (appelé hbbr upstream). Le relais se contente de transférer des octets chiffrés entre les deux côtés — il ne peut pas les lire, car la clé de session AES-256-GCM a été négociée de bout en bout avant que le trafic n'atteigne le relais.

Le relais ajoute de la latence (typiquement 15–40 ms via nos PoPs en EU et US) et vous partagez la bande passante avec d'autres sessions relayées, mais il fonctionne derrière n'importe quelle topologie NAT qui autorise du trafic sortant de type HTTPS.

L'arbre de décision de connexion

Comparaison avec d'autres approches

Tunnels VPN (WireGuard, Tailscale, Twingate)

Les VPN résolvent le même problème à un autre niveau : ils font entrer les deux endpoints sur un réseau privé virtuel pour que n'importe quel protocole fonctionne entre eux. Tailscale utilise spécifiquement les mêmes techniques de traversée de NAT décrites ci‑dessus pour son maillage. L'inconvénient est que vous avez un second logiciel à installer, gérer et maintenir, et que vous routez tout le trafic vers la machine distante — pas seulement la session de bureau à distance. Pour un cas d'usage unique (contrôler un PC à distance), un outil avec traversée de NAT intégrée est plus simple.

RDP redirigé par port

Le RDP natif de Windows exige que vous redirigiez le TCP 3389 (ou un autre port si vous le remappez) depuis votre routeur vers la machine cible. Cela fonctionne sur un réseau domestique à NAT unique, nécessite une IP publique statique ou un DNS dynamique, vous expose au balayage de force brute RDP global, et casse immédiatement si votre FAI vous migre vers du CGNAT. La recommandation de Microsoft est de placer RDP derrière un Remote Desktop Gateway ou Azure Bastion — qui sont essentiellement des relais.

AnyDesk et TeamViewer

Les deux utilisent aussi rendezvous + hole punching + bascule sur relais. L'architecture est globalement la même que celle de GoDesk. Différences : AnyDesk et TeamViewer exécutent leurs propres protocoles propriétaires sur des clients fermés, leurs relays ne peuvent pas être auto‑hébergés, et leur tarification reflète le coût opérationnel de maintien d'une infrastructure de relais globale pour des millions d'utilisateurs. GoDesk est construit sur le fork open-source RustDesk, donc le protocole est auditable et le relais peut être auto‑hébergé si vous voulez un contrôle total.

Configuration en trois étapes

Le but de la traversée de NAT est qu'il n'y ait rien à configurer. Voici la configuration réelle sous Windows :

# 1. Download (no admin required for the portable build)
Invoke-WebRequest https://godeskflow.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.

Aucun changement de routeur. Aucune règle de pare‑feu. Pas d'IP statique. Le même flux fonctionne sur macOS (DMG), Linux (deb/rpm/AppImage) et Android (APK ou Play Store). Pour un déploiement sur de nombreuses machines, consultez notre guide plateforme Windows pour une installation MSI silencieuse.

Quand vous voudrez peut‑être encore rediriger un port

Deux cas limites :

• LAN isolé sans accès internet. Si vous auto‑hébergez le relais GoDesk sur un LAN qui ne peut pas atteindre notre serveur d'ID public, vous devez pointer les clients vers votre relais interne en utilisant le flag --relay-server et configurer votre pare‑feu pour autoriser ce trafic. Consultez notre guide d'auto‑hébergement pour la configuration complète.
• Workflows sensibles à la latence sur un réseau connu et fiable. Si vous faites du jeu ou de la production audio sur un LAN, une connexion directe sur un port fixe élimine une source de variabilité. GoDesk prend en charge un mode « direct IP » pour cela — mais ce n'est pas le mode par défaut et vous ne l'utiliseriez pas depuis l'extérieur du réseau.

Conclusion

La redirection de ports pour le bureau à distance est une solution 2010 à un problème 2026. La traversée de NAT moderne gère 99% des topologies réseau sans configuration, sans exposer de services à l'internet public et sans nécessiter d'IP statique. Téléchargez GoDesk sur les deux machines, saisissez l'ID et vous êtes connecté. Si vous voulez comprendre le modèle de sécurité sous‑jacent à la couche de traversée de NAT, lisez ensuite is remote desktop secure.

FAQ

GoDesk fonctionne‑t‑il vraiment sans aucune configuration de routeur ?
Oui. Le client n'établit que des connexions sortantes, ce que tout NAT et pare‑feu grand public autorise par défaut. Pas de règles entrantes, pas d'UPnP, pas de redirection de port.

Que se passe‑t‑il si mes deux appareils sont en CGNAT ?
Le hole punching échouera probablement et la session basculera sur notre relais. Vous verrez une latence légèrement supérieure (15–40 ms ajoutés) mais la connexion fonctionne de la même manière par ailleurs.

Le relais est‑il un risque pour la vie privée ?
Non. Le relais ne voit que des ciphertexts AES-256-GCM. La clé de session est négociée de bout en bout via X25519 entre vos deux clients avant que des données n'atteignent le relais. Nous ne pourrions pas lire votre trafic, même si nous le voulions.

Comment savoir si j'ai obtenu une connexion directe ou via relais ?
La barre d'état du client GoDesk affiche "Direct" ou "Relay" une fois la connexion établie. Vous pouvez aussi vérifier les détails de la session depuis la barre d'outils.

Puis‑je forcer GoDesk à utiliser systématiquement le relais ?
Oui — définissez relay-only = true dans la configuration du client. Utile si vous préférez une latence constante plutôt que la variabilité d'un P2P qui bascule sur relais en cours de session.