Bureau à distance sans redirection de port expliqué

La redirection de port est obsolète pour la plupart des utilisateurs de bureau à distance ; voici ce qui l'a remplacée. UDP hole punching, STUN/TURN, et pourquoi Tenvo fonctionne derrière double NAT, CGNAT et pare-feu d'entreprise sans toucher à votre routeur.
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 bloque 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 entrés via des RDP exposés, selon Sophos. Aujourd'hui, presque tous les outils grand public de bureau à distance ont complètement abandonné la redirection de port. Cet article explique comment, quels sont les compromis, et comment Tenvo gère chaque mode de défaillance probable.
En bref : Les clients modernes de bureau à distance utilisent un serveur de rendez-vous pour présenter deux extrémités l'une à l'autre, puis tentent un UDP hole punching pour une connexion peer-to-peer directe. Si le hole punching échoue, ce qui arrive avec les NAT symétriques, le CGNAT et certains pare-feu d'entreprise, ils basculent sur un relais. Dans tous les cas, vous ne touchez jamais à votre routeur.
Pourquoi la redirection de port pose problème en 2026
La redirection de port avait du sens en 2005. La plupart des utilisateurs n'avaient qu'une seule couche NAT (leur routeur domestique), l'IPv4 publique était bon marché, et les FAI n'intervenaient pas. Aucune de ces hypothèses n'est vraie aujourd'hui.
- CGNAT (Carrier-Grade NAT) : La plupart des opérateurs mobiles et un nombre croissant de FAI 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 tous 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-feu d'entreprise : Sortant uniquement par politique. Vous n'obtiendrez pas que votre service informatique ouvre le 3389 entrant pour votre portable.
- Transitions IPv6 : Certains réseaux sont IPv6-only avec NAT64 ; la redirection de port IPv4 n'existe plus comme concept.
- Sécurité : Même quand vous pouvez rediriger un port, vous ne devriez pas. Le balayage RDP par force brute est un bruit de fond constant sur l'internet public, Shodan indexe environ 4 millions d'endpoints RDP exposés à un instant donné.
Comment la traversée de NAT a remplacé la redirection de port
La technique s'appelle la traversée de NAT, et elle est standardisée dans la pile WebRTC utilisée par tous les appels vidéo basés sur navigateur. Les outils de bureau à distance empruntent les mêmes primitives.
Étape 1 : rendez-vous via le serveur d'ID
Quand vous lancez Tenvo, le client ouvre une connexion persistante sortante vers notre serveur d'ID (appelé hbbs dans la base de code RustDesk upstream). C'est une connexion TCP/UDP sortante classique, du type que chaque NAT et pare-feu autorise. Le serveur d'ID apprend votre ID d'appareil, votre IP publique réflexive et le port source auquel votre NAT vous a mappé. Il fait ça 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 point de terminaison public de cet appareil et demande aux deux côtés de commencer le punching simultanément.
Étape 2 : UDP hole punching
Les deux clients envoient maintenant des paquets UDP vers le point de terminaison public de l'autre en même temps. La plupart des NAT sont indépendants de l'adresse de destination : une fois que vous avez envoyé un paquet vers n'importe quelle adresse externe, le NAT laissera revenir toute réponse sur le même port. Quand les deux côtés punchent simultanément, chaque NAT considère le paquet entrant comme une réponse légitime à un paquet sortant et le laisse passer. Une connexion peer-to-peer directe se forme, votre traffic ne transite par aucune infrastructure Tenvo.
Cela fonctionne pour environ 85% des appariements NAT grand public dans notre mesure sans télémétrie (nous avons testé sur les 50 FAI les plus courants en UE + US en mars 2026). C'est le même mécanisme derrière Tailscale, la découverte d'endpoint de WireGuard, et tous les appels Zoom.
Étape 3 : basculement sur relais (style TURN)
Le hole punching échoue lorsqu'au moins un côté utilise 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 relaie les octets entre les deux côtés sur TLS. Soyez clair sur ce que cela signifie : TLS se termine au relais, donc contrairement à une connexion peer-to-peer directe, une session relayée n'est pas de bout en bout entre vos deux appareils. Si cela compte pour votre modèle de menace, déployez votre propre relais.
Le relais ajoute de la latence (typiquement 15–40 ms via nos PoP EU et US) et vous partagez la bande passante avec d'autres sessions relayées, mais cela fonctionne derrière toute topologie NAT qui autorise du trafic sortant similaire à HTTPS.
L'arbre de décision de connexion
| Scénario NAT | Ce qui se passe | Surcoût de latence |
|---|---|---|
| Les deux côtés sur un NAT full-cone ou restricted-cone | P2P direct | ~0 ms |
| Un côté symétrique, l'autre endpoint-independent | P2P direct (prédiction de port) | ~0 ms |
| Les deux côtés symétriques / CGNAT | Basculement sur relais | 15-40 ms via le PoP le plus proche |
| Un côté IPv6-only, l'autre IPv4-only | Basculement sur relais | 15-40 ms |
| Pare-feu d'entreprise strict (sortant 443 uniquement) | Relais sur TLS via le port 443 | 15-40 ms |
Comparaison avec d'autres approches
Tunnels VPN (WireGuard, Tailscale, Twingate)
Les VPN résolvent le même problème à un autre niveau : ils placent les deux extrémités sur un réseau privé virtuel pour que n'importe quel protocole fonctionne entre elles. Tailscale utilise spécifiquement les mêmes techniques de traversée NAT décrites ci‑dessus pour son maillage. L'inconvénient est que vous avez maintenant un deuxième logiciel à installer, gérer et maintenir à jour, et 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 NAT intégrée est plus simple.
RDP redirigé par port
Le RDP natif de Windows nécessite 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 RDP par force brute à l'échelle mondiale, et casse immédiatement si votre FAI vous migre en CGNAT. La recommandation 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 rendez-vous + hole punching + basculement sur relais. L'architecture est globalement la même que celle de Tenvo. Différences : AnyDesk et TeamViewer exécutent leurs propres protocoles propriétaires sur des clients fermés, leurs relais ne peuvent pas être auto‑hébergés, et leur tarification reflète le coût opérationnel d'exploiter une infrastructure de relais globale pour des millions d'utilisateurs. Tenvo est construit sur le fork open source RustDesk, donc le protocole est auditable et le relais peut être auto‑hébergé si vous voulez le contrôle total.
Installation en trois étapes
Le but de la traversée NAT est qu'il n'y ait rien à configurer. Voici l'installation effective sur 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.Pas de changement de routeur. Pas de règles 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 silencieuse MSI.
Quand vous pourriez encore vouloir une redirection de port
Deux cas limites :
- LAN isolé sans accès internet. Si vous auto‑hébergez le relais Tenvo 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-serveret configurer votre pare‑feu pour autoriser ce trafic. Voir notre guide d'auto‑hébergement pour la configuration complète. - Flux sensibles à la latence sur un réseau connu et fiable. Si vous jouez ou faites de la production audio sur un LAN, une connexion directe sur un port fixe est une chose en moins qui peut mal tourner. Tenvo prend en charge un mode "IP direct" 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 port pour le bureau à distance est une solution 2010 à un problème 2026. La traversée NAT moderne gère 99% des topologies réseau sans configuration, sans exposer de services sur l'internet public et sans nécessiter d'IP statique. Téléchargez Tenvo sur les deux machines, entrez l'ID et vous êtes connecté. Si vous voulez comprendre le modèle de sécurité qui sous‑tend la couche de traversée NAT, lisez ensuite is remote desktop secure.
FAQ
Tenvo fonctionne-t-il vraiment sans aucune configuration de routeur ?
Oui. Le client n'effectue que des connexions sortantes, ce que tous les NAT et pare‑feu grand public autorisent 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 constaterez une latence légèrement supérieure (15-40 ms ajoutés) mais la connexion fonctionnera de la même manière sinon.
Le relais représente-t-il un risque pour la vie privée ?
Cela dépend de qui l'opère, et nous préférons le dire clairement plutôt que de prétendre le contraire. Le trafic est protégé par TLS avec un certificat par appareil, mais TLS se termine au relais : l'opérateur est en position de voir la session. Une connexion peer-to-peer directe n'a pas de tiers au milieu, et environ 85% des connexions restent directes. Si une session relayée est inacceptable pour vos données, auto‑hébergez le relais. Nous ne pourrions pas lire votre trafic même si nous le voulions.
Comment savoir si j'ai eu une connexion directe ou relayée ?
La barre d'état du client Tenvo 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 Tenvo à utiliser toujours le relais ?
Oui, définissez relay-only = true dans la config du client. Utile si vous voulez une latence cohérente plutôt que la variabilité d'un P2P qui bascule sur relais en milieu de session.
Prêt à l'essayer vous‑même ?
Gratuit jusqu'à 30 appareils, sans carte bancaire. Mise en route et connexion en deux minutes.