Pare-feu et NAT, en toute simplicité.

La plupart des utilisateurs n’ont jamais à toucher un réglage de pare-feu pour utiliser Remio. L’application repose sur la même technologie de connexion qui permet aux applications d’appel vidéo de fonctionner derrière des routeurs domestiques, le Wi-Fi d’un hôtel et des VPN d’entreprise — elle trouve le chemin toute seule. Mais pour le petit nombre d’utilisateurs sur des réseaux verrouillés où le comportement par défaut se fige, cette page est la référence unique : ce que Remio envoie réellement sur le réseau, ce qu’il faut autoriser sur le pare-feu, comment lire les diagnostics en session et ce qu’il faut dire à l’informatique.

Vue d’ensemble

Remio utilise une approche par couches pour connecter un client à un hôte. Il essaie d’abord le chemin le plus rapide, puis se replie en douceur si nécessaire. Il y a trois chemins possibles, dans cet ordre de préférence :

1. Direct sur le même réseau — client et hôte sur le même Wi-Fi ou LAN. Les images circulent de point à point. Environ 8 ms de latence de traitement ; le reste est le rythme de rafraîchissement propre à votre écran. C’est ce que vous obtenez à la maison, dans un réseau de bureau unique, ou via Tailscale/WireGuard.
2. Direct à travers Internet (pair à pair) — client et hôte sur des réseaux différents, mais chacun capable d’établir une connexion UDP sortante. Les deux extrémités échangent leurs adresses publiques via le serveur de connexion de Remio, puis s’envoient le média directement. 10 à 40 ms de latence supplémentaire selon la géographie.
3. Repli par relais — quand l’UDP est bloqué ou que le NAT est trop restrictif pour un chemin direct, les deux extrémités se connectent en sortie à un serveur relais (le réseau mondial de Cloudflare, turn.cloudflare.com) — en UDP quand c’est possible, en TCP ou TLS sur le port 443 quand l’UDP est bloqué — et le relais transmet le média chiffré entre elles. 30 à 80 ms de latence supplémentaire. Fonctionne partout où HTTPS fonctionne.

Vous ne choisissez pas le chemin manuellement. Remio sonde les trois simultanément au début de chaque session et utilise le plus rapide qui aboutit. Si le réseau change en cours de session (vous passez du Wi-Fi du bureau à la 4G), Remio sonde à nouveau et change de chemin sans interrompre la session.

Comment une session Remio traverse un pare-feu

Dès l’instant où vous touchez Se connecter dans le client, voici la séquence :

1. TLS sortant vers le serveur de connexion. Le client et l’hôte ouvrent chacun un WebSocket de longue durée vers relay.remio.net sur le port 443. Il transporte les échanges de jumelage, l’échange offre/réponse et un faible volume de trafic de contrôle pendant toute la durée de la session. Aucune donnée d’écran ou de saisie n’y transite jamais. C’est du HTTPS standard — tous les pare-feu d’entreprise le laissent passer.
2. Sondage du réseau. Chaque extrémité utilise le service STUN public pour découvrir sa propre adresse publique (l’adresse que voit le reste d’Internet). Elle demande ensuite au serveur de connexion des identifiants de courte durée pour le relais (turn.cloudflare.com), au cas où le sondage échouerait.
3. Course des chemins. Les deux extrémités essaient simultanément l’UDP direct, l’UDP direct via les adresses découvertes par STUN, et le relais TLS. La combinaison qui aboutit et répond la première l’emporte. La plupart des réseaux domestiques choisissent l’UDP direct en 200 ms ; les réseaux restreints retombent sur le relais TLS en environ 2 secondes.
4. Flux média chiffré. Une fois le chemin choisi, chaque image vidéo, chaque frappe, chaque échantillon audio est chiffré de bout en bout et envoyé par le chemin retenu. Même sur le chemin par relais, le nœud relais ne voit que du texte chiffré.

Tout ce processus vous est invisible — le client affiche simplement « Connecté ». Mais comprendre la séquence permet de comprendre les règles de pare-feu de la section suivante.

Ce qu’il faut autoriser sur le pare-feu

