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 : terminal, fichiers, écrans et bureaux distants, interfaces web, supervision SNMP, caméras. 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.
Prise 2
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
À travers l'agent, le hub ouvre SSH, Telnet, SFTP, FTP et FTPS, VNC, RDP, interfaces web, SNMP v2c et v3, caméras RTSP et ONVIF, et tout port TCP déclaré. Chacun est décrit ci-dessous, avec ce qu'il fait et où il s'arrête, sous les mêmes droits et dans le même journal.
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.
Prise 8
SSH et Telnet, vers un équipement
Un terminal ouvert sur un équipement derrière l'agent, dans la console. En SSH, le hub peut tenir l'identifiant de la cible : l'intervenant reçoit le droit d'ouvrir la session, pas le mot de passe.
Telnet est là pour les équipements qui ne parlent que lui, et il est dit pour ce qu'il est : le badge de confiance le marque « en clair », et aucune politique ne peut relever ce niveau, puisque le protocole ne chiffre rien. Le hub n'en tient pas les identifiants - c'est l'invite de l'équipement qui les demande - et la case du protocole est décochée d'avance sur chaque machine. Les deux sessions s'enregistrent et se rejouent ; celle de Telnet garde ce qui s'est affiché, mot de passe compris si l'équipement l'a affiché.
Les fichiers d'un équipement
Un serveur SFTP, FTP ou FTPS derrière l'agent s'ouvre dans le même navigateur de fichiers que la machine elle-même : c'est le hub qui parle le protocole derrière. Chaque dépôt, renommage ou suppression entre au journal.
Le FTPS est une politique TLS posée sur le service, et le badge dit lequel des deux on ouvre. Ce qui n'est pas servi : le mode actif, qui demanderait à l'équipement de se connecter vers l'extérieur, et le FTPS implicite sur le port 990. L'agent n'ouvre le canal de données que sur la plage que le serveur annonce.
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.
Prise 7
Un bureau distant
Un poste Windows joignable derrière l'agent s'ouvre de deux façons, au choix de qui le déclare, et la carte du bureau dit laquelle.
Supervisé : le hub ouvre lui-même la session, avec le compte enregistré du service, et la décode. C'est ce qui permet de l'enregistrer et de la donner en lecture seule - un accompagnement qui regarde sans pouvoir agir. Elle s'ouvre dans le navigateur, sans client à installer, ou dans le client RDP du poste - mstsc, FreeRDP, Remmina -, qui reçoit alors l'image que le hub a décodée et s'enregistre de même. Les lecteurs, les imprimantes et le son du poste n'y passent pas.
Relayé : le hub ne transporte que des octets, vers le navigateur ou vers le client du poste. Rien ne s'enregistre, rien ne se donne en lecture seule, et aucun mot de passe n'est gardé : c'est le RDP tel quel, pour qui le veut ainsi, et la console le dit sur la carte du bureau.
Prise 13
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.
Lire et superviser un équipement en SNMP
Le hub interroge lui-même un switch, un onduleur ou un automate : sa fiche - nom, emplacement, depuis quand il tourne, ses interfaces, leur état et leur débit -, n'importe quel identifiant, et ceux qu'on choisit de superviser, relevés à intervalle, gardés un mois, avec un seuil qui prévient quand il est franchi et quand la valeur revient.
En v2c par communauté, en v3 par utilisateur, aux trois niveaux de sécurité ; la communauté et les clés sont scellées dans le hub et n'en sortent pas. Le badge dit ce qui traverse le réseau du site : seul le v3 chiffré est chiffré. En lecture seule : le hub n'écrit jamais sur un équipement et ne reçoit pas de trap. L'agent relaie des datagrammes UDP qu'il ne lit pas, dans le même périmètre qu'une connexion TCP - l'agent Android aussi, pour un équipement que seul le téléphone joint. Lire un équipement demande un droit à part, distinct de celui de voir le service déclaré.
Une caméra, dans la console
Une caméra RTSP s'ouvre dans un onglet de l'espace de travail, sur le seul port déclaré, en RTSPS si une politique TLS le demande. Une seule connexion vers la caméra, quel que soit le nombre de personnes qui regardent, et chacune entre au journal.
Avec un port ONVIF déclaré en plus, un bouton « Commandes » donne ce que la caméra propose : un instantané, l'orientation et le zoom tant qu'on appuie, les préréglages, le filtre infrarouge, la mise au point. Le hub arrête la caméra dès que les ordres cessent d'arriver - elle ne continue jamais de tourner parce qu'un message s'est perdu. Piloter demande un droit de plus que regarder.
Ce qui ne se lit pas : le navigateur ne lit que le H.264. Une caméra en H.265, en MJPEG ou en MPEG-4 le dit au lieu d'afficher un rectangle noir - le hub ne réencode pas. Le son n'est pas joué.
Tout autre port TCP
Ce qui n'est dans aucune des familles ci-dessus se déclare comme un port : son adresse, son numéro, et il devient joignable à travers l'agent, avec les mêmes droits et la même trace. Avec PipeLinker Desktop, ce sont vos propres outils qui l'atteignent - un client d'automate, un client de base de données -, par un port local sur votre poste.
Dites-nous quels équipements, derrière quels réseaux. On vous montre la console dessus.
Tracé, enregistré, opposable
Prise 3
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.
Une session en cours se regarde aussi, depuis la console, par une autre personne qui ne peut rien envoyer - ni souris ni clavier. Terminal, écran ou bureau, celle qui est regardée le sait : un bandeau le lui dit. Depuis l'onglet « Sessions » de la machine, qui en a le droit peut aussi la couper.
Les enregistrements ont une durée de conservation et une place maximale, que vous réglez ; la purge ne retire jamais une session en cours d'écriture. Chaque matin, un rapport dit aux administrateurs la place occupée, ce qui s'est ajouté et ce que la purge a retiré, parc par parc.
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
Prise 4
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. Il ne sert pas son propre écran - c'est une autorisation qu'on ne lui demande pas -, mais celui d'un équipement derrière lui s'atteint par le tunnel, comme depuis n'importe quel agent. Il relaie aussi l'UDP, donc le SNMP. Ce que fait l'agent Android