Procédure d'assistance à distance VNC/OpenVPN

#1

Republication d’une procédure d’assistance à distance basée sur l’utilisation de VNC/OpenVPN. Rédigée, testée et utilisée avec Debian Jessie mais devrait être valable pour des versions plus récentes du système, cependant certaines informations notamment sur la partie Android et MS Windows sont peut-être obsolètes, tâche au lecteur de les vérifier.

Introduction

Convention utilisée dans ce document

  • Pour parler d’un poste effectuant l’assistance à distance le terme poste aidant est employé.
  • Pour parler d’un poste recevant l’assistance à distance le terme poste aidé est employé.

Objectif

Le but recherché ici est de proposer une méthode d’assistance à distance qui soit simple d’utilisation, sûre, uniquement basée sur l’utilisation de logiciels libres et qui permette de contourner les problèmes d’accès au poste aidé se trouvant derrière un routeur qui bien souvent ne possède pas d’IP publique fixe, ce qui obligerait à :

  • configurer une redirection de port dans le routeur pour accéder au poste aidé se trouvant derrière,
  • utiliser un service de DNS dynamique pour localiser le poste quand l’IP publique change.

Cette solution est adaptée s’il y a de nombreux postes aidés à gérer, par exemple dans le cas d’un service d’assistance à distance proposé par une société pour ses clients. Cette solution permet de se passer de service externe et privateur comme TeamViewer tout en étant plus souple et plus efficace.

Principe

La solution proposée ici repose sur l’utilisation d’OpenVPN et de VNC. L’idée est d’installer et de configurer sur les deux postes aidant et aidé un client OpenVPN afin qu’ils se connectent tous les deux au même réseau local virtuel et puissent se trouver virtuellement. Du poste aidant, on peut ainsi accéder facilement au poste aidé sans à avoir recours à aucune redirection de port dans aucun routeur ni à aucun service de DNS Dynamique pour localiser l’un des deux postes.

(Il resterait néanmoins nécessaire d’effectuer une redirection de port dans un routeur et de configurer un service de DNS dynamique, si l’accès au serveur OpenVPN depuis l’Internet ne dispose pas d’une IP publique fixe. En effet, ce serveur sert de « jonction » entre les différents postes aidants et aidés, il faut donc en installer un et le configurer comme indiqué dans la partie Configuration du serveur.)

Sur chacun des postes aidés un serveur VNC est installé, la configuration est ainsi faite qu’il n’est lancé qu’au besoin, lors des connexions au réseau VPN, puis coupé à la déconnexion du VPN de manière qu’il ne reste pas en écoute inutilement sur le réseau local pour plus de sécurité.

Enfin, seuls les postes aidants ont accès à toutes les machines du réseau virtuel alors que les poste aidés n’ont qu’un accès restreint de façon à ce qu’ils ne puissent contacter les autres postes du réseau. En effet, il doit être impossible pour deux postes aidés connectés en même temps au VPN de se connecter l’un à l’autre.

Configuration du serveur

0. À propos du serveur

La configuration proposée ici est destinée à une machine fonctionnant sous Debian Jessie. On estime aussi qu’il n’y a pas d’autres configurations OpenVPN tournant sur la machine.

Les paquets suivants doivent être présents sur le système :

  • openvpn (le serveur vpn),
  • esay-rsa (une suite de script qui permettra de gérer facilement une infrastructure à clé publique pour le serveur vpn),
  • iptables-persistent (permet de charger le règle iptables automatiquement au démarrage du système).
apt-get install openvpn easy-rsa iptables-persistent

1. Préparer l’autorité de certification

Le serveur VPN doit être en mesure d’accepter plusieurs clients, de les authentifier et de chiffrer la communication. Pour cela il faut créer :

  • une autorité de certification
  • ainsi que des certificats pour les clients et le serveur.

