Lire les sockets TCP en écoute
Commande exécutée dans la VM : sudo ss -lntp. Options : -l écoute, -n valeurs numériques, -t TCP, -p processus. Exemple de sortie :
| Adresse locale | Processus | Interprétation |
|---|---|---|
127.0.0.53%lo:53, 127.0.0.54:53 | systemd-resolve, PID 833 | Points d’écoute de résolution DNS sur la boucle locale IPv4 ; %lo désigne l’interface loopback |
0.0.0.0:5355, [::]:5355 | systemd-resolve | Écoute TCP LLMNR sur toutes les adresses IPv4/IPv6 |
0.0.0.0:22, [::]:22 | sshd, PID 1094 | SSH écoute sur toutes les adresses IPv4/IPv6 |
*:9090 | systemd, PID 1 | Cohérent avec le socket Cockpit précédemment étudié ; confirmer le propriétaire logique avec systemctl status cockpit.socket |
0.0.0.0 signifie toutes les adresses IPv4 locales ; [::] toutes les adresses IPv6 locales. 127.0.0.x appartient à la boucle locale et ne désigne pas une adresse directement joignable depuis une autre machine. Peer Address ... :* ne représente pas une liste de clients connectés : ces sockets sont en écoute. Le script lab-demo n’apparaît pas car il n’ouvre pas de socket TCP d’écoute. Une écoute n’assure pas la joignabilité : vérifier aussi réseau et pare-feu. ss -lntp ne montre pas les écoutes UDP ; utiliser ss -lnup pour celles-ci.
Pour aller plus loin : confirmer cockpit.socket et distinguer un port détenu par systemd d’un processus applicatif déjà démarré.
Socket Cockpit après redémarrage
Exemple de sortie : cockpit.socket enabled et active (listening), écoute [::]:9090 (Stream), déclenche cockpit.service. Le service est inactive. C’est cohérent avec le PID 1 vu par ss : systemd maintient le socket d’écoute sans que le service applicatif soit déjà actif.
Pour aller plus loin : observer les connexions TCP établies avec ss -ntp state established, distinctes des sockets LISTEN, en utilisant la session SSH actuelle.
Connexion SSH établie : les deux extrémités
sudo ss -ntp state established a affiché : adresse locale 192.168.122.141:22, adresse distante 192.168.122.1:42992, Recv-Q et Send-Q à 0, processus sshd-session PID 1228 et 1207 partageant le descripteur du socket. La VM est le serveur SSH (port 22) ; Fedora utilise ici l’adresse du pont libvirt 192.168.122.1 et le port client temporaire 42992. Le port client peut changer à chaque connexion. Recv-Q à 0 signifie aucune donnée reçue en attente de lecture par l’application ; Send-Q à 0 signifie aucune donnée envoyée en attente d’acquittement TCP à cet instant. Ces valeurs ne mesurent pas le trafic cumulé.
Une connexion TCP est identifiée par les adresses et ports des deux extrémités (et le protocole). Depuis Fedora, la vue locale/distante serait inversée. Plusieurs processus associés au même socket ne prouvent pas plusieurs connexions.
Pour aller plus loin : comparer depuis le terminal Fedora physique, sans fermer la session SSH, avec ss -ntp state established et retrouver la ligne dont le pair est 192.168.122.141:22.
Vue de la connexion depuis Fedora
Comparer les sorties depuis la VM et depuis le poste client dans un second terminal : les extrémités locale et distante sont inversées. Pour distinguer écoute, connectivité et réponse applicative, comparer également une requête HTTPS locale et distante vers Cockpit.