Guide des ports VNC : accès au bureau à distance sur le port 5900

VNC permet à un spectateur de contrôler un bureau graphique distant sur le réseau. Le spectateur se connecte à un serveur VNC, négocie le protocole RFB, s'authentifie, puis échange les mises à jour d'écran, les entrées au clavier, à la souris, les données du presse-papiers et parfois les fonctionnalités de transfert de fichiers en fonction de l'implémentation du serveur.

VNC est utilisé pour les postes de travail Linux, le partage d'écran macOS, les systèmes embarqués, les machines de laboratoire, les hôtes de saut et l'assistance à distance. Différentes implémentations telles que TigerVNC, TightVNC, RealVNC, UltraVNC, x11vnc et noVNC peuvent utiliser différentes valeurs par défaut et options de sécurité, donc vérifiez toujours l'écouteur et la configuration réels.

Le port VNC habituel est TCP 5900 pour l'affichage :0. La notation d'affichage VNC traditionnelle ajoute le numéro d'affichage à 5900, ce qui signifie :1 correspond à 5901, :2 correspond à 5902, et ainsi de suite. Certains visualiseurs permettent aux utilisateurs de saisir soit host:5901, soit host:1 en fonction de l'interface client.

Ne présumez pas que chaque serveur VNC suit la convention d'affichage. De nombreux serveurs peuvent être configurés avec un port TCP personnalisé, un mode de connexion inversée, un proxy Web ou un tunnel SSH. Utilisez les paramètres du serveur, les règles de pare-feu et les vérifications des écouteurs pour confirmer le port réel.

VNC, RDP et SSH résolvent différents problèmes d'accès à distance. VNC partage ou crée un bureau graphique à l'aide du protocole RFB, généralement sur le port 5900. RDP est Microsoft Remote Desktop et utilise généralement le port 3389. SSH est un protocole shell sécurisé sur le port 22 et est souvent utilisé pour créer des tunnels pour VNC.

Pour les flux de travail de bureau à distance Windows, RDP est généralement plus intégré. Pour un accès graphique multiplateforme, VNC est flexible. Pour une administration sécurisée, SSH constitue souvent le chemin d'accès externe le plus sûr, en particulier lorsque VNC lui-même est lié à l'hôte local et atteint via un tunnel SSH.

Ouvrez VNC uniquement lorsqu'un utilisateur de confiance, un outil d'assistance, un flux de travail d'automatisation, un réseau de laboratoire ou un chemin de gestion privé a besoin d'un accès graphique au bureau à distance. Les cas courants incluent la prise en charge des postes de travail Linux à distance, la maintenance des kiosques, la gestion des appareils intégrés et l'accès aux laboratoires privés.

Évitez d’ouvrir VNC sur l’ensemble d’Internet. Un port VNC public peut attirer des tentatives de force brute, des attaques par mot de passe faible, des tentatives de prise de contrôle de bureau et une recherche de serveurs plus anciens. Si un accès à distance est requis, placez VNC derrière un VPN, un tunnel SSH, une couche d'accès zéro confiance, un bastion ou une liste blanche d'IP source.

Vérifiez d'abord quel serveur VNC est en cours d'exécution, sur quelle interface il écoute et quel écran ou port TCP il utilise. Autorisez ensuite le port exact uniquement à partir de réseaux sources fiables. Pour l'affichage :0, il s'agit généralement de TCP 5900 ; pour display :1 il s'agit souvent de TCP 5901.

Sur un routeur, transférez le port externe vers l'hôte VNC interne uniquement si vous avez une bonne raison et une politique de source étroite. Sur les serveurs, alignez le pare-feu hôte, le groupe de sécurité cloud, la stratégie VPN et l'adresse de liaison du serveur VNC afin que le service soit accessible uniquement via le chemin prévu.

Commencez par une vérification du port externe par rapport au nom d'hôte public ou à l'adresse IP et au port 5900, ou au port VNC personnalisé que vous avez configuré. Si le port est ouvert, un client distant peut atteindre un écouteur TCP. Testez ensuite avec un véritable visualiseur VNC pour confirmer la négociation du protocole, l'authentification, l'accès au bureau et les mises à jour de l'écran.

Sur le serveur, vérifiez les écouteurs avec ss, netstat, lsof, PowerShell ou la page d'état du serveur VNC. Si VNC est tunnelisé via SSH, testez d'abord la connexion SSH, puis confirmez le port transféré local et la cible de la visionneuse.

Si le port VNC est fermé, le serveur peut être arrêté, lié uniquement à localhost, écoutant sur un autre écran ou bloqué par le pare-feu de l'hôte. Si la vérification expire, un routeur, un pare-feu cloud, une politique VPN, un filtre FAI ou une restriction IP source peuvent supprimer des paquets avant qu'ils n'atteignent l'hôte.

Si le port est ouvert mais que la visionneuse ne peut pas se connecter, vérifiez le numéro d'affichage, la version du protocole, la politique de mot de passe, les exigences de cryptage, les règles d'accès côté serveur, l'état de la session du bureau et si le serveur VNC autorise les connexions à partir du réseau de la visionneuse. Certains serveurs rejettent les clients lorsqu'aucune session de bureau n'est disponible.

Ne comptez pas uniquement sur un mot de passe VNC pour accéder à Internet. Préférez les tunnels VPN, SSH, les réseaux privés ou l'accès zéro confiance, et liez VNC à l'hôte local lors du tunneling. Utilisez des informations d'identification uniques et solides, désactivez les comptes inutilisés et maintenez le serveur VNC corrigé.

Activez le cryptage lorsque le serveur et la visionneuse le prennent en charge, limitez les adresses IP sources, surveillez les échecs de connexion et vérifiez si le presse-papiers, le transfert de fichiers ou l'accès sans surveillance doivent être désactivés. Traitez VNC comme un accès complet au bureau, et non comme un simple point de terminaison d'état.