Le VPN se dit connecté, mais la route par défaut est morte

Le client annonce une connexion, l’icône de la zone de notification semble normale, et rien ne se charge. Cela a commencé juste après le passage du Wi-Fi à un câble, ou juste après la fin d’une mise à niveau de la distribution. Ce qui a cassé n’est pas le profil, mais l’état construit pour la connexion de base précédente. Le noyau garde une route par défaut vers un périphérique tunnel que personne ne possède, ou le résolveur liste encore des serveurs sur un lien qui a disparu. Les deux pannes ressemblent à un réseau mort et les deux se réparent sur place.

Les pièces périmées étaient déjà fausses avant que vous ne les remarquiez. Débrancher un câble ne les a rendues que visibles.

Demandez au noyau où irait un paquet

Les listes de routes sont difficiles à lire parce qu’elles énumèrent tout ce que le système connaît, y compris des entrées qui ne s’appliquent plus. Une recherche de route répond à la seule question qui vaille : quel périphérique transporte ce paquet précis en ce moment. Si la réponse nomme un périphérique tunnel, le noyau l’utilisera même si aucun processus client n’est vivant derrière, et le paquet tombe dans une interface que personne n’entretient. Si la réponse nomme l’adaptateur Ethernet alors que le client affirme être connecté, le tunnel existe mais a perdu la sélection, ce qui est le résultat habituel d’un passage du sans-fil au filaire.

Lancez la recherche deux fois, une pour une adresse publique et une pour une adresse interne, car une politique de tunnel divisé peut en router une honnêtement et abandonner l’autre.

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

Le résolveur garde aussi le lien mort

Sur un hôte avec systemd-resolved, les serveurs DNS appartiennent aux liens et non à une liste globale. Un lien VPN tombé peut rester enregistré avec ses serveurs pendant un moment, et chaque recherche attend alors une adresse qui ne répondra jamais. Ce délai ressemble à un réseau mort et pousse les gens à regarder les routes alors que la route est bonne.

resolvectl status
resolvectl query intranet.example.com

Lisez les blocs par lien et identifiez quel lien possède le domaine en question. Un tunnel levé mais qui ne possède pas le domaine interne transmet les noms internes au résolveur public, et le symptôme est indiscernable d’une faute de routage.

Réparez l’enregistrement plutôt que /etc/resolv.conf. Sur les installations actuelles d’Ubuntu et de Fedora, ce chemin est un lien symbolique vers l’état d’exécution du résolveur, si bien qu’une modification est soit ignorée, soit écrasée au prochain événement réseau.

Un VPN ne démarre jamais tout seul

NetworkManager monte un VPN par-dessus une connexion de base, et il apprend laquelle suivre à partir de connection.secondaries sur cette base. La référence des paramètres de connexion indique explicitement que la connexion automatique n’est pas implémentée pour les profils VPN. C’est tout le mécanisme derrière cette classe de panne : changez la base, et le VPN doit être réappairé ou réactivé à la main.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

Quand la liste active montre la base sans le VPN, le tunnel n’est pas actif du tout et la route n’a jamais été installée plutôt que laissée périmée. Quand l’activation se plaint qu’aucune connexion source n’existe, la base avec laquelle il était appairé a disparu, alors réparez d’abord la base ou l’appairage et cessez de réessayer le VPN.

Une mise à niveau peut laisser tomber des réglages sans message

Mettre à niveau une distribution remplace le client et souvent son greffon NetworkManager, tandis que le profil enregistré conserve les noms de propriétés avec lesquels il a été écrit. Tout ce que le nouveau greffon ne reconnaît plus est ignoré en silence. Le profil s’active encore et le périphérique apparaît encore, mais la route qui arrivait autrefois avec lui n’arrive plus.

Les crochets écrits à la main bougent aussi. Un script qui installait une route à un moment prévisible de l’ancienne séquence peut maintenant s’exécuter avant que l’interface existe, ou après que le client a déjà expiré.

Comparez le profil vivant au greffon que vous avez réellement, et non au comportement dont vous vous souvenez. Si une clé a disparu de la documentation, déplacez le travail dans un script répartiteur ou dans un remplacement pris en charge plutôt que de restaurer l’ancienne propriété.

Trois états, trois réparations différentes

Décidez dans quel état vous êtes avant de toucher à quoi que ce soit, car un redémarrage détruit les preuves et la panne revient au prochain changement de réseau.

Terminez par une recherche pour une adresse publique, une pour une adresse interne et une requête de nom. Si les adresses fonctionnent et le nom non, la panne restante est la portée de domaine dans le résolveur, et la table de routage n’a jamais été le problème.