Réseau sous Linux

Les nœuds Proxmox et les VM du lab s’administrent surtout à distance. Quand une machine ne répond plus en SSH, ou qu’une VM neuve n’a pas d’IP, le diagnostic commence sur la machine elle-même (console Proxmox) avec les outils réseau de base — pas dans UniFi, pas dans Kubernetes. Cette page rassemble ce que j’utilise pour voir les interfaces, coller une adresse de test, vérifier routes et DNS, puis revenir en SSH une fois le lien rétabli. Pour la segmentation VLAN et le firewall, le détail est dans le guide UniFi ; ici on reste au niveau Linux.

Nom d’hôte et interfaces

Le hostname identifie la machine sur le réseau et dans les logs. hostnamectl affiche l’état actuel ; le fichier /etc/hostname fixe le nom au boot. Ensuite on liste ce que le noyau a détecté : ls /sys/class/net/, ip link, ip addr. Les noms modernes (enp0s31f6, ens18) ont remplacé le classique eth0 sur beaucoup de installs — d’où l’intérêt de ne pas coller une commande trouvée sur un vieux tutoriel sans vérifier l’interface réelle. Si une carte n’apparaît pas, dmesg (filtré sur le driver) raconte souvent si le module a chargé ou non.

hostnamectl
ls /sys/class/net/
ip link
ip addr

Adresse IP et routes

L’outil actuel, c’est iproute2 (ip), pas ifconfig. On peut ajouter une adresse et monter l’interface pour un test immédiat — utile sur une console quand le DHCP a échoué — en sachant que ces changements sont volatils : au reboot, seule la config persistante compte (ifupdown /etc/network/interfaces, netplan, NetworkManager, ou la conf réseau Proxmox selon le cas). Mélanger les outils sur le même hôte est une bonne façon d’avoir une IP « fantôme » qui disparaît au prochain redémarrage.

sudo ip addr add 192.168.50.10/24 dev ens18
sudo ip link set ens18 up
ip route show
sudo ip route add default via 192.168.50.1

La route par défaut et les routes VLAN déterminent si tu sors vers Internet ou vers un autre segment du lab. Quand le WoL ou un service « ne marche pas d’un VLAN à l’autre », je vérifie d’abord ici, puis les règles UniFi — dans cet ordre, pour ne pas accuser le firewall alors que la machine n’a tout simplement pas de gateway.

DNS et SSH

La résolution de noms passe en général par /etc/resolv.conf (souvent géré par un service) et éventuellement /etc/hosts pour des overrides locaux. Chez moi, les VLAN pointent vers Pi-hole : si une résolution casse après un changement de réseau, je regarde le DNS du VLAN avant de soupçonner l’application. getent hosts … ou un simple ping / curl suffisent pour trancher.

cat /etc/resolv.conf
getent hosts mon-service.lab
ssh [email protected]

SSH est le chemin normal une fois l’IP et le DNS stables. Clés plutôt que mots de passe dès que la machine est durable ; depuis le lab, l’accès suit la segmentation (VLAN admin / trusted) décrite dans le guide UniFi. Quand SSH refuse la connexion, la page Activité système complète le tableau : logs d’auth, processus, ports en écoute avec ss.