Les 5 principaux problèmes de connectivité de bureau à distance et la manière de les prévenir

1. Défaillance réseau

La défaillance du réseau sous-jacent constitue le problème de bureau à distance le plus répandu. Pour vérifier la connectivité, raccordez un ordinateur portable au port réseau depuis lequel l’utilisateur tente de se connecter, puis utilisez une commande Ping ou Tracert pour déterminer l’état de la connexion au serveur hôte ou au broker de connexion. N’oubliez pas, cependant, que cette façon de tester la connectivité de votre bureau à distance ne fonctionne que si vous autorisez les paquets ICMP à franchir les pare-feux de votre réseau.

Si l’utilisateur qui rencontre le problème est connecté via un réseau privé virtuel (VPN ; Virtual Private Network) ou une passerelle TS (Terminal Services), ledit problème peut venir de la machine de l’utilisateur, du VPN ou de la passerelle, ou encore de votre infrastructure de bureau à distance. Dans ces cas de figure, pour diagnostiquer un problème de bureau à distance, vous devez procéder par élimination. Par exemple, essayez de vous connecter au VPN au moyen d’un ordinateur client correctement configuré et d’un compte d’utilisateur fiable, afin de déterminer si vous pouvez établir une connexion de bureau à distance.

2. Problèmes de pare-feu

On oublie souvent qu’un pare-feu peut contribuer à des problèmes de connexion de bureau à distance ; pourtant, c’est assez souvent le cas. Pour éviter les problèmes liés au pare-feu, assurez-vous que le port qu’utilise votre logiciel de bureau à distance est bien ouvert sur tous les pare-feux actifs entre les ordinateurs clients et le serveur auxquels ils se connectent.

La difficulté tient au fait que vous pouvez être amené à configurer plusieurs pare-feux. Ainsi, le client et le serveur peuvent, tous deux, exécuter le Pare-feu Windows ; ou encore, plusieurs pare-feux matériels peuvent être installés entre les deux systèmes. Qui plus est, le numéro du port qui doit être ouvert sur les pare-feux diffère d’un produit d’infrastructure de bureau virtuel, ou VDI (Virtual Desktop Infrastructure), à l’autre. (Si vous utilisez un outil qui est basé sur le protocole de bureau à distance RDP - Remote Desktop Protocol -, cet outil utilisera par défaut le port 3389.)

3. Problèmes de certificat SSL

Les certificats de sécurité peuvent également engendrer des problèmes de connectivité de bureau à distance. Nombre de produits VDI utilisent le cryptage SSL (Secure Sockets Layer) lorsque des utilisateurs accèdent à des sessions VDI hors du périmètre réseau. Mais attention, le cryptage SSL nécessite l’utilisation de certificats ; un fonctionnement qui fait entrer en ligne de compte deux problèmes liés aux bureaux à distance.

Tout d’abord, pour que les bureaux à distance se connectent correctement, les ordinateurs clients doivent approuver l’autorité de certification qui émet le certificat. Cette approbation ne pose généralement aucun problème aux organisations qui achètent leurs certificats auprès d’autorités largement reconnues. En revanche, les clients n’approuvent pas toujours les certificats qu’une organisation génère en interne. Aussi, pour garantir la connectivité de bureau à distance qu’établissent vos clients, utilisez une autorité de certification « fiable ».

Parallèlement, les clients doivent pouvoir vérifier le certificat qu’utilise le serveur. Et le processus de vérification peut s’interrompre en cas d’expiration dudit certificat, ou si le nom qui figure sur ce dernier ne correspond pas au nom du serveur qui l’utilise. Aussi, veillez à tenir vos certificats à jour.

4. Authentification au niveau du réseau

Sous Windows Server 2008 R2, le protocole Microsoft Remote Desktop Services (RDS) est conçu pour exploiter une fonction de sécurité nommée « authentification au niveau du réseau » (Network Level Authentication). L’idée fondamentale est que l’hôte de la session doit authentifier l’utilisateur avant l’établissement d’une session. Non seulement l’authentification au niveau du réseau améliore la sécurité, mais elle contribue à diminuer la quantité de ressources VDI que la session sollicite.

L’authentification au niveau du réseau peut empêcher des problèmes de connexion de bureau à distance susceptibles de se produire ultérieurement au cours de la session, mais tous les clients de bureau à distance ne la prennent pas en charge.

Si vous utilisez des clients Microsoft et souhaitez savoir s’ils assurent cette prise en charge, il vous suffit de cliquer sur l’icône de cette fonction, placée dans le coin supérieur gauche du menu « Connexion Bureau à distance », puis de choisir « À propos de » dans le menu qui se présente. Le client spécifie explicitement s’il prend en charge l’authentification au niveau du réseau de Microsoft.

Si aucun message ne spécifie que votre client prend en charge ce type d’authentification, vous pouvez soit procéder à la mise à jour du composant client, soit désactiver l’exigence d’authentification au niveau du réseau sur vos serveurs VDI. N’oubliez pas que l’authentification au niveau du réseau s’active aussi parfois via les paramètres de politique de groupe.

5. Dépassement de capacité

Enfin, vous pouvez rencontrer des problèmes de connectivité de bureau à distance si vous dépassez la capacité de l’infrastructure ; peut-être parce que vous ne disposez plus de suffisamment de bureaux virtuels ou de licences VDI. Par ailleurs, certaines mises en œuvre VDI refusent les connexions clientes dès lors que le serveur est trop occupé, ou lorsque le lancement d’une session de bureau virtuel supplémentaire est susceptible d’affaiblir les performances des sessions déjà en cours.

La majorité de ces problèmes de connexion de bureau à distance peut être évitée par une simple planification préalable. Assurez-vous que vos certificats SSL sont bien à jour, configurez correctement vos pare-feux et surveillez constamment votre capacité VDI.

L’auteur

Certifié MCSE, Brien M. Posey compte parmi les MVP (Microsoft most Valuable Professional) pour ses travaux sur Windows 2000 Server et IIS. Il a officié comme DSI pour une chaine d’hôpitaux nationale, et a été responsable de la sécurité informatique de Fort Knox. Rédacteur technique indépendant, Brien M. Posey travaille pour différentes entreprises du secteur des technologies, notamment Microsoft, TechTarget, MSD2D et Relevant Technologies.