Cela requiert la mise en place d’une Public Key Infrastructure (PKI). Pour cela nous utiliserons easy-rsa qui est fourni par le paquet easy-rsa sous Debian Jessie. (mais qui peut aussi se récupérer ici. Easy-rsa consiste en un ensemble de script shell servant de frontend à openssl.

Pour commencer, créer une copie des scripts dans le dossier /etc/openvpn/ (ou bien cloner le dépôt git de easy-rsa si votre distribution ne comporte pas le paquet).

cp -a /usr/share/easy-rsa/ /etc/openvpn/

Toujours dans le dossier /etc/openvpn/, créer un dossier keys dédié au stockage des clés et certificats. À l’intérieur de ce dossier, il faut y créer deux fichiers :

serial
: dans lequel on ajoutera la valeur “00”. Ce fichier sert à numéroter de manière unique chaque certificat créé. Il est incrémenté de 1 a chaque nouveau certificat créé.

index.txt
: un fichier texte où seront indexés tous les certificats créés.

cd /etc/openvpn/
mkdir keys/
echo "00" > keys/serial
touch keys/index.txt

Il faut ensuite éditer le fichier easy-rsa/vars afin de configurer le comportement du script pour la création des certificats, il faut entre autre y modifier la variable KEY_DIR pour qu’elle pointe dans le dossier keys créé plus haut : KEY_DIR=$EASY_RSA/../keys. Et comme on est complètement baisé, on va mettre la valeur de KEY_SIZE à 4096 bit. Modifier les autres variables en conséquence et selon les besoins.

Voici le contenu du fichier /etc/openvpn/easy-rsa/vars après modifications :

	# easy-rsa parameter settings

	# NOTE: If you installed from an RPM,
	# don't edit this file in place in
	# /usr/share/openvpn/easy-rsa --
	# instead, you should copy the whole
	# easy-rsa directory to another location
	# (such as /etc/openvpn) so that your
	# edits will not be wiped out by a future
	# OpenVPN package upgrade.

	# This variable should point to
	# the top level of the easy-rsa
	# tree.
	export EASY_RSA="`pwd`"

	# This variable should point to
	# the requested executables
	#
	export OPENSSL="openssl"
	export PKCS11TOOL="pkcs11-tool"
	export GREP="grep"

	# This variable should point to
	# the openssl.cnf file included
	# with easy-rsa.
	export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA`

	# Edit this variable to point to
	# your soon-to-be-created key
	# directory.
	#
	# WARNING: clean-all will do
	# a rm -rf on this directory
	# so make sure you define
	# it correctly!
	export KEY_DIR="$EASY_RSA/../keys"

	# Issue rm -rf warning
	echo NOTE: If you run ./clean-all, I will be doing a rm -rf on $KEY_DIR

	# PKCS11 fixes
	export PKCS11_MODULE_PATH="dummy"
	export PKCS11_PIN="dummy"

	# Increase this to 2048 if you
	# are paranoid.  This will slow
	# down TLS negotiation performance
	# as well as the one-time DH parms
	# generation process.
	export KEY_SIZE=4096

	# In how many days should the root CA key expire?
	export CA_EXPIRE=3650

	# In how many days should certificates expire?
	export KEY_EXPIRE=3650

	# These are the default values for fields
	# which will be placed in the certificate.
	# Don't leave any of these fields blank.
	export KEY_COUNTRY="FR"
	export KEY_PROVINCE="Calvados"

	export KEY_CITY="Vire"
	export KEY_ORG=""
	export KEY_EMAIL="demar.max@openmailbox.org"
	export KEY_OU="help_user"

	# X509 Subject Field
	export KEY_NAME="EasyRSA"

	# PKCS11 Smart Card
	# export PKCS11_MODULE_PATH="/usr/lib/changeme.so"
	# export PKCS11_PIN=1234
	
	# If you'd like to sign all keys with the same Common Name, uncomment the KEY_CN export below
	# You will also need to make sure your OpenVPN server config has the duplicate-cn option set
	# export KEY_CN="CommonName"

Ensuite, on initialise l’autorité de certification racine, pour cela il faut se placer dans le dossier ou se trouve le script easy-rsa :

cd easy-rsa
source vars
./pkitool --initca

Le dossier keys contient maintenant le certificat et la clé privé pour l’autorité de certification (CA).

La prochaine étape est de générer le paramètre pour le Diffie-Hellman et vu qu’on a fixé la longueur des clés à 4096 bit, on a du temps temps d’aller boire son café dans le bistro de la ville d’à côté.

./build-dh

L’authentification HMAC permet de signer les paquets à destination du serveur. Ce qui permet entre autre d’éviter les attaques de type DOS. Pour cela, il faut créer une clé statique qui devra aussi être fournie au client :

openvpn --genkey --secret keys/ta.key

Pour finir, il reste à créer le certificat et la clé privé pour le serveur :

./pkitool --interact --server mysrv

Une fois le tout terminé, notre dossier keys doit disposer des fichiers suivants :

Fichier Description
ca.key Clé privé de la CA
ca.crt Clé public de la CA
dh4096.pem Paramètre Diffie-Hellman
ta.key Clé d’authentification HMAC
mysrv.crt Certificat du serveur
mysrv.key Clé privé du serveur

2. Configurer le serveur OpenVPN

Pour plus de sécurité, le serveur tournera dans un environnement chrooté. Dans le dossier de configuration d’openvpn créer un dossier chroot.

cd /etc/openvpn/
mkdir chroot

OpenVPN a besoin d’avoir accès à un répertoire /tmp accessible en écriture après que le deamon se soit mis à tourner avec les droits d’utilisateur non privilégiés, vu que le serveur ici fonctionne dans un chroot il faut qu’il dispose de ce répertoire dans son chroot :

mkdir chroot/tmp
chown nobody:nogroup chroot/tmp

Chaque client du VPN est identifié de manière unique grâce au common name de son certificat. En plaçant dans un dossier prévu à cet effet un fichier portant lui aussi le common name du client, on peut lui passer des paramètres de configuration propre. Cela servira dans ce cas à fixer une IP propre à chaque client pour ensuite pouvoir filtrer les connexions en fonction du fait qu’il s’agisse d’un poste aidant ou d’un poste aidé. À noter que vu que le service sera chrooté dans le dossier chroot, il faut créer ce dossier de configuration des clients (ccd) dans ce dossier.

mkdir chroot/ccd

Il faut maintenant créer le fichier de configuration pour les serveurs dans le dossier de configuration d’OpenVPN.

Remarquons qu’OpenVPN peut accepter plusieurs fichiers de configuration, chacun pouvant servir pour une instance différente du service. Sous Debian Jessie, tous les fichiers se trouvant dans /etc/openvpn/ doivent se terminer par l’extension .conf si on veut qu’ils soient détectés par le script d’init du service. Par défaut, aucun de ces fichiers n’est lu par celui-ci, pour déterminer lesquels doivent être démarrés automatiquement se reférer au fichier /etc/default/openvpn.

Créer le fichier /etc/openvpn/serveur.conf et y mettre :

	# Port d'écoute du serveur
	port 1194
	# Tunnel sur UDP (ne pas utiliser tcp dans ce cas-ci car VNC l'utilise déjà)
	proto udp
	# Tunnel routé
	dev tun
	# Certificat de l'autorité de certification
	ca keys/ca.crt
	# Certificat du serveur
	cert keys/mysrv.crt
	# Clé privée du serveur
	key keys/mysrv.key
	# Paramètre Diffie-Hellman
	dh keys/dh4096.pem
	# Le tunnel supporte un réseau de type subnet ou les clients ne peuvent se joindre
	# qu'au travers de la passerelle (pas d'utilisation de client-to-client ici car il
	# faut que la passerelle puisse filtrer les connexions au travers du tunnel).
	topology subnet
	mode server
	tls-server
	push topology subnet
	# Ip de la passerel
	ifconfig 172.20.0.1 255.255.0.0
	# Pool d'IP disponibles pour les clients du réseau. Les dernières IP (de .255.1
	# à .255.254 sont réservées pour les postes aidants qui ont accès à tout le réseau
	# VPN).
	ifconfig-pool 172.20.0.2 172.20.254.254 255.255.0.0
	# Toutes les connexions en direction du réseau VPN doivent transiter par la
	# passerelle pour y être filtrées.
	push route 172.20.0.0 255.255.0.0 172.20.0.1
	# Ping les clients toutes les 10 secondes, si pas de réponce au bout de 120
	# secondes le client est considéré comme mort.
	keepalive 10 120
	# authentification TLS de paquets côté serveur
	tls-auth keys/ta.key 0
	# Active la compression lzo des données
	comp-lzo
	# Le serveur, une fois lancé, tourne avec des droits réduits
	user nobody
	group nogroup
	# Vu que les serveurs tournent avec des droits réduits, il ne sera pas en mesure
	# de relire la clé publique ou de récréer l'interface tun en cas de signal
	# de réinitialisation. On va donc les laisser persistantes.
	persist-key
	persist-tun
	# Fichier de statut sur les connexions actives
	status openvpn-status.log
	verb 3
	# Une fois démarré, le serveur chrootera dans ce dossier
	chroot /etc/openvpn/chroot/
	# Configuration spécifique au client, utilisé pour fixer une IP au client
	# aidant et filtrer/autoriser ensuite ces IP à accéder à la totalité du
	# du VPN.
	client-config-dir ccd

Il n’y a plus qu’à démarrer le service. Ne pas oublier d’éditer le fichier /etc/default/openvpn pour que cette configuration d’OpenVPN soit chargée automatiquement au démarrage avec AUTOSTART="serveur" :

	# This is the configuration file for /etc/init.d/openvpn
	#
	# Start only these VPNs automatically via init script.
	# Allowed values are "all", "none" or space separated list of
	# names of the VPNs. If empty, "all" is assumed.
	# The VPN name refers to the VPN configutation file name.
	# i.e. "home" would be /etc/openvpn/home.conf
	#
	# If you're running systemd, changing this variable will
	# require running "systemctl daemon-reload" followed by
	# a restart of the openvpn service (if you removed entries
	# you may have to stop those manually)
	#
	#AUTOSTART="all"
	#AUTOSTART="none"
	AUTOSTART="server"
	#
	# WARNING: If you're running systemd the rest of the
	# options in this file are ignored.
	#
	# Refresh interval (in seconds) of default status files
	# located in /var/run/openvpn.$NAME.status
	# Defaults to 10, 0 disables status file generation
	#
	#STATUSREFRESH=10
	#STATUSREFRESH=0
	# Optional arguments to openvpn's command line
	OPTARGS=""
	#
	# If you need openvpn running after sendsigs, i.e.
	# to let umountnfs work over the vpn, set OMIT_SENDSIGS
	# to 1 and include umountnfs as Required-Stop: in openvpn's
	# init.d script (remember to run insserv after that)
	#
	OMI_SENDSIGS=0

Note à propos de systemd
: Systemd crée un service pour chaque instance d’OpenVPN donc dans notre cas pour démarrer ou stopper le service, il ne faut pas faire systemctl [action] openvpn.service mais systemctl [action] openvpn@serveur.service.

3. Filtrer le trafic au travers du VPN avec Netfilter

Pour des raison de sécurité il faut que les poste aidant ne puissent pas se contacter les uns les autres au travers du VPN. Rappelons en effet que le serveur sert de passerelle pour toutes les connexions à destination du VPN. Il faut donc configurer ces règles dans la chaîne FORWARD de la table filter de Netfilter à l’aide de la commande iptables.

Il ne faut pas non plus oublier d’activer l’ip_forward pour ipv4 sinon ça ne marchera pas.

	sysctl net.ipv4.ip_forward=1
	# Décommente l'activation du suivie d'ipv4 au démarrage
	sed -i "s/#net\.ipv4\.ip_forward=1/net\.ipv4\.ip_forward=1/g" /etc/sysctl.conf

Il faut ensuite définir la politique par défaut pour la chaîne FORWARD pour que tout soit bloqué.

	iptables -P FORWARD DROP

Puis autoriser tout le trafic déjà établi, sans cela les postes aidant pourront contacter les postes aidé mais ces derniers ne pourront répondre.

	iptables -A FORWARD -s 172.20.0.0/16 -d 172.20.0.0/16 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Il y a une plage d’IP du réseau VPN que le serveur n’attribue pas dans sa configuration actuelle, il s’agit des IP allant de 172.20.255.1 à 172.20.255.254. Ces IPs ne seront attribuées qu’au poste aidant via un fichier dans le dossier de configuration personnalisé (/etc/openvpn/chroot/ccd/) ; voir la partie Permettre à un poste aidant de contacter les postes aidés.

Il faut maintenant ajouter une règle au pare-feu pour que cette plage d’adresse ait accès a la totalité du réseau VPN :

	iptables -A FORWARD -m iprange --src-range 172.20.255.1-172.20.255.254 -d 172.20.0.0/16 -j ACCEPT

Pour finir, il faut sauvegarder les règles créées pour qu’iptables-persistent les charge automatiquement au démarrage :

	iptables-save > /etc/iptables/rules.v4

Configuration des clients

Au préalable sur le serveur

Création du certificat pour tous les clients (postes aidés comme postes aidants)

Pour s’authentifier sur le serveur, chaque client doit disposer de son certificat et de sa clé privée. Ils sont créés à l’aide de easy-rsa de la même manière que pour ceux du serveur. Chaque certificat est identifié de manière unique grâce à son common name à fournir comme argument au script de génération du certificat, ici mon_client :

Sur le serveur OpenVPN :

	cd /etc/openvpn/easy-rsa/
	source vars
	./pkitool --interact mon_client

Pour se connecter au serveur, le client à besoin de disposer de 4 fichiers en tout :

Fichier Description
mon_client.key sa clé privé
ca.crt le certificat de l’autorité de certification du serveur OpenVPN
ta.key la clé servant pour l’authentification HMAC

Pour copier ses fichiers au client, il peut être utile de la placer dans un fichier d’archive. Par exemple pour un client GNU/Linux avec tar :

cd /etc/openvpn/
tar -cf MonClient_OVPN_AUTH.tar keys/mon_client.crt keys/mon_client.key keys/ca.crt keys/ta.key

Ou pour un client M$/Windows avec zip :

cd /etc/openvpn/
zip MonCLient_OVPN_AUTH.zip keys/mon_client.crt keys/mon_client.key keys/ca.crt keys/ta.key

Il ne reste plus qu’à se débrouiller pour faire parvenir l’archive au client.

Permettre à un poste aidant de contacter les postes aidés

Les postes aidants doivent pouvoir accéder aux autres postes au travers du réseau VPN, ce qui est bloqué par défaut par le pare-feu. Des règles ont été ajoutées au pare-feu pour laisser passer les connexions provenant des IP allant de 172.20.255.1 à 172.20.255.254.

Or, par défaut, le serveur n’attribue aucune de ses IP. En créant un fichier du même nom que celui du common name du certificat du client dans le dossier des configurations personnalisées d’OpenVPN (voir la directive client-config-dir dans le fichier de configuration du serveur ainsi que la partie 2. Configurer le serveur OpenVPN). Dans ce fichier, il faut placer une directive pour que le client reçoive une IP comprise dans la plage des IP non filtrées. Par exemple, le client dont le common name du certificat est mon_client, on crée le fichier /etc/openvpn/chroot/ccd/mon_client pour y placer :

ifconfig-push 172.20.255.1 255.255.0.0

Ainsi, lors de sa connexions au serveur le client recevra l’IP 172.20.255.1 et pourra contacter tous les postes aidés.

Configurer OpenVPN et VNC pour un poste aidé sous GNU/Linux

La configuration d’un poste aidant est presque identique à celle d’un poste aidé mis a part qu’il est inutile d’installer de serveur VNC et qu’il faudra aussi faire le nécessaire pour qu’il puissent contacter les postes aidés comme expliqué dans la partie précédente.

Configurer OpenVPN et VNC pour un poste aidé sous GNU/Linux

Installer Network-Manager pour OpenVPN et X11VNC

Les postes devront disposer de network-manager-openvpn-gnome qui servira de client OpenVPN ainsi que de x11vnc (meilleur serveur VNC que vinagre qui ne supporte pas le transfert de fichier ni le chat UltraVNC).

Si un autre serveur VNC écoute sur le port 5900 il faudra le désactiver.

Sous Debian :

apt-get install network-manager-openvpn-gnome x11vnc

Configurer Network-Manager pour OpenVPN

Au préalable, il faut récupérer le nécessaire pour connecter le client (certificat, clé, etc…). Puis, dans la configuration des connexions, via l’interface graphique de Network-Manager :

  1. Ajouter une connexion de type OpenVPN.
  2. Dans Nom de la connexion, donner un nom explicite comme “assistance à distance”.
  3. Donner comme adresse de passerelle celle du serveur OpenVPN (bien évidement, il faut au préalable avoir fait le nécessaire pour quecelui-ci soit joignable depuis internet.)
  4. Laisser le paramètre d’authentification à l’aide de certificat TLS.
  5. Fournir les chemins vers le certificat du client, la CA ainsi que vers la clé privée du client.
  6. Cliquer ensuite sur le bouton « avancé » :
-   Sous l'onglet « Général » : cocher `Utiliser la compression de données LZO`
-   Sous l'onglet « Authentification TLS » : fournir la clé pour l'authentification HMAC (fichier `ta.key`) dans /"Fichier declé :/" puis mettre la direction de la clé à 1 (pour un client).
-   Cliquer sur `Valider`
  1. Dans l’onglet Paramètres IPv4 cliquer sur le bouton Routes... puis cocher Utiliser cette connexion uniquement pour les ressources de son réseau afin que l’interface du VPN ne soit pas utilisé comme route par default.

Configurer le serveur VNC

Ici x11vnc sera lancé lors de la connexion au VPN puis sera stoppé lors de sa déconnexion. Pour cela, il faut utiliser le dispatcher de Network-Manager qui permet d’exécuter des script à la connexion et a la déconnexion d’une interface réseau (pour en savoir plus : man NetworkManager). Créer le fichier /etc/NetworkManager/dispatcher.d/10x11vnc_openvpn_connect et y mettre :

   #!/bin/sh

   ## Lance automatiquement le serveur x11vnc lors de sa connexion
   ## OpenVPN pour l'assistance à distance.

   ## Le serveur VNC est configuré pour n'autoriser que les connexions
   ## entrantes sur l'interface du VPN, supporte le transfert de fichiers
   ## UltraVNC et est lancé avec les droit de l'utilisateur connecté sur
   ## l'interface graphique pour que le transfert de fichier s'opère avec
   ## des droits restreints.

   test "$1" != "tun0" && exit

   X_CONNECTED="$(w | grep " :0 " | cut -d " " -f 1 | head -n 1)"

   case $2 in
		  vpn-up )
				 su -c "x11vnc -display :0 -nopw -allow 172.20. -ultrafilexfer -forever -env FD_XDM=1 -auth /home/$X_CONNECTED/.Xauthority" $X_CONNECTED &
		  ;;
		  vpn-down )
				  killall x11vnc
		  ;;
   esac

Ainsi, à chaque fois que NetworkManager se connecte au réseau VPN, le serveur VNC x11vnc sera lancé. Les paramètres qui lui sont fixés font qu’il n’acceptera les connexions qu’en provenance du VPN, gérera le transfert de fichier UltraVNC et afin d’éviter que celui-ci n’ait un accès root au système de fichier le service tournera avec les droits de l’utilisateur connecté sur l’interface graphique. Il est aussi lancé avec l’option -forever pour qu’il ne coupe pas si le client VNC rompt la connexion. Une fois la connexion au VPN interrompue, le script tuera le serveur VNC.

Configuration d’OpenVPN et de VNC pour un poste aidé sous M$/Windows

Testé sur les version 8 et 10 de M$/Windows.

Le serveur VNC UltraVNC

Le serveur VNC retenu ici est UltraVnc, il doit être installer avant OpenVPN pour que ce dernier puisse le démarrer automatiquement lors d’une connexion au VPN à l’aide d’une directive dans son fichier de configuration.

1. Installation

Récupérer le paquet d’installation sur le site d’UltraVNC dans la version qui correspond au système cible.

Dans notre cas, nous n’aurons besoin d’installer qu’UltraVNC serveur (pas besoin du client). Ne pas installer UltraVNC en tant que service ni créer de raccourci sur le bureau. Il est possible de faire une silent install du programme en mettant les instructions d’installation suivantes dans un fichier ini, ici nommé ultravnc_silent-install.ini qui se trouve dans le même dossier que celui de d’installateur et qui contient les réponses au questions posées durant l’installation :

	[Setup]
	Lang=fr
	Dir=C:\Program Files\uvnc bvba\UltraVNC
	Group=UltraVNC
	NoIcons=0
	SetupType=custom
	Components=ultravnc_server
	Tasks=

Ensuite, il n’y a plus qu’a effectuer l’installation silencieuse avec le commande suivante :

cd chemin\ver\installateur
UltraVNC_[version]_setup.exe /silent /loadinf=ultravnc_silent-install.inf

2. Configuration

UltraVNC se configure via l’exécutable uvnc_settings.exe situé dans son dossier d’installation (ici C:\Program Files\uvnc bvba\UltraVNC). Par défaut, la configuration est stockée dans le fichier ultravnc.ini qui se trouve dans le même dossier. Voici le contenus de ce fichier pour une configuration qui conviendra parfaitement dans notre cas :

	accept_reject_mesg=
	DebugLevel=8
	DisableTrayIcon=0
	LoopbackOnly=0
	UseDSMPlugin=0
	AllowLoopback=1
	AuthRequired=0
	ConnectPriority=2
	DSMPlugin=No Plugin Detected
	AuthHosts=
	DSMPluginConfig=
	AllowShutdown=1
	AllowProperties=1
	AllowEditClients=1
	FileTransferEnabled=1
	FTUserImpersonation=1
	BlankMonitorEnabled=1
	BlankInputsOnly=0
	DefaultScale=1
	primary=1
	secondary=0
	SocketConnect=1
	HTTPConnect=0
	AutoPortSelect=0
	PortNumber=5900
	HTTPPortNumber=5800
	IdleTimeout=0
	IdleInputTimeout=0
	RemoveWallpaper=1
	RemoveAero=1
	QuerySetting=2
	QueryTimeout=10
	QueryAccept=1
	QueryIfNoLogon=1
	InputsEnabled=1
	LockSetting=0
	LocalInputsDisabled=0
	EnableJapInput=0
	kickrdp=0
	clearconsole=0
	service_commandline=
	FileTransferTimeout=1
	KeepAliveInterval=5
	[admin_auth]
	group1=
	group2=
	group3=
	locdom1=0
	locdom2=0
	locdom3=0
	[poll]
	TurboMode=1
	PollUnderCursor=0
	PollForeground=0
	PollFullScreen=1
	OnlyPollConsole=0
	OnlyPollOnEvent=0
	MaxCpu=40
	EnableDriver=0
	EnableHook=1
	EnableVirtual=0
	SingleWindow=0
	SingleWindowName=

À adapter au besoin bien sûr. UltraVNC requiert deux mots de passe pour ce connecter à une session, dans le fichier de configuration ci-dessus il sont :

  • toto: pour ouvrir une session avec prise de contrôle
  • titi: pour ouvrir une session viewer only

(je sais qu’ils sont bidons mes mots de passe… Mais merde !)

Le client OpenVPN

1. Installation

La première chose à faire est de récupérer le paquet d’installation d’OpenVPN à cette adresse. Ce paquet contient aussi TAP-windows il est donc inutile de le télécharger en plus.

Dans notre cas, il n’est pas utile d’installer tous les éléments contenus dans le paquet, ne sélectionner que les option suivantes lors de l’installation (décocher les autres) :

  • TAP Virtual Ethernet Adaptater
  • OpenVPN GUI
  • OpenVPN File Associations
  • Add OpenVPN to PATH
  • Depencencies (tout coché)

Cela peut aussi être fait à l’aide de la ligne de commande suivant pour une installation silencieuse :

	cd \chemin\vers\l'installateur\
	.\openvpn-install-[version].exe /S /SELECT_SHORTCUTS=0 /SELECT_OPENVPN=1 /SELECT_SERVICE=0 /SELECT_TAP=1 /SELECT_OPENVPNGUI=1 /SELECT_ASSOCIATIONS=1 /SELECT_OPENSSL_UTILITIES=0 /SELECT_EASYRSA=0 /SELECT_PATH=1 /SELECT_OPENSSLDLLS=1 /SELECT_LZODLLS=1 /SELECT_PKCS11DLLS=1

2. Configuration

Tout ce qui va concerner la configuration d’OpenVPN va se retrouver dans son dossier d’installation qui est par défaut C:\Program Files\OpenVPN\, il faut donc se placer au préalable dedans.

Ensuite :

  1. Le serveur VNC sera démarré et coupé automatiquement lors des connexions et déconnexion du VPN. Pour ce faire, deux script seront exécutés dans chacun des cas. Créer le dossier script ainsi que les deux fichiers suivants à l’intérieur :
  • uvnc_start.bat: contenant :
	@echo off
	rem Permet au serveur VNC d'être lancé par OpenVPN
	cd "C:\Program Files\uvnc bvba\UltraVNC\"
	start winvnc.exe
  • uvnc_stop.bat: contenant :
	@echo off
	rem Permet au serveur VNC d'être stoppé par OpenVPN à la fin de la connexion
	cd "C:\Program Files\uvnc bvba\UltraVNC\"
	winvnc.exe -kill

  1. Récupérer tout le nécessaire à la connexion du client généré au préalable sur le serveur OpenVPN comme indiqué dans le partie Création du certificat pour les client, puis placer le tout dans le dossier keys.

  2. Dans le dossier config créer un fichier client.ovpn avec le contenus suivant :

	## Configuration OpenVPN pour client Windows
	# servant à crée le lien pour l'assistance à
	# distance.

	# Mode client
	client
	# Tunnel sur IP
	dev tun
	# Utilisation du protocole UDP
	proto udp
	# Adresse et port d'écoute du serveur
	remote [ma passerelle] 1194
	## Ne pas lier la connexion à une adresse et un port en particulier
	nobind
	# Se placer dans le dossier d'OpenVPN afin d'utiliser un chemin relatif
	# pour préciser l'emplacement des clés et scripts.
	cd "C:\\Program Files\\OpenVPN"
	# Certificat de la CA
	ca keys\\ca.crt
	# Clé privé de l'hôte
	key keys\\win8.key
	# Certificat de l'hôte
	cert keys\\win8.crt
	# Permet de signer les paquets réseau afin d'éviter les attaques DOS
	tls-auth keys\\ta.key 1
	# Utilise la complétion lzo pour les paquets transitant dans le tunnel
	comp-lzo
	# Niveau de verbosité convenable
	verb 3
	# Envoie un serveur un ping toutes les 20 secondes et ferme la connexion
	# si pas de réponse pendant 240 secondes
	keepalive 20 240
	# Permet l'exécution de script externe
	script-security 2
	# Démarre le service VNC la connexion
	up script\\uvnc_start.bat
	# Stop le service VNC a la déconnexion
	down script\\uvnc_stop.bat

Ne pas oublier de remplacer [ma passerelle] par l’adresse de votre serveur OpenVPN

Noter que pour M$ Windows, les séparateurs des dossiers dans le nom de chemin doivent être échappés, par exemple :
C:\\mon\\chemain\\mon_fichier.

  1. Faire que openvpn-gui.exe se lance automatiquement à chaque démarrage, entrer la commande suivante dans une invite de commande :
	reg ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v OpenVPN-gui /d "C:\Program Files\OpenVPN\bin\openvpn-gui.exe

Utilisation

  1. L’aidant et L’aidé se connectent tous deux au VPN.
  2. L’aidant prend le contrôle du poste aidé en utilisant son client VNC au travers du VPN.

Sur le poste aidé

Sous GNU/Linux

Voici la procédure pour qu’une personne active le VPN sur un poste aidé :

  1. Cliquer sur l’icône de l’applet de NetworkManager ; un menu s’affiche.
  2. Passer le pointeur de la souris sur Connexion VPN ; un sous-menu s’affiche.
  3. Initialiser la connexion en cliquant sur le nom de celle destiné à l’assistance à distance.
  4. Quand l’acte d’assistance est achevé, la personne retourne dans l’applet de NetworkManager, va dans Connexions VPN et clique sur “Déconnecter le VPN”.

Sous M$ Windows

Dans sa zone de notification, l’aidé dispose de l’icône OpenVPN GUI (celle ci peut être masqué, dans ce cas il faut cliquer sur la petite flèche pointant vers le haut juste à gauche de la zone de notification pour la faire apparaître), il effectue un clic droit dessus plus choisi Connecter. (Une fois la connexion établie l’icône d’UltraVNC apparaîtra dans la zone de notification car celui-ci sera lancé a la connexion au VPN.)

Quand c’est fini, la personne retournera faire un clic droit sur l’icône OpenVPN GUI dans la zone de notification et clique sur Déconnecter.(L’icône d’UltraVNC disparaîtra ensuite de la zone de notification car celui-ci sera terminé à la fermeture de la connexion au VPN.)

Sur le poste aidant

Configuration du client OpenVPN

Le client OpenVPN se configure de la même manière que pour les postes aidés à la différence qu’il faut faire le nécessaire sur le serveur pour que celui-ci puissent contacter les postes aidés comme indiqué dans la partie Permettre à un poste aidant de contacter les postes aidés.

Client VNC sous GNU/Linux avec ssvnc

Le client VNC sous GNU/Linux recommandé est ssvnc qui gère entre autre le transfert de fichier avec UltraVNC (ainsi que divers méthode d’encodage vidéo).

Une fois le client lancé :

  1. Dans la partie VNC Host:Display entrer l’IP de l’aidé au travers du VPN
  2. Sur l’avant dernière ligne, cocher le bouton radio None, puis cliquer sur Connect. Si le client est un client Windows, il faudra renter le mot de passe d’UltraVNC pour initialiser une session “prise de contrôle”.
  3. Afin d’avoir une connexion plus fluide je recommande quelques réglages sumplémentaires en allant dans Options... -> Advanced... -> Unix ssnvcviewer... puis de mettre à Encodings: tight et à Extra Options: -compresslevel 9 -quality 0.
  4. Une fois connecté, appuyer sur la touche pour ouvrir un menu permettant d’avoir accès à diverses options pour :
    • Choisir l’encodage utilisé ainsi que la profondeur des couleur.
    • Redimensionner l’affichage (Scale Viewer).
    • Lancer un transfert de fichier UltraVNC.

Pour M$/Windows

Non traité ici mais je suppose qu’avec le client VNC UltraVNC tout ce passera pour le mieux.

Astuce pour identifier facilement les postes aidés

Donner une IP fixe comme pour les postes aidants au poste aidé puis renseigner le fichier hosts sur le poste aidant en faisant correspondre des nom d’hôtes aux IP données au nom d’hôte du poste aidé…

Annexe Android

helpme impossible pour le moment directement sous android

Bien qu’une application openvpn Android libre existe il n’y a pas de serveur VNC exéption du proget droidVncServeur qui semble aparement abandoné.

La version de droidVncServer présente sur le play store et autres miroir apk posède un porblème avec les version récente d’android.

Je n’ai pas su compiler moi même l’application, il semble y avoir des erreurs de syntaxe dans le code :

$ ndk-build
...
jni/jpeg/jidctfst.S: Assembler messages:
jni/jpeg/jidctfst.S:66: Error: missing ')'
jni/jpeg/jidctfst.S:66: Error: garbage following instruction -- `pld (r2,#0)'
jni/jpeg/jidctfst.S:259: Error: missing ')'
jni/jpeg/jidctfst.S:259: Error: garbage following instruction -- `pld (sp,#32)'
jni/jpeg/jidctfst.S:271: Error: missing ')'
jni/jpeg/jidctfst.S:271: Error: garbage following instruction -- `pld (ip,#32)'
/usr/lib/android-ndk/build/core/build-binary.mk:473 : la recette pour la cible « obj/local/armeabi/objs/jpeg/jidctfst.o » a échouée
make: *** [obj/local/armeabi/objs/jpeg/jidctfst.o] Erreur 1

Solution de contournement avec Vysor

Dépend de code propriétaire et l’application est limité en usage en mode gratuit. A utliser seulement en cas de nécécité absolue.

Cette application permet de prendre le controle du smartphone à la manière de VLC depui l’ordinateur de l’utilisation en reliant de smartphone par cable USB à l’ordinateur. Il est essuite possible de conécter au PC de l’utlisateur via helpme puis d’administer le smartphone au travers.

Étape 1 activer de débogage USB sur le smartphone

  1. Aller dans les paramètre
  2. Aller dans “A propos du téléphone”
  3. Tapper 7 fois sur “Numéro de build” pour activer le menu “Option pour les dévloppeurs”
  4. Dans le paramètres, aller dans “Options pour les dévloppeurs”
  5. Dans “Options pour les dévloppeur” activer le “Débogage USB”.

Utliser Vysor sur le PC

Normalement Vysor s’optien en tant qu’aplication du navigateur web google chrom, mais sous GNU/Linux Vysor ne gerera pas l’affichage du smartphone si il est éxécuter depuis chromium. La solution ? Utliser electron comme indiqué sur le site de Vysor :

https://github.com/koush/vysor.io/issues/242

Ensuite la procédure d’instalation est décrite sur cette page :

https://github.com/koush/electron-chrome

La compilation de d’élécton requiert la dernière version de nodejs, se méfier du paquet de la distribution, voir ici pour des paquet avec le dernière vertion de nodejs pour Debian et dérivé :

https://github.com/nodesource/distributions

Pour finir

Une fois éléctron installé :

  • Éxécuter Vysor (dans le dossier ou il a été compilé exécuter `./node_module/.bin/electron --enable-logging . --app-id=gidgenkbbabolejbgbpnhbimgjbffefm)
  • Connecter le smartphone au PC et a la demande du smartphone autoriser le PC à y accèder (si le smartphone refuse l’accès au PC quant Vysor essai d’y accèder dans “Utliser la connexion USB pour” choisir “Recharger cet appareil”.
#2

Merci Maxime !

Pour avoir donné des cours à distance chaque semaine durant des années avec un système réalisé à partir de ce tutoriel, je confirme que cette solution est très efficace, légère (peu de délais malgré les connexions moisies de la campagne ornaise) et très facile d’utilisation pour la personne aidée. Enfin, uniquement basée sur des logiciels libres, on peut l’utiliser en toute confiance !

Ce serait vraiment cool que ce tuturiel soit repris par la communauté Yunohost afin qu’ils puissent le rendre accessible à tous les libristes qui se résignent à utiliser du privateur avec Teamviewer ou DWservice.

#3

À noter que j’utilise désormais le client VNC Remmina, et non plus ssvnc qui est cité sur le tuto de Maxime.

Remmina est par exemple présent dans les dépôts :

#4

Moi aussi, j’utilise maintenant Remmina, c’est la meilleur alternative que j’ai trouvé à SSVNC.

À noter que j’ai tout de même fait une erreur au niveau de la compatibilité de cette procédure avec les systèmes GNU/Linux récents : les versions récentes de Debian utilisent par défaut le serveur d’affichage Wayland plutôt que le vieillissant Xorg, or X11vnc ne fonctionne pas avec Xorg [Note de Nico: je pense que tu as voulu écrire Wayland].

Voyez donc ma procédure comme une approche pour traiter le problème plutôt que comme une solution toute faite.

Pour palier à ce problème une première solution consiste à utiliser
gnome-remote-desktop qui fonctionne bien mais n’est pas bien sécurisé.

Je pense que son utilisation doit se faire au travers d’un tunnel SSH, l’accès au port 5900 bloqué par le Firewall sauf pour localhost (surtout si les machines disposent d’une IPv6 directement accessible depuis internet). Le service ne doit pas forcément être activé par défaut mais peut l’être via la commande /usr/lib/gnome-remote-desktop/gnome-remote-desktop-daemon. Il ne possède pas beaucoup de paramètres de configuration pour le moment, il se paramètre via l’utilisation de dconf dans le chemin /org/gnome/desktop/remote-desktop/vnc. Pour que l’utilisateur autorise la connection plutôt via une boite de dialogue plutôt que de devoir fournir un de mot de passe (limité à 7 caractères dont pas franchement sécu), la clé /org/gnome/desktop/remote-desktop/vnc/auth-method doit valoir 'prompt'.

D’autres solutions sont à explorer, voir la page dédié sur le Wiki Archlinux.

J’envisage de tester ce que vaudrait l’utilisation d’un serveur RDP avec Wayland. Si quelqu’un a déjà testé, je veux bien quelques retours.

Enfin, actuellement, je n’utilise plus cette solution à base de VNC/OpenVPN pour effectuer de l’assistance à distance mais bien un bon vieux port forwaring SSH. Je peux démarrer automatiquement le serveur VNC sur le poste cible via la configuration SSH suivante (à placer dans le ~/.ssh/config) :

Host <alias pour la connexion>
        Hostname <ip public du poste cible>
        User <user>
        Port <port>
        # Tunneling ssh
        LocalForward 5990 localhost:5911
        RemoteCommand /usr/bin/x11vnc -localhost -rfbport 5911 -tightfilexfer -display :0 -gui

Une fois connecté via SSH au poste cible, je lance ma visionneuse VNC et je le connecte sur localhost:5990 ce qui débouche sur le poste cible à localhost:5911 la oà j’ai demandé au serveur VNC d’écouter via RemoteCommand.

Des tas de tutos existent sur le sujet, voici un pour l’exemple : https://doc.fedora-fr.org/wiki/Connexion_VNC_distante_sécurisée_en_mode_graphique_avec_SSH.

Par contre, cette méthode n’est pas non plus compatible avec l’utilisation de Wayland (je fais appel à X11vnc), de plus elle possède l’inconvénient de me donner un accès sans limite au poste cible sans que celui-ci soit forcément mis au courant du fait que je me connecte (ce qui est moyen en terme de confiance et d’éthique) et qu’il faille activer le NAT dans le routeur du poste cible (sauf si IPv6 directement accessible depuis internet). À noter que désormais, les FAI semblent attribuer toujours la même IPv4 à leur client, ce qui est très pratique pour ce genre de connexion.

Si d’autres ont leurs solutions testées, simples et efficaces pour faire de la prise en main graphique de poste client à distance je suis toujours preneur.