Vérification Prise en main à distance
S'applique à : Medulla - Medulla relai
Version : Toutes
Environnement : On-Premise
Catégorie : PMAD
Workflow
Logs
- /var/log/apache2/*.log
- /var/log/mmc/mmc-agent.log
- /var/log/pulse/xmpp-agent-relay.log
- /var/log/mmc/master-mast.log
- C:\Program Files\Medulla\var\log\xmpp-agent-machine.log
- /var/log/tomcat9/*.log
- /var/log/tomcat9/*.txt
- journalctl -u guacd -f
Opérations de debug
- Lister les connexions guacamole enregistrées pour une machine :
USE xmppmaster;
SELECT jid,
hostname,
machine_id,
idguacamole,
protocol
FROM machines
JOIN has_guacamole
ON machines.id = has_guacamole.machine_id
WHERE jid like '%nom_machine%';
Voici un exemple de retour :
+-------------------------------------------+-------------+------------+-------------+----------+
| jid | hostname | machine_id | idguacamole | protocol |
+-------------------------------------------+-------------+------------+-------------+----------+
| nom_machine.7wg@server-ars01/bc241109f61e | nom_machine | 23 | 386 | SSH |
| nom_machine.7wg@server-ars01/bc241109f61e | nom_machine | 23 | 387 | VNC |
| nom_machine.7wg@server-ars01/bc241109f61e | nom_machine | 23 | 388 | RDP |
+-------------------------------------------+-------------+------------+-------------+----------+
Si la connexion n'existe pas, relancer un enregistrement de la machine.
Si après un re-enregistrement toujours pas de connexion, sur la machine cliente, vérifier que les protocoles sont bien activés (VNC lancé, RDP activé, démon OpenSSH lancé).
- Afficher le détail d'une connexion (se fait sur le relais de la machine)
USE guacamole;
SELECT guacamole_connection.protocol as protocol,
guacamole_connection.connection_id as connection_id,
parameter_name,
parameter_value
FROM guacamole_connection_parameter
JOIN guacamole_connection
ON guacamole_connection_parameter.connection_id = guacamole_connection.connection_id
where guacamole_connection.connection_id = 387;
Pour la dernière ligne de la requête SQL ci-dessus, prendre l'ID (idguacamole) de la connexion en cours trouvé dans le résultat de la 1ère requête, ici 387, car le test est réalisé sur une connexion VNC.
Si vous disposez d'un relai, la requête SQL ci-dessus doit être réalisée sur le relai sur lequel est connectée la machine.
Voici un exemple de retour :
+----------+---------------+----------------+-----------------+
| protocol | connection_id | parameter_name | parameter_value |
+----------+---------------+----------------+-----------------+
| vnc | 387 | color-depth | 24 |
| vnc | 387 | hostname | localhost |
| vnc | 387 | password | xxxxxxxx |
| vnc | 387 | port | 60381 |
+----------+---------------+----------------+-----------------+
- Vérification du reverse
S'il y a une connexion qui est faite (hostname = localhost), vérifier l'établissement de la connexion sur le relai sur lequel la machine est connectée :
netstat -vatpn | grep <port>
Exemple de retour :
tcp 0 0 0.0.0.0:60381 0.0.0.0:* LISTEN 420161/sshd: revers
tcp6 0 0 :::60381 :::* LISTEN 420161/sshd: revers
tcp6 0 0 ::1:44178 ::1:60381 ESTABLISHED 420167/guacd
tcp6 0 0 ::1:60381 ::1:44178 ESTABLISHED 420161/sshd: revers
Il y a ensuite une redirection du port de guacd sur le serveur dans le tunnel. Cette redirection est faite lors du montage du reverse.
Vérifiez bien également la présence d'une ligne guacd en plus des lignes revers.
Si aucune ligne revers n'est affichée, il faut debugguer le reversessh :
SUPPORT - Reverse SSH - Support
SUPPORT - Reverse SSH - Support
- Debug du VNC
Sur la machine cliente vérifier que le serveur VNC est en écoute:
netstat -an | find "5900"
Si ce n'est pas le cas, vérifier l'exécution de TightVNC
Sur la machine cliente vérifier que le reverse ssh soit bien fait:
Sur la machine cliente vérifier que le reverse ssh soit bien fait:
netstat | find "ssh"
Sur le relais vérifier que le reverse ssh soit bien établi:
netstat -vatpn |grep sshd
Attention le reverse s'établit sur un port aléatoire.
