Perte du réseau sur la machine

« Le réseau est tombé » recouvre deux cas différents : rien n'atteint la machine depuis l'extérieur, et la machine elle-même ne peut rien atteindre. Commencez par la console, car SSH est indisponible dans cette situation, et la console fonctionne toujours — elle est reliée directement à la machine, en contournant le réseau.

Étape 1. Entrer par la console

Ouvrez /hosting/vds/m/<id>, l'onglet « Console ». La console texte (port série) fonctionne pour toutes les commandes ; « Screen » (VNC) est nécessaire si le système n'affiche pas d'invite sur la ligne série. Si la console affiche une invite de connexion, la machine est vivante et le problème vient du réseau, pas du démarrage.

Si aucune invite n'apparaît et que « Screen » affiche un message d'erreur du noyau, consultez Kernel panic : que faire ensuite.

Étape 2. Vérifier l'interface et l'adresse

ip -brief address
ip route

L'interface doit porter votre adresse IPv4 publique de l'onglet « Overview », et les routes doivent contenir une ligne default via .... Constats fréquents :

• l'interface est à l'état DOWN — activez-la : ip link set dev ens18 up ;
• l'adresse a disparu après une modification manuelle de la configuration — restaurez le fichier de paramètres et redémarrez le service réseau (systemctl restart systemd-networkd ou netplan apply sur Ubuntu) ;
• il n'y a pas de route par défaut — restaurez-la temporairement avec ip route add default via <gateway> pour retrouver l'accès, puis corrigez la configuration, sinon le problème se reproduira après un redémarrage.

Les modifications faites via ip ne durent que jusqu'au redémarrage. La vraie correction se fait toujours dans le fichier de configuration.

Étape 3. Distinguer « pas de connectivité » de « pas de noms »

ping -c3 1.1.1.1
ping -c3 millida.net

Si l'adresse répond au ping mais pas le nom, le réseau est correct et la résolution de noms est cassée : passez à Les noms ne se résolvent pas (DNS).

Étape 4. Examiner le filtre de paquets

La cause la plus fréquente d'une perte d'accès est votre propre règle qui a coupé la connexion. Vérifiez :

nft list ruleset
iptables -S
ufw status verbose

Si vous voyez une politique DROP sur le trafic entrant sans le port 22 autorisé, vous vous êtes coupé de SSH. Restaurez l'accès via la console :

ufw allow 22/tcp
ufw reload

Avant d'activer un pare-feu, autorisez toujours le port SSH dans le même ensemble de commandes. L'approche « refuser d'abord, autoriser ensuite » vous coûte votre accès.

Étape 5. Vérifier le démon SSH lui-même

Le réseau peut fonctionner alors que le port est fermé parce que le service a planté :

systemctl status ssh
ss -tlnp | grep :22

Consultez Le service ne démarre pas : dépannage systemd pour savoir comment diagnostiquer l'état du service.

Si rien n'a aidé

Démarrez sur le disque de récupération SystemRescue depuis l'onglet « Access » : connexion root sans mot de passe, et le disque de la machine est visible sous /dev/sda. Montez la racine et corrigez la configuration réseau « de l'extérieur » du système. Une fois terminé, revenez au mode de démarrage normal et redémarrez la machine — sinon elle continuera de démarrer sur SystemRescue.