Accès distant

Intervenez sans vous déplacer, sans ouvrir un port

Vos automates, IHM, postes et équipements industriels, atteints sans ouvrir un port entrant. L'agent appelle le hub que vous hébergez, et tout passe dans ce flux : shell, fichiers, SSH, SFTP, écran distant, interfaces web. Un seul flux sortant à autoriser, aucune règle entrante. Avant d'ouvrir, la télémétrie dit ce qui répond ; pendant, les droits disent qui fait quoi ; après, le journal le garde.

Un terminal qui s'ouvre sur une machine distante Prise 2
Un terminal qui s'ouvre sur une machine distantedu clic à l'invite, derrière le pare-feu
Vidéo en boucle, 12 s - à capturer

Aucun port entrant, jamais

L'agent établit lui-même une connexion sortante et chiffrée vers le hub, et la maintient ouverte. Tout passe dedans : la télémétrie, les commandes, les mises à jour, et l'accès distant. Il n'y a donc aucune règle de pare-feu à obtenir sur le site distant, aucune adresse fixe à demander à l'opérateur, aucun port à exposer sur internet.

Une simple connexion internet sortante suffit : un lien 4G ou 5G, la box d'un prestataire, une liaison de chantier - un réseau que vous ne maîtrisez pas. Le canal se maintient seul, et un parc entier se reconnecte sans faire tomber le hub après une coupure.

Ce que vous faites à travers

Un shell interactif

Une vraie session : édition de ligne, complétion, programmes plein écran. Sur Linux comme sur Windows.

Comment le hub atteint les équipements derrière l'agent

Sous chacun de ces accès, le même mécanisme : c'est l'agent qui ouvre la connexion finale vers l'hôte et le port demandés, toujours en flux sortant. C'est ce qui vous donne les machines situées derrière lui, et pas seulement lui.

Ce n'est pas une fonction de plus, et il n'y a rien à en faire directement : on ne demande pas « un tunnel », on demande un service déclaré, et le tunnel est la façon dont il est atteint. Le hub ne connaît d'ailleurs pas d'autre mode que ceux ci-dessus.

Rien n'est installé sur votre poste, et rien n'y écoute. Le canal ne débouche pas sur un port local : le droit est accordé à la personne, pas à la machine sur laquelle elle est assise. Toutes les sessions - shell, fichiers, écran, bureau distant, interfaces web - se tiennent dans la console, dans le navigateur.

Les fichiers de la machine elle-même

Distinct du SFTP : ici il n'y a ni SSH ni service déclaré, l'agent ouvre le disque de sa propre machine, avec ses propres droits. Parcourir, téléverser, récupérer, renommer.

C'est fermé par défaut, et il faut deux accords pour l'ouvrir : celui de la machine et celui de l'exploitation - un contrôle posé d'un seul côté se contournerait du côté qu'on ne tient pas. L'accès est borné à une racine déclarée, et l'écriture demande un réglage de plus que la lecture.

Les écritures entrent au journal - dépôt, suppression, renommage, changement de droits.

Un fichier déposé sur une machine distante Prise 8
Un fichier déposé sur une machine distanteles fichiers de la machine, un relevé envoyé, et il est dans la liste
Vidéo en boucle, 12 s - à capturer

Un écran distant

L'accès à un serveur VNC local à l'agent, ou simplement joignable depuis lui : c'est le même mécanisme, l'agent ouvrant une connexion vers l'hôte et le port demandés. Rien à installer sur la machine visée.

Un écran distant dont on reprend la main Prise 7
Un écran distant dont on reprend la mainVNC, cinq à huit secondes, une fenêtre qu'on ouvre
Vidéo en boucle, 8 s - à capturer

Un bureau distant

Un poste Windows joignable derrière l'agent s'ouvre dans le navigateur, sans client à installer : le hub tient la connexion RDP, la décode et vous envoie l'image. C'est ce qui permet d'enregistrer la session et de la donner en lecture seule - un accompagnement qui regarde sans pouvoir agir -, ce qu'un client RDP posé sur votre poste ne saurait pas faire.

Un bureau Windows, décodé par le hub Prise 13
Un bureau Windows, décodé par le huble bureau s'ouvre dans le navigateur, une fenêtre de l'équipement s'ouvre dedans
Vidéo en boucle, 12 s - à capturer

Les interfaces web d'équipements

L'IHM web d'un automate ou d'un onduleur, ouverte dans votre navigateur à travers la connexion de l'agent.

Trente minutes sur un cas proche du vôtre

Dites-nous quels équipements, derrière quels réseaux. On vous montre la console dessus.

Demander une démo

Tracé, enregistré, opposable

Le rejeu d'une session enregistrée Prise 3
Le rejeu d'une session enregistréele curseur de temps qu'on déplace
Vidéo en boucle, 12 s - à capturer

Le journal d'audit conserve qui a accédé à quoi, quand, et ce qui s'y est fait ; les sessions de terminal et d'écran s'enregistrent et se rejouent. Vous n'ouvrez pas seulement la porte : vous pouvez montrer ce qui s'est passé derrière.

Le shell interactif reste une capacité avancée, réservée aux rôles qui la justifient : tout le monde n'a pas besoin d'une invite de commande sur une passerelle en production.

Ce que vous savez avant d'ouvrir la session

L'agent remonte la télémétrie et les métriques de la machine sans qu'on lui demande rien : ce qui répond, ce qui ne répond plus, depuis quand, et ce qui tourne dessus. On sait donc quoi ouvrir - et parfois qu'il n'y a rien à ouvrir : une machine injoignable depuis trois jours n'est pas une session à ouvrir, c'est un déplacement à prévoir.

L'IHM d'un automate, dans votre navigateur

L'IHM d'un équipement dans le navigateur Prise 4
L'IHM d'un équipement dans le navigateurla barre d'adresse visible : une adresse temporaire, celle de la session, pas celle de l'équipement
Vidéo en boucle, 10 s - à capturer

Ce que ces équipements ont de particulier

Un automate, un onduleur, une caméra, une IHM de ligne : la plupart de ces équipements exposent une interface web, et cette interface est le seul moyen sérieux de les régler. Elle vit sur un réseau que vous n'atteignez pas depuis votre bureau, derrière un site distant sans port entrant ouvert.

Les réponses habituelles coûtent cher : un VPN par site, un poste de rebond à maintenir, ou un déplacement.

Des interfaces web qui fonctionnent comme sur le site

C'est le choix qui décide de la fiabilité. Un routage par préfixe de chemin casse les URL absolues que ces firmwares écrivent partout ; router par le nom d'hôte les laisse intactes.

Corollaire : les corps de réponse ne sont jamais réécrits. La page arrive telle que l'équipement l'a produite, ce qu'aucune réécriture ne sait garantir.

Et deux équipements ne se marchent pas dessus : chacun a son origine, donc ses propres cookies.

Un domaine distinct de celui de la console

Ce n'est pas cosmétique : sur un sous-domaine de la console, l'interface web d'un équipement compromis pourrait poser un cookie qui atteint la console elle-même.

Le cookie de la session porte le préfixe __Host- : l'isolation est vérifiée par le navigateur plutôt que promise par nous.

Ce qui passe

Le TLS jusqu'à l'équipement, y compris vers les certificats auto-signés que porte la plupart des firmwares. La bascule WebSocket, dont dépendent les IHM modernes qui rafraîchissent leurs valeurs en direct. Et l'authentification par le hub en amont : l'équipement n'est joignable qu'après que le hub a reconnu la personne et vérifié ses droits, la session étant tracée comme le reste.

Ce qui ne passe pas

Un équipement qui impose NTLM ou Negotiate ne s'ouvrira pas ainsi : ces deux mécanismes supposent une connexion TCP tenue d'un bout à l'autre.

L'échec est franc : ce qui fonctionne fonctionnera toujours, ce qui ne passe pas ne passera jamais. On l'éprouve à l'enrôlement, pas un jour d'intervention.

Sur Android, dans les limites du système

L'agent Android porte le terminal, les fichiers et les tunnels, mais dans ce qu'Android laisse à une application non rootée : le terminal tourne sous l'identité de l'agent, dans son bac à sable, et les fichiers sont les dossiers que l'appareil a accordés. Pas d'écran distant. Ce que fait l'agent Android