Pour les équipes informatiques qui rédigent une politique de pare-feu, voici la liste complète du trafic sortant que génère Remio. Aucune règle entrante n’est jamais nécessaire.

# Règles sortantes — Remio Client et Remio Host

# Requis — établissement de la connexion (signalisation uniquement, pas de média)
ALLOW  TCP/443    ->  relay.remio.net           (WebSocket TLS)

# Requis — repli par relais (média quand aucun chemin direct n’existe)
ALLOW  TCP/443    ->  turn.cloudflare.com       (TURN sur TLS — fonctionne quand l’UDP est bloqué)
ALLOW  UDP/3478   ->  turn.cloudflare.com       (TURN sur UDP — facultatif, préféré)
ALLOW  UDP/443    ->  turn.cloudflare.com       (TURN sur UDP — facultatif)

# Fortement recommandé — active le pair à pair direct (latence plus faible)
ALLOW  UDP        ->  any (ports élevés 32768-65535)

# Facultatif — utilisé uniquement pour la découverte initiale de l’adresse
ALLOW  UDP/3478   ->  stun.cloudflare.com
ALLOW  UDP/19302  ->  stun.l.google.com

# Non requis, jamais utilisé
DENY   any inbound                              (aucun trafic entrant n’est jamais nécessaire)

Si vous ne pouvez autoriser que le strict minimum, autorisez le port TCP 443 sortant vers relay.remio.net et vers turn.cloudflare.com — ces deux règles suffisent pour que Remio fonctionne de bout en bout, simplement par le chemin du relais plutôt qu’en direct. Les sessions restent chiffrées et diffusées en pleine qualité ; la latence est le seul prix à payer.

Scénarios courants de réseaux d’entreprise

Les configurations de pare-feu du monde réel couvrent un large éventail. Voici à quoi s’attendre dans chaque cas.

Sortant autorisé par défaut (la plupart des petits bureaux, réseaux domestiques)

Le pare-feu laisse sortir tout le TCP et l’UDP sortants, en bloquant seulement certaines plages malveillantes. Remio trouve un chemin UDP direct en une seconde et s’y tient. La latence est celle de votre aller-retour Internet, plus 3 à 5 ms de surcharge Remio. Vous voyez Direct dans l’indicateur de type de connexion.

UDP sortant bloqué (entreprises de taille moyenne, écoles)

Le pare-feu autorise le TLS et une poignée de protocoles courants, mais bloque l’UDP sortant en bloc pour éviter les abus du pair à pair. Le sondage UDP direct de Remio échoue, celui du relais TLS-443 réussit, et la session s’établit par le chemin du relais en environ 2 secondes. L’indicateur de type de connexion affiche Relais. La latence augmente de 30 à 80 ms selon votre distance au nœud relais le plus proche. Le streaming, le son, le clavier et la saisie fonctionnent de la même façon.

Proxy à inspection TLS (grandes entreprises, finance, santé)

Le pare-feu déchiffre chaque connexion TLS sortante, inspecte le contenu, puis rechiffre avant de transmettre. C’est le cas le plus délicat. Deux choses peuvent mal tourner :

• Le proxy ne reconnaît pas le flux de longue durée de type média qu’utilise Remio, et soit l’abandonne après un court délai, soit le bride au point de le rendre inutilisable.
• Le proxy supprime des parties de la poignée de main de connexion qu’il ne comprend pas, laissant Remio bloqué.

La solution consiste à ajouter relay.remio.net et turn.cloudflare.com à la liste d’exclusion de l’inspection TLS du proxy. Tous les grands proxys d’entreprise (Zscaler, Palo Alto, Cisco Umbrella, Check Point, Forcepoint) prennent en charge l’exclusion par domaine. Le trafic continue de traverser le pare-feu de l’entreprise — il n’est simplement pas déchiffré au passage. Les équipes informatiques ajoutent généralement des exclusions pour les applications de visioconférence (Zoom, Teams) pour la même raison ; Remio rentre dans le même schéma.

Portail captif / Wi-Fi d’hôtel

