Bonsoir à tous,
J’ai crée une machine virtuelle sur mon serveur à l’aide de Cockpit comme interface graphique, mais je n’arrive pas à y accéder à distance. J’ai essayé avec VNC-viewer et Remmina (que j’utilise au quotidien pour un VPS).
Pourtant l’accès par bureau distant dans l’onglet Partage de la VM est bien activé (Debian12 sous gnome) et j’ai bien récupéré la bonne adresse IP de la machine et utilisé le port (5900) afférent…
Quelqu’un pourrait m’éclairer? Merci d’avance.
Nicosss L’IP de la VM est dans le même sous-réseau que la machine qui essaye de la contacter ?
Pas tout à fait… 😃
Mais bon, ça c’est quand je configure la connexion de la VM en réseau virtuel ou bridge.
J’ai essayé en attachement direct sur la carte ethernet et là j’ai bien une adresse en 192.168.1.x sur ma VM, mais ça ne fonctionne pas non plus.
Nicosss Tu as regardé si SELinux ne bloquait pas quelque chose ?
Côté serveur ou client?
À priori non, je ne vois rien dans le journalctl, mais peut-être que j’ai mal cherché 🤔
que donne
# nmap -sT 192.168.122.xx
Nicosss C’est bien configuré pour te demander un mot de passe et non attendre une autorisation distante ?
Qu’entends-tu par autorisation distante?
C’est configuré dans Remmina pour un accès distant par login utilisateur et mot de passe, sans tunnel ssh.
J’ai réussi hier soir finalement à accéder au bureau distant (en RDP) à condition de mettre l’interface de la VM directement sur la carte réseau et en changeant le sous-réseau de celle-ci (192.168.122.0/24) vers celui de mon serveur et de mon pc portable (192.168.1.0/24).
Donc je suis quasiment sûr qu’il s’agit d’un problème de routage entre les deux sous-réseaux. Et je ne me rappelle plus comment il fallait procéder pour configurer cela, je n’ai pas touché à ce genre de choses depuis un bail maintenant…
L’idée est de configurer le routage entre la carte réseau du serveur sur un premier sous-réseau (enp2s0 @ 192.168.1.0/24) et le bridge associé (virbr0 @ 192.168.122.0/24) qui lui va distribuer ensuite les paquets destinés à chaque machine virtuelle.
Donc si quelqu’un pouvait m’expliquer succintement, ou si c’est trop long me donner un lien vers un tutoriel bien sûr.
Autre question, si je souhaite me connecter en vnc côté client, dois-je impérativement installer un serveur vnc côté serveur? Ou bien Fedora server intègre-t’il déjà d’origine ce qu’il faut pour cela? Je pose la question parce que sur ce coup je ne suis plus trop sûr de rien. Dans Cockpit il est clairement indiqué qu’il suffit d’installer un afficheur de bureau côté client et de récupérer l’adresse de connexion, alors que lorsque je cherche le moindre serveur vnc installé avec la commande dnf il n’y a rien, donc ça me parait bizarre…
Même question avec spice, sauf que pour le coup il y a bien un paquet spice-server installé.
fgland que donne
# nmap -sT 192.168.122.xx
sur le terminal du serveur :
[gogi@fedoraserver ~]$ nmap -sT 192.168.122.178
Starting Nmap 7.93 ( https://nmap.org ) at 2023-09-30 16:36 CEST
Nmap scan report for 192.168.122.178
Host is up (0.00012s latency).
Not shown: 999 closed tcp ports (conn-refused)
PORT STATE SERVICE
3389/tcp open ms-wbt-server
Nmap done: 1 IP address (1 host up) scanned in 0.26 secondsdonc ça marche bien, et ça paraît logique,
et sur le terminal de mon pc portable : rien. 😃
Edit Nicosss : Correction des balises Markdown -> Voir FAQ
sauf que je vois pas de port vnc 5900 ouvert, problème de départ.
Il faut que le port soit ouvert mais il faut aussi qu’il y a un programme à l’écoute et c’est lui qui gérera les droits.
Sous kde il y a krfb, dans les dépôt il y a aussi giver que je ne connais et qui ne me semble pas actif (2007).
Krfb a très peu de dépendance, on peu l’utiliser dans d’autres environnements graphiques
GOGI Merci de faire attention aux balises Markdown pour faciliter la lecture -> Voir FAQ . J’ai corrigé dans ton message.
GOGI Qu’entends-tu par autorisation distante?
Côté serveur, l’accès est par mot de passe ou il faut que quelqu’un côté serveur autorise l’accès. Mais désormais le souci est réglé comme tu n’es pas sous le même sous-réseau.
C’est ce que je te précisait plus haut concernant les sous-réseaux. Je n’ai rien sous le coude à te proposer pour le moment.
Pour VNC, oui il faudra un serveur VNC sur le serveur. Mais une connexion RDP est très bien aussi.
fgland sauf que je vois pas de port vnc 5900 ouvert, problème de départ.
Il faut que le port soit ouvert mais il faut aussi qu’il y a un programme à l’écoute et c’est lui qui gérera les droits.
Sous kde il y a krfb, dans les dépôt il y a aussi giver que je ne connais et qui ne me semble pas actif (2007).
Krfb a très peu de dépendance, on peu l’utiliser dans d’autres environnements graphiquesNicosss fgland Il utilise une connexion RDP donc port 3389/tcp et il est bien ouvert.
@ fgland n’a pas tort à 100%, ou alors j’ai mal utilisé et/ou interprété la commande…
Il est vrai que sa commande utilise le port 3389/tcp, tout comme la connexion RDP que j’ai réussi à établir hier soir, donc là ça marche.
Par contre j’ai essayé cette commande depuis le terminal du serveur :
[gogi@fedoraserver ~]$ nmap -sT 192.168.122.178 -p 5900
Starting Nmap 7.93 ( https://nmap.org ) at 2023-09-30 17:38 CEST
Nmap scan report for 192.168.122.178
Host is up (0.00028s latency).
PORT STATE SERVICE
5900/tcp closed vnc
Nmap done: 1 IP address (1 host up) scanned in 0.09 secondset là on voit que le port 5900/tcp semble fermé sur la machine correspondant à l’adresse 192.168.122.178…
Pourtant ce que je ne comprends pas, c’est que c’est une machine Debian, et sur Debian par défaut il n’y a pas de filtrage de port.
P.S. : désolé j’ai encore du mal avec les nouvelles balises de forum, j’essaie de m’y faire.
Nicosss Côté serveur, l’accès est par mot de passe ou il faut que quelqu’un côté serveur autorise l’accès. Mais désormais le souci est réglé comme tu n’es pas sous le même sous-réseau.
C’est ce que je te précisait plus haut concernant les sous-réseaux. Je n’ai rien sous le coude à te proposer pour le moment.
Merci quand même, je vais continuer à chercher dans ce sens de toute façon. Je ne me rappelle plus comment ça se faisait, mais je vais bien finir par retrouver. J’avais fait ça à l’époque où je cherchais à comprendre comment fonctionnait un serveur DNS et que j’avais monté mon propre serveur avec Bind9 dans un container nspawn, mais ça date et quand on ne pratique pas régulièrement ça finit par s’enfouir profondément dans la mémoire… 😃
Nicosss Pour VNC, oui il faudra un serveur VNC sur le serveur. Mais une connexion RDP est très bien aussi.
De toute façon, il faut déjà que je puisse contacter la machine virtuelle pour commencer. Pour l’instant, pas de ping ce qui serait la base…
Une fois que j’aurai le ping, peut importe le type de connexion, rdp, spice, vnc voire même ssh en CLI, ça devrait marcher…
Mais cette histoire de serveur VNC non installé côté serveur par défaut alors que c’est le mode de connexion officiel qui est proposé lui par défaut dans l’application “Machines Virtuelles” de Cockpit me laisse dubitatif. Ça me parait pas logique.
Sauf erreur de ma part, le serveur vnc par défaut est lié au bureau : partage de bureau. Dans le cas d’un serveur qui n’a pas de session ouverte, il n’ a pas de bureau gérant le partage ! Dans ton cas il faut se connecter en graphique à un serveur distant, ce que fait RDS.
Suivant les besoins, un tunel ssh pourrait être suffisant ou une connexion avec ssh – x mais cela suppose que le serveur distant tourne sur x11 ou X2go en fonction des environnements graphiques installé sur le serveur
Si le port 5900 avait été ouvert la commande nmap – sT 192.168.122.178 l’aurait montré en même temps que 3389 mais il aurait sans doute été aussi fermé car pas de programme à l’écoute.
J’espère ne pas avoir été trop confus
tu parles pour Fedora en général ou pour l’objet de ce fil ? Il a résolu son problème en changeant de porte mais il me semble important de comprendre pourquoi cela n’a pas marché avec son premier essai en vnc. Personne n’a soulevé cette absence de bureau partagé sur le serveur distant.
Je viens de faire une connexion vnc sur une VM Fedora34 en gardant l’adresse et le routage par défaut 192.168.122.27 sur un bureau LXDE en utilisant Remmina car cela ne marche pas avec le Visionneur de bureaux distants de gnome.
Le problème n’est donc pas dans le routage.
fgland Je parle à minima de la variante Workstation de Fedora Linux donc avec Gnome et ce qu’il propose en terme de partage de bureau. Pour sa Debian c’est bien le protocole RDP qui est utilisé aussi car on retrouve 3389/tcp open ms-wbt-server .
D’ailleurs la commande suivante le confirmera
$ netstat -laputen | grep gnome-remote
Fedora Linux 34 avec LXDE doit potentiellement encore utiliser VNC.
Je viens de faire un essai depuis F39 Beta et Vinagre semble avoir quelques bugs car je n’ai pas réussi à avoir le bureau mais aucun souci avec Remmina pour me connecter sur une VM F38 (192.168.122.181) créée avec Gnome Boxes sur un même machine..
Il faudrait que @GOGI précise son architecture.
fgland Sauf erreur de ma part, le serveur vnc par défaut est lié au bureau : partage de bureau. Dans le cas d’un serveur qui n’a pas de session ouverte, il n’ a pas de bureau gérant le partage ! Dans ton cas il faut se connecter en graphique à un serveur distant, ce que fait RDS.
On est d’accord. pas de bureau, pas de partage, comme c’est le cas avec mon serveur : connexion en console ou ssh.
Ici ce que j’essaie de faire marcher, c’est la connexion par bureau à distance sur des machines virtuelles avec bureau : Fedora Workstation, Debian, Windows 11…
@fgland Suivant les besoins, un tunel ssh pourrait être suffisant ou une connexion avec ssh – x mais cela suppose que le serveur distant tourne sur x11 ou X2go en fonction des environnements graphiques installé sur le serveur
C’est vrai, mais pour l’instant ça ne marche pas non plus. 😃
@fgland Si le port 5900 avait été ouvert la commande nmap – sT 192.168.122.178 l’aurait montré en même temps que 3389 mais il aurait sans doute été aussi fermé car pas de programme à l’écoute.
J’espère ne pas avoir été trop confus
J’ai tenté en ouvrant les ports temporairement à travers Cockpit dans la zone “public” et la zone “libvirt” et effectivement il apparaissait fermé car pas de programme à l’écoute. Mais de toute façon ça n’a pas marché non plus.
@Nicosss C’est désormais un serveur RDP et non plus VNC de base. D’où l’adresse de connexion ms-rd://
Effectivement, du coup j’ai abandonné VNC pour l’instant. D’ailleurs quelle différence concrète entre VNC et RDP, je veux dire à l’usage lequel est le mieux?
@fgland tu parles pour Fedora en général ou pour l’objet de ce fil ? Il a résolu son problème en changeant de porte mais il me semble important de comprendre pourquoi cela n’a pas marché avec son premier essai en vnc. Personne n’a soulevé cette absence de bureau partagé sur le serveur distant.
Oh non, le problème n’est pas résolu pour moi tant que je n’aurai pas trouvé pourquoi ça ne fonctionne pas avec le bridge “virbr0” par défaut de libvirt. Je tiens absolument comme toi à comprendre pourquoi ça ne marche pas et j’ai bien l’intention de creuser jusqu’au bout. C’est la meilleur façon d’apprendre.
Mais je ne vois pas le rapport avec ton histoire de bureau absent sur le serveur distant? Je n’essaie pas de me connecter à mon serveur qui heberge mes machines virtuelles mais aux machines virtuelles qui elles ont bien un environnement graphique.
@fgland Je viens de faire une connexion vnc sur une VM Fedora34 en gardant l’adresse et le routage par défaut 192.168.122.27 sur un bureau LXDE en utilisant Remmina car cela ne marche pas avec le Visionneur de bureaux distants de gnome.
Le problème n’est donc pas dans le routage.
C’est exactement ce que j’essaie de faire depuis deux jours, avec Remmina, mais ça ne marche ni en RDP ni en VNC, en tous cas pas avec le bridge “virbr0”. Si je mets la machine en attachement direct sur la carte réseau, alors ça marche mais c’est normal puisqu’alors la machine virtuelle se retrouve sur le sous-reseau 192.168.1.X/24, là où est le serveur, la box, mon pc portable… donc tout va bien. Le bridge et toutes les machines virtuelles qui viennent derrière sont sur le sous-réseau 192.168.122.X/24, comme dans l’exemple que tu donnes ci-dessus, mais chez moi ça ne se connecte pas… Une question : ton test avec la connexion VNC, tu l’as fait avec la machine virtuelle et la machine distance sur la même machine physique?
Pour moi, dans mon cas il y a un problème au niveau du routage peut-être, probablement, mais surtout au niveau du bridge virbr0 ça c’est sûr. Je vais expliquer plus bas pourquoi je dis ça.
@Nicosss Je viens de faire un essai depuis F39 Beta et Vinagre semble avoir quelques bugs car je n’ai pas réussi à avoir le bureau mais aucun souci avec Remmina pour me connecter sur une VM F38 (192.168.122.181) créée avec Gnome Boxes sur un même machine..
Comme dit juste avant à @fgland , vos tests se font sur une même machine, peut-être que mon problème est là, certainement, quelque part..
Bon voilà j’ai essayé de vous répondre le plus précisément possible à vos messages avant de reprendre le fil de la discussion.
Donc pour revenir à nos moutons, puisque j’ai également fait beaucoup de tests aujourd’hui sur les machines en question et que je ne sais moi-même plus ce que j’ai fait ou pas, je vais reprendre du début.
Je suis à la maison derrière une Freebox, avec un pc portable sous Fedora Workstation 38 et une tour qui fait office de serveur sous Fedora Server 38.
Sur ce serveur j’ai installé trois machines virtuelles (pour tester le fonctionnement avant que ça ne me serve de production plus tard), une Debian12, une Fedora Workstation 38 et une Windows 11.
Lorsque ces machines sont reliées sur le réseau via le bridge virbr0, je ne peux pas me connecter à distance.
Lorsqu’elles sont reliées en attachement direct à l’interface du serveur ça fonctionne…
Je vais faire un schéma pour que ce soit plus clair.