Outils pour utilisateurs

Outils du site


user:pascal_cabaud:blog:grippe_a_et_teletravail

~~META: date created: 2009/11/25 02:20 date modified: 2009/11/25 02:20 ~~

Grippe « A » et télétravail

En cas de pandémie grippale, les services doivent continuer à fonctionner. Mon UFR a donc acquis plusieurs ordinateurs portables. Ils seront confiés aux personnels administratifs et techniques dont les activités sont indispensables pour que les missions de service public puissent être menées à bien et ce, malgré une fermeture éventuelle des locaux. La documentation pour les utilisateurs est là : Plan de continuité d'activité en cas de pandémie grippale.

Sessions à distance Les portables sont configurés pour utiliser des tunnels SSH (avec PuTTY) vers le proxy-cache, le mailhost et le poste de l'utilisateur via RDP. Comme ces machines sortent des murs et peuvent contenir des données sensibles (dossiers RH ou de scolarité par exemple), une partition est chiffrée avec TrueCrypt et les dossiers « Bureau », « Application Data » et « Local Settings » des utilisateurs sont chiffrés avec EFS (mécanisme natif de NTFS).

Les postes des personnels concernés fonctionnant sous Windows XP, le port tcp/3389 est ouvert en interne et les systèmes sont configurés pour accepter les sessions à distance (dans le panneau de configuration « Système »). Penser à éventuellement ajouter des utilisateurs sous la forme habituelle DOMAIN\user.

Sur la passerelle SSH, chaque utilisateur a un compte et s'authentifie par clé uniquement (penser à bloquer l'allocation d'un tty en ajoutant dans les $HOME/.ssh/authorized_keys, devant la clé, la mention no-pty). Sur les portables, PuTTY est installé et une clé par portable a été créée. Dans cette configuration, chaque personnel ayant un ordinateur portable, a un compte avec une clé sur la passerelle SSH.

Chaque utilisateur a un script d'ouverture de session qui :

  1. monte la partition chiffrée par TrueCrypt (saisie de la phrase secrète TrueCrypt),
  2. charge la clé (stockée sur la partition chiffrée) dans l'agent pageant.exe (saisie de la phrase secrète de la clé SSH),
  3. se connecte à la passerelle et ouvrent les tunnels,
  4. lance mstsc.exe (« Connexion Bureau à distance »).

Les navigateurs sont configurés pour utiliser le proxy-cache http://localhost:3128, le client de courrier se connecte quant à lui à localhost:25 et localhost:110. Enfin, le client RDP se connecte à localhost:3391 (on se réserve le droit d'utiliser localhost:3389… pour se connecter au portable lui-même !). Le client RDP (« Connexion Bureau à distance ») exporte la partition chiffrée sur le poste fixe (pour simplifier les échanges de fichiers).

Pour finir, pour que les informaticiens soient en mesure d'aider leurs collègues à travers divers NAT, une seconde connexion SSH est ouverte vers la passerelle et ouvre un tunnel en reverse forward (durcir éventuellement /etc/ssh/sshd_config avec PermitOpen). Chaque portable a son propre port, qui est fixe (15901, 15902, etc.). Un serveur UltraVNC écoute (uniquement) sur localhost:5900 sur les ordinateurs portables, permettant ainsi de se connecter à l'appareil et ce, malgré les divers NAT et routeurs traversés dans les deux sens.

NAT et reverse SSH

Testé sur une connexion ADSL à 1Mbs (17 hops, latence mesurée avec ping(8) d'environ 60ms), c'est parfaitement fluide. Lors des tests, j'ai poussé le vice à me connecter depuis mon portable à une machine virtuelle qui tournait sur ce même portable pour manipuler une feuille Excel sur un système dans les locaux de l'université ; il y avait alors dans le même « tuyau » :

  1. deux tunnels SSH depuis la VM vers la passerelle SSH (RDP et VNC en reverse),
  2. un tunnel SSH depuis le portable lui-même vers la passerelle (VNC),
  3. une connexion RDP depuis la VM vers un système dans les locaux de l'université.

Pour une fois, on espère avoir travaillé pour rien !

user/pascal_cabaud/blog/grippe_a_et_teletravail.txt · Dernière modification: 2010/01/23 01:30 (modification externe)