De nombreux hôtels et aéroports utilisent un portail captif qui bloque tout le trafic sortant tant que vous n’avez pas accepté les conditions. Une fois authentifié, la plupart autorisent le HTTPS normal, ce qui signifie que le chemin par relais de Remio fonctionne. L’UDP est aléatoire — certains portails continuent de bloquer l’UDP même après la connexion. Si une session paraît lente sur le Wi-Fi d’un hôtel, vérifiez l’indicateur — il affiche presque toujours Relais. Il n’y a rien à corriger ; c’est le mode attendu sur ces réseaux.

NAT de niveau opérateur sur les réseaux mobiles

Les connexions 4G/5G se trouvent souvent derrière plusieurs couches de NAT exploitées par l’opérateur, ce qui complique le pair à pair direct. Remio gère cela de façon transparente — l’UDP direct fonctionne généralement dans un sens (le client mobile qui atteint l’hôte), et le chemin par relais est toujours disponible en repli. Les performances en 4G/5G sont généralement excellentes.

Vérifier le chemin de connexion

Chaque client Remio affiche le chemin de connexion retenu dans la surcouche de statistiques en session. Ouvrez-la depuis la barre d’outils — l’icône est un petit pictogramme de diagramme en barres. Vous verrez :

• Connexion — Direct signifie pair à pair en UDP. Latence la plus faible. Les images circulent directement de l’hôte au client, sans saut intermédiaire.
• Connexion — Relais signifie que le trafic est acheminé par le relais (turn.cloudflare.com). Ajoute 30 à 80 ms de latence. Toujours chiffré de bout en bout — le relais ne voit que du texte chiffré.
• Connexion — LAN apparaît quand les deux extrémités sont sur le même réseau local. Environ 8 ms de latence de traitement (le reste est le rythme de rafraîchissement propre à votre écran), sans aller-retour Internet.

Si vous vous attendez à Direct mais voyez Relais, le réseau sur lequel vous êtes bloque l’UDP quelque part sur le chemin. La session fonctionne quand même, simplement avec de la latence en plus. Sur un réseau que vous contrôlez (votre routeur domestique), vérifiez les réglages de QoS et tous les interrupteurs de « mode jeu », qui perturbent parfois la redirection UDP.

Ce que le relais peut et ne peut pas voir

Une inquiétude courante sur le chemin par relais concerne la confidentialité : si mon écran passe par un serveur relais, quelqu’un peut-il le voir là-bas ? Non. Voici pourquoi :

• Chiffrement de bout en bout. Chaque image, chaque frappe, chaque échantillon audio est chiffré avec une clé de session dérivée lors de la poignée de main. Seuls le client et l’hôte détiennent la clé. Le relais transmet du texte chiffré.
• Pas de séquestre de clés. Les serveurs de Remio ne voient ni ne stockent jamais les clés de session. Même avec un accès complet aux journaux du relais et un contrôle physique des serveurs relais, Remio ne peut déchiffrer aucune session d’utilisateur — passée, présente ou future.
• Rien de lisible à journaliser. Le relais ne manipule jamais que des paquets chiffrés, et le serveur de connexion propre à Remio (relay.remio.net) ne transporte que des messages d’établissement — jamais d’écran, de son ou de saisie.
• Le contournement de l’inspection TLS de l’entreprise fonctionne aussi. Comme le média est chiffré à une couche au-dessus du TLS (le chiffrement a lieu avant que le TLS n’enveloppe le paquet pour le relais), un proxy TLS d’entreprise qui déchiffre le TLS externe ne voit encore que la charge utile interne chiffrée. Aucun équipement intermédiaire ne peut lire votre écran.

Pour toute l’histoire du chiffrement, voir Sécurité & chiffrement.

Dépanner les problèmes de connexion

• « La connexion échoue sur le Wi-Fi de l’entreprise mais fonctionne à la maison » — l’UDP est bloqué en sortie et le chemin par relais TLS est lui aussi bloqué ou altéré. Demandez à l’informatique d’autoriser le port TCP 443 sortant vers relay.remio.net et turn.cloudflare.com, et, s’il y a un proxy à inspection TLS, d’ajouter ces deux mêmes noms d’hôte à sa liste d’exclusion. Cela débloque le chemin par relais ; les sessions fonctionnent alors de bout en bout.
• « La latence est bien plus élevée que prévu sur le réseau du bureau » — la connexion passe probablement par le relais (vérifiez l’indicateur en session). Les chemins par relais ajoutent 30 à 80 ms. Si l’informatique peut ouvrir l’UDP sortant, Remio passera automatiquement au chemin direct et la latence baissera.
• « La connexion s’établit mais le flux se fige après quelques secondes » — typique d’un proxy à inspection TLS qui autorise la poignée de main initiale mais coupe les flux de longue durée. Vérifiez dans les journaux de l’informatique si le proxy interrompt relay.remio.net ou turn.cloudflare.com, et ajoutez des exclusions pour les deux.
• « Les autres applications vidéo fonctionnent, seul Remio échoue » — presque toujours une inspection TLS ou une inspection approfondie des paquets qui altère la poignée de main. La solution est la même : demandez à l’informatique d’ajouter relay.remio.net et turn.cloudflare.com à la liste d’exclusion de l’inspection.
• « Parfois ça marche, parfois ça reste bloqué sur “Connexion en cours” » — résolution DNS instable pour relay.remio.net, ou filtre DNS d’entreprise bloquant le serveur de connexion. Essayez nslookup relay.remio.net depuis la même machine — il devrait renvoyer une IP en moins d’une seconde. S’il expire ou échoue, le DNS est le goulot d’étranglement.
• « Le bouton Se connecter ne fait rien — pas d’erreur, pas de progression » — le port 443 sortant est entièrement bloqué. C’est inhabituel mais cela arrive sur des réseaux très restreints. Testez en chargeant https://relay.remio.net/health dans un navigateur ; il devrait renvoyer une courte réponse d’état. Si le navigateur ne peut pas non plus l’atteindre, le pare-feu bloque complètement le HTTPS sortant vers cet hôte.
• « Le client VPN perturbe Remio quand il se connecte » — certains agents VPN capturent tout le trafic, média compris, ce qui provoque des saccades. Essayez d’exclure relay.remio.net et turn.cloudflare.com du tunnel si votre VPN prend en charge le tunnel fractionné.

Avancé — verrouiller encore davantage

Si votre équipe de sécurité a besoin de la liste d’autorisation la plus stricte possible, voici le minimum qui permet encore à Remio de fonctionner de bout en bout :

# Liste d’autorisation minimale viable du pare-feu
# Permet uniquement le fonctionnement en mode relais (latence ~30-80 ms)

OUTBOUND TCP/443   ->  relay.remio.net          # établissement de la connexion
OUTBOUND TCP/443   ->  turn.cloudflare.com      # relais (TURN sur TLS)

# Ajouter ces lignes débloque le pair à pair direct (3-5 ms en LAN, 10-40 ms en WAN)
OUTBOUND UDP/3478  ->  stun.cloudflare.com      # découverte de l’adresse publique
OUTBOUND UDP/19302 ->  stun.l.google.com        # découverte de l’adresse publique (redondance)
OUTBOUND UDP       ->  any (32768-65535)        # chemin média direct

Les deux premières lignes suffisent à elles seules pour que l’application fonctionne — toutes les autres lignes sont des optimisations de latence. Si vous voulez à la fois la sécurité maximale et la latence la plus faible, autorisez les cinq.

Questions sur le pare-feu et le NAT

Remio exige-t-il d’ouvrir des ports entrants sur mon pare-feu ?

Non. Remio Client et Remio Host n’établissent que des connexions sortantes. Il n’y a rien à ouvrir sur votre routeur ni dans les règles entrantes de votre pare-feu. Si votre réseau autorise le trafic web sortant normal — charger des sites web, utiliser une application de messagerie — Remio fonctionne.

Quels ports Remio utilise-t-il ?

TCP 443 sortant vers relay.remio.net pour l’établissement de la connexion, et du trafic sortant vers le relais (turn.cloudflare.com) quand aucun chemin direct n’existe : UDP 3478 ou 443 quand c’est possible, TCP ou TLS sur le port 443 quand l’UDP est bloqué. Le média pair à pair direct utilise de l’UDP sortant sur des ports élevés aléatoires ; la découverte de l’adresse publique utilise UDP 3478 (stun.cloudflare.com) et UDP 19302 (stun.l.google.com). Aucun port entrant n’est requis d’aucun côté.

Remio fonctionne-t-il sur les réseaux d’entreprise qui bloquent l’UDP ?

Oui. Quand l’UDP est bloqué, Remio se rabat automatiquement sur le relais du média en TLS sur le port 443 — le même port que celui qu’utilise votre navigateur pour le HTTPS. Les connexions mettent une fraction de seconde de plus à s’établir et ajoutent environ 30 à 80 ms de latence, mais la session fonctionne de bout en bout. Il n’y a aucun réglage à basculer — le repli se fait de façon transparente.

Mon équipe informatique peut-elle inspecter le trafic de Remio ?

Non. Tout le média de session est chiffré de bout en bout — votre écran ne touche jamais nos serveurs, et même le relais ne voit que du texte chiffré. Même lorsque le trafic passe par le relais sur le port 443, le relais ne transmet que des paquets chiffrés — il ne peut lire ni le contenu de l’écran, ni les frappes, ni aucune autre donnée. Les proxys d’inspection TLS d’entreprise ne peuvent pas non plus voir à l’intérieur du flux, car le média est chiffré à une couche au-dessus du TLS.

Pourquoi ma connexion fonctionne-t-elle à la maison mais échoue-t-elle au bureau ?

Les réseaux d’entreprise bloquent fréquemment l’UDP en totalité et peuvent aussi bloquer le TLS sortant vers des hôtes non autorisés. Demandez à l’informatique d’autoriser le port TCP 443 sortant vers relay.remio.net (établissement de la connexion) et vers turn.cloudflare.com (le relais qui transporte le média quand l’UDP est fermé). Ces deux entrées suffisent pour que Remio fonctionne avec l’UDP entièrement bloqué.

Comment vérifier si ma session est directe ou relayée ?

Ouvrez la surcouche de statistiques en session depuis la barre d’outils. Chaque client Remio affiche un indicateur de type de connexion — Direct, LAN ou Relais — à côté de la latence et du débit. Les connexions directes paraissent plus vives ; les connexions relayées ajoutent environ 30 à 80 ms de latence selon votre distance au nœud relais le plus proche.

Remio fonctionne-t-il derrière un VPN ou un agent zero-trust ?

Oui, dans presque tous les cas. Les chemins pair à pair comme par relais utilisent du HTTPS sortant standard, que les VPN d’entreprise et les agents zero-trust (Zscaler, Cloudflare WARP, Tailscale, Twingate) laissent passer sans problème. Certains équipements d’inspection approfondie des paquets trop agressifs peuvent altérer le flux — voir la section de dépannage ci-dessus pour les contournements.

L’interception TLS de mon entreprise va-t-elle casser Remio ?

C’est possible. Les proxys d’inspection approfondie des paquets qui déchiffrent et rechiffrent toutes les connexions TLS suppriment parfois des parties de la poignée de main de connexion ou bloquent la nature durable des flux média. Si vous constatez que Remio n’échoue que sur votre réseau d’entreprise, demandez à l’informatique d’ajouter relay.remio.net et turn.cloudflare.com à la liste d’exclusion de l’inspection TLS — la plupart des proxys d’entreprise (Zscaler, Palo Alto, Cisco Umbrella, Check Point) prennent en charge l’exclusion par domaine.

Guides associés

• Configurer Mac vers Mac — la configuration de base avant de régler le chemin réseau.
• Configurer Mac vers iPad — même logique réseau, client iPad.
• Diffuser un PC Windows vers un Mac — même logique réseau, hôte Windows.
• Connexion LAN directe — quand vous voulez du pair à pair garanti sur votre propre réseau.
• Dépannage — le fourre-tout plus large pour les problèmes de connexion.
• Sécurité & chiffrement — tout le détail du chiffrement de bout en bout.