Diagnostiquer une erreur de routage sur un VPS Linux

Une erreur de routage peut donner l’impression qu’un VPS est totalement hors ligne alors que son interface réseau fonctionne encore. La bonne méthode consiste à séparer les tests locaux, la passerelle par défaut et la destination finale. Ce guide propose une vérification progressive sur Debian, Ubuntu ou une autre distribution Linux, avec des commandes réversibles et des points d’arrêt pour éviter de couper sa propre session SSH.

Avant de commencer le diagnostic

Gardez une session SSH ouverte tant que la cause n’est pas identifiée. Si vous disposez d’une console distante fournie par votre hébergeur, ouvrez-la avant de modifier une route. Notez l’adresse IP du VPS, l’interface Ethernet concernée, la destination qui ne répond pas et le protocole utilisé. Un VPS peut joindre sa passerelle tout en échouant vers un seul réseau, ce qui n’a pas la même cause qu’une interface arrêtée.

Les commandes ci-dessous observent d’abord l’état du système. Ne supprimez pas une route et ne remplacez pas la configuration réseau avant d’avoir enregistré la sortie des commandes. Pour les opérations qui nécessitent les droits root, utilisez sudo et vérifiez chaque valeur avant validation.

1. Vérifier l’interface et les adresses

Commencez par afficher les interfaces, leur état et les adresses IP IPv4 ou IPv6 attribuées :

ip -br address
ip link show

Repérez l’interface qui porte l’adresse du VPS et vérifiez qu’elle est marquée UP. Une interface active ne prouve pas encore que le routage est correct, mais une interface absente, désactivée ou sans adresse explique déjà une partie du problème. Comparez cette observation avec la configuration déclarée par votre distribution et votre panneau de gestion. Une adresse statique ne se vérifie pas comme une adresse obtenue par DHCP. La commande historique ifconfig peut apparaître dans de vieux scripts, mais ip est l’outil à privilégier.

2. Lire la table de routage

Affichez la table utilisée par le noyau :

ip route show
ip -6 route show
ip route get 1.1.1.1

La ligne default indique la route par défaut. La commande ip route get est utile car elle montre le chemin choisi pour une destination précise, avec l’interface et la passerelle retenues. Si aucune route ne correspond à la destination, ou si la route par défaut pointe vers une mauvaise interface, le problème est local au VPS. Pour IPv6, contrôlez séparément la table ip -6 route : une route IPv4 correcte ne répare pas une route IPv6 absente.

Ne copiez pas une passerelle trouvée dans un exemple en ligne. Elle dépend du réseau fourni avec votre adresse IP et doit être confirmée dans la configuration de votre instance ou auprès du support. Vérifiez aussi le sous-réseau et le masque de sous-réseau : un préfixe incorrect peut faire croire qu’un hôte local est directement joignable alors qu’il doit passer par un routeur.

3. Tester la passerelle séparément

Testez ensuite la passerelle affichée par ip route show :

ping -c 4 ADRESSE_DE_LA_PASSERELLE

Un échec vers la passerelle oriente vers un problème d’adresse, d’interface, de route locale ou de réseau attaché au VPS. Un succès vers la passerelle mais un échec vers une adresse externe indique plutôt un problème de route suivante, de filtrage ou de destination. Le ping reste un indice, pas une preuve absolue : certains routeurs ne répondent pas à l’ICMP.

4. Comparer plusieurs destinations

Testez une adresse IP externe, puis le nom d’un domaine :

ping -c 4 1.1.1.1
getent hosts example.com
tracepath 1.1.1.1

Si l’adresse IP répond mais que le nom ne se résout pas, le symptôme relève probablement du DNS et non du routage général. Si aucune destination externe ne répond alors que la passerelle est joignable, examinez la route par défaut, le filtrage des paquets TCP et UDP et les règles du firewall. Pour un chemin plus détaillé, tracepath ou traceroute peuvent montrer à quel saut les paquets cessent d’avancer, sans modifier la configuration.

5. Examiner les règles et le filtrage

Une route correcte peut être neutralisée par un firewall local. Listez les règles avec l’outil réellement utilisé par votre système :

sudo ufw status verbose
sudo nft list ruleset

N’exécutez pas les deux commandes comme s’il s’agissait de deux configurations indépendantes. UFW peut gérer des règles nftables, tandis qu’un serveur peut utiliser une configuration directe. Cherchez une règle qui bloque le trafic sortant ou les réponses établies, sans désactiver le firewall et sans supprimer une règle à l’aveugle. Un filtrage en amont, un VPN ou un routeur virtuel peut aussi modifier le chemin observé. Dans une machine virtuelle, le NAT et le réseau virtuel peuvent également expliquer une différence entre l’IP du serveur et l’adresse visible depuis Internet.

6. Vérifier la configuration du système

Une route ajoutée avec ip route add peut être temporaire et disparaître au redémarrage. Une correction durable doit être appliquée dans le gestionnaire réseau de la distribution, par exemple Netplan, NetworkManager ou systemd-networkd, selon votre installation. Sur Ubuntu, contrôlez le fichier de configuration Netplan avant de l’appliquer. Sur Debian, vérifiez le gestionnaire déclaré et les fichiers réseau utilisés. Dans tous les cas, sauvegardez le fichier concerné et prévoyez une console de secours.

Si le VPS reçoit ses paramètres par DHCP, vérifiez le bail, le serveur DHCP et la passerelle fournie. Si l’adresse est statique, vérifiez le masque, le sous-réseau, la passerelle et l’interface. Une erreur d’adressage peut rendre un réseau local ou un LAN inaccessible alors que l’accès à Internet fonctionne. Notez la configuration avant de la corriger manuellement et ne modifiez pas un proxy ou un fichier DNS sans rapport avec le symptôme observé.

7. Rejouer les tests après correction

Après la correction, relancez les tests dans le même ordre : interface, table de routage IPv4 et IPv6, passerelle, adresse externe, puis nom de domaine. Cette progression permet de vérifier que la route est revenue sans confondre une panne DNS avec une panne réseau. Notez également si les connexions TCP vers le service attendu fonctionnent, car un ping autorisé ne garantit pas qu’un port applicatif est ouvert.

Conservez les résultats de la ligne de commande dans un compte rendu : adresse IP, masque, interface, route par défaut, destination testée et erreur obtenue. Cette trace évite de répéter des changements non nécessaires et aide à distinguer un problème de routeur, de firewall, de DNS ou de service.

Quand contacter le support

Contactez le support si l’interface et la route correspondent à la configuration attendue, mais que la passerelle reste inaccessible, ou si la connectivité disparaît après une modification validée. Transmettez l’adresse IP concernée, l’interface, la sortie de ip route, le résultat du test vers la passerelle, le chemin tracepath et l’heure du problème. Évitez de partager des clés privées, des mots de passe ou des données sensibles.

Pour approfondir l’administration de votre infrastructure, consultez aussi le diagnostic d’un VPS inaccessible en 30 secondes, le guide sur l’adresse IP secondaire, la configuration des ports avec UFW, le diagnostic des I/O disque et les premiers réglages de sécurité d’un serveur dédié.