Flux en direct et contrôle à distance via TightVNC

Important :

Cela s’applique aux versions de Robot 2023.4 et 2023.10.

Les fonctionnalités de flux en direct et de contrôle à distance sont disponibles pour :

• Versions de Windows Robots 2023.4 et 2023.10
• Automation Cloud Robots - Serverless
• Automation Cloud Robots - VM

En raison de limites techniques, nous ne pouvons pas offrir une prise en charge complète des robots Linux, mais les principaux cas d'utilisation sont disponibles dans cette itération.

Remarque : cette fonctionnalité ne peut pas être utilisée avec les tâches en arrière-plan Windows.

Prérequis pour les Robots Windows 2023.10 et antérieurs.

1. Activez SignalR. Plus de détails ici
2. Installez un serveur VNC en suivant ces étapes :
   1. Téléchargez TightVNC. La version que nous prenons actuellement en charge est 2.8.75.
   2. Exécutez le programme d'installation et, une fois que vous atteignez l'écran Choisir le type d'installation (Choose Setup Type), sélectionnez Personnalisée (Custom).
   3. Cliquez sur Suivant (Next).
   4. Assurez-vous que l'option Enregistrer le serveur TightVNC en tant que service système (Register TightVNC Server as a system service) (sous Configuration du service TightVNC (TightVNC Service configuration)) n'est pas sélectionnée.
   5. Si vous utilisez une machine physique, un moniteur doit y être connecté.

Configuration requise pour le réseau

La configuration réseau minimale requise pour qu'une session de diffusion en direct et de contrôle à distance fonctionne sans accroc peut varier considérablement en raison d'un certain nombre de facteurs :

• La résolution d'écran du robot

• Les changements entraînés par votre automatisation - plus les changements d'images et de texte sont dynamiques, plus le volume de trafic est élevé

• La latence entre votre machine et la région Automation Cloud

• La latence entre votre robot et la région Automation Cloud

Compte tenu de ce qui précède, nous recommandons une bande passante réseau de 3 Mo/s pour une résolution d'écran de 1920 x 1080.

Considérations de sécurité

La connexion de diffusion en direct entre le client et la machine cible est acheminée via TLS via le proxy VNC, ce qui signifie que le serveur est sécurisé. De plus, chaque fois qu'une session de diffusion en direct est démarrée, un jeton JWT unique est généré et utilisé pour authentifier la requête. La seule instance de trafic non sécurisé se trouve sur la machine robot pour la connexion localhost.

Côté Robot, un mot de passe unique est généré pour chaque tâche et défini pour le serveur VNC. Le serveur ne s'exécute que pendant la session de diffusion en direct. Lorsque l'utilisateur se déconnecte de la session, le serveur VNC se ferme également.

Flux de réseau

1. Lorsque vous effectuez une demande depuis l’interface d’Orchestrator pour démarrer le flux en direct, Orchestrator envoie une commande au robot pour lancer une nouvelle session de contrôle à distance.
2. Le robot démarre un serveur VNC qui écoute sur le port dynamique. Le serveur VNC démarre en bouclage uniquement, ce qui désactive les connexions à distance. La commande Orchestrator inclut également un mot de passe pour l’authentification VNC, qui est partagé entre le serveur VNC et le client du navigateur.
3. Le robot commence alors ce qui suit :
   1. un autre programme qui se connecte au serveur VNC local sur le port dynamique
   2. un proxy de flux en direct UiPath

   Le programme transmet tout le trafic TCP au proxy de flux en direct en le convertissant en protocole WebSocket Secure (wss).

4. Le client Orchestrator VNC se connecte au même proxy de flux en direct dont le travail consiste à associer les deux WebSockets : l’un à partir du client VNC dans le navigateur et l’autre à partir du robot. Il crée ensuite un tunnel entre les deux WebSockets et transmet le trafic d’un WebSockets à l’autre.

   Le client VNC utilise deux ports : 443 et 5 900.

   Le port 443 doit être ouvert pour se connecter à un service auxiliaire en ligne.

   Le port 5 900 fonctionne localement sur la même machine pour acheminer le trafic entre deux applications.

   Pour que la communication fonctionne, ces ports doivent être ouverts dans les deux sens afin de permettre le trafic entrant et sortant.

   

Configuration TightVNC

Avant que la session ne démarre sur la machine locale, les connexions HTTP sont désactivées et le serveur VNC est configuré pour ne pas accepter les connexions en dehors de la machine locale.