Ce que gateway-ping-timeout attend vraiment dans NetworkManager

Vous trouvez connection.gateway-ping-timeout dans un fil sur un ordinateur portable qui démarre avant que le réseau soit utilisable, vous l’augmentez, et quelque chose change. Que le changement ait aidé pour la raison que vous croyez est une autre question. La réponse commence par ce que fait réellement l’activation pendant que ce minuteur tourne, et par le fait que l’attente a deux fins possibles.

Suivez une connexion depuis la ligne de commande et la sémantique devient concrète.

Suivre une activation

Commencez par regarder la connexion enregistrée plutôt qu’une valeur par défaut globale, car il s’agit d’une propriété propre à chaque connexion. Ajoutez --show-secrets uniquement si vous en avez vraiment besoin ; le paramètre lui-même n’est pas un secret.

nmcli -f connection.id,connection.gateway-ping-timeout connection show
nmcli connection show "Wired connection 1" | grep gateway-ping

Quand la propriété vaut zéro, ce qui est la valeur par défaut documentée, l’activation avance dès que l’adressage est terminé. Mettez-la à une valeur positive et l’activation de la configuration IP attend qu’une réponse arrive de la passerelle ou que le délai expire.

Ensuite, coupez et remontez la connexion en observant le flux d’événements. L’ordre que vous voyez est le paramètre qui fait son travail : état de l’appareil, adressage, l’attente, et enfin l’état activé sur lequel les services dépendants sont généralement ordonnés.

L’attente a deux fins

Les deux fins comptent, et la plupart des gens n’en retiennent qu’une. Une réponse de la passerelle termine l’attente plus tôt, et le délai la termine aussi, que quelque chose ait répondu ou non. La propriété n’exige pas un ping réussi avant que l’activation puisse se terminer.

Cette seule phrase dissipe beaucoup de confusion autour des ordinateurs portables dans les hôtels et les centres de congrès, où un portail captif refuse souvent ICMP jusqu’à ce que vous vous connectiez. La connexion s’active quand même après l’expiration du délai ; elle le fait simplement plus tard que nécessaire, et chaque service ordonné après la connexion attend avec elle.

Ce n’est pas non plus un contrôle de vivacité. Rien dans la description ne commence à pinguer une passerelle une fois la connexion établie, et rien ne déconnecte un profil actif parce qu’un ping ultérieur échoue. Si vous avez besoin de détecter des pertes, cela relève du protocole ou du propriétaire du tunnel, pas d’une propriété qui s’est exécutée une fois pendant l’activation.

Deux objets, un paramètre

Le profil de base filaire et un profil VPN sont des objets de configuration distincts, et définir la propriété sur l’un n’affecte pas l’autre. Un profil VPN qui nomme une connexion de base n’hérite d’aucun de ses paramètres d’activation, ce qui explique pourquoi la valeur que vous avez modifiée peut sembler sans effet sur ce que vous observiez.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office VPN" | grep gateway-ping

Lisez les UUID plutôt que les noms. Les noms se dupliquent après une réinstallation ou un profil restauré, et deux connexions portant le même nom visible vous feront modifier le mauvais fichier pendant que la vraie reste inchangée.

La version installée de NetworkManager compte aussi. Le comportement des greffons et la façon dont un type de connexion mappe cette propriété sur ses propres étapes d’activation varient, alors testez sur la version que vous déployez au lieu de supposer qu’un article trouvé s’applique sans changement.

Ce que l’attente ne peut pas certifier

Voici la partie qui coûte le plus de temps. Une réponse du routeur local prouve qu’un hôte a répondu à un écho ICMP pendant l’activation. Elle ne prouve pas qu’un point de terminaison VPN se résout, que l’identité du client est acceptée, que des routes privées ont été installées, que le résolveur du bureau répond, ni que l’application qui vous importe fonctionnera.

Ce sont des dépendances distinctes avec des preuves distinctes. Une passerelle peut répondre pendant que DNS échoue, et une passerelle peut silencieusement abandonner ICMP par politique pendant que tous les chemins applicatifs fonctionnent. Conditionner sur cette propriété est donc une supposition sur la couche qui est en retard, pas une mesure de celle-ci.

Si vous attendez un service dépendant, nommez ce dont il a besoin. Une adresse attribuée est satisfaite par l’adressage. Un tunnel est satisfait par l’état du tunnel lui-même. Un nom privé est satisfait par une requête. Une application est satisfaite par l’application, et aucune de ces réponses ne vient d’un minuteur qui porte le nom de la passerelle.

Si vous le changez, écrivez pourquoi

Consignez la valeur précédente et la raison avant un changement approuvé, puis réglez-la sur la connexion concernée plutôt que partout. Une attente plus longue décale le moment de l’activation pour tout ce qui est ordonné après cette connexion, ce qui peut faire paraître un système lent correct et un rapide cassé.

Un piège historique mérite d’être nommé : une valeur comme celle-ci est parfois modifiée pour qu’un éditeur plus ancien accepte un profil. Si c’est la vraie histoire, vous avez deux événements, pas un. L’éditeur a enregistré, et une politique réseau active a changé. Réparez l’éditeur ou le greffon et remettez le minuteur.

La source de NetworkManager définit la propriété comme un retard de la réussite de l’adressage IP jusqu’à une réponse de la passerelle ou le délai, avec une valeur par défaut de zéro, et la définition du paramètre de connexion est la référence à lire avant de vous fier à un comportement décrit de seconde main.