OpenVPN démarré avant le réseau n'est pas un échec

Vous démarrez le client au boot, l'unité signale qu'elle est active, et le tunnel est absent. La conclusion naturelle est que le service n'a pas démarré, et le correctif naturel est de le redémarrer. Les deux sont assez souvent faux pour mériter une règle : un client en cours d'exécution qui réessaie ressemble exactement, de l'extérieur, à un client cassé. La différence tient à ce que fait le processus, pas à l'état de l'unité.

Mythe : un service démarré signifie un tunnel qui fonctionne

Une unité active prouve que le processus a été lancé et n'est pas sorti. Elle ne prouve pas que le profil a été chargé, que le certificat a été accepté ou que l'extrémité distante a répondu. Un client empaqueté peut rester des minutes dans une boucle de reprise pendant que systemd ne signale que le succès. Cet écart entre état et comportement est tout le sujet.

Le cas inverse est tout aussi courant. Le processus a pu sortir après avoir échoué à lire une clé, et l'unité signale alors un état d'échec qui ne dit rien de la raison. Les deux états ont besoin du journal pour être distingués.

Lisez le journal de l'instance plutôt que l'état de l'unité. La ligne de raison est dans le journal, pas dans l'étiquette d'état.

Mythe : les réglages de reprise couvrent tous les échecs

La résolution de noms et les reprises de transport sont des contrôles distincts avec des valeurs par défaut distinctes. resolv-retry régit les recherches répétées d'un nom d'hôte distant, et la valeur documentée continue d'essayer indéfiniment. connect-retry fixe l'intervalle entre les tentatives, tandis que connect-retry-max peut plafonner le nombre d'essais par entrée distante. Vérifiez quelle étape le journal nomme avant de modifier l'un d'eux.

Rien de tout cela ne s'applique à un profil malformé, une clé privée illisible ou un compte rejeté. Ces cas demandent une correction, et un client qui les réessaie n'avance pas.

Réessayer indéfiniment un certificat non approuvé n'est pas une raison de retirer la vérification. C'est une raison de lire l'erreur.

Mythe : un lanceur suffit, alors ajoutez-en un autre

Une connexion déjà gérée par NetworkManager ou par une unité empaquetée n'a pas besoin d'un second lanceur attaché. Deux processus qui se disputent les mêmes routes produisent des interfaces en double, des journaux confus et un tunnel qui oscille pour des raisons que personne ne voit. La seconde copie arrive généralement comme contournement du fait que la première est lente.

Décidez quel composant possède le tunnel avant d'ajouter quoi que ce soit. Retirez ensuite l'autre lanceur au lieu de le désactiver en espérant.

Le propriétaire détermine aussi l'origine des reprises et des identifiants, c'est pourquoi cette décision précède tout réglage. La propriété vient en premier exactement pour cette raison.

Ce qui a réellement besoin d'un ordre

L'ordre peut attendre une adresse configurée, et c'est tout ce qu'il garantit. network-online.target retarde l'activation jusqu'à ce que le gestionnaire considère le réseau monté, et la définition de monté dépend du gestionnaire. Il ne dit rien sur la résolution du nom d'hôte VPN, la réponse de l'écouteur ou l'admission de l'appareil par un portail captif.

Lisez l'unité installée et tout drop-in avant d'ajouter des dépendances. Un After= large sur chaque service réseau retarde le démarrage sans établir la connexion dont vous avez réellement besoin.

Ordonnez la dépendance que vous pouvez tester, et vérifiez tout le reste avec une sonde de disponibilité. Une sonde qui ouvre le tunnel vaut mieux qu'un minuteur qui devine.

Ce qui se passe après la première montée du tunnel

Le démarrage est un événement parmi d'autres. Le lien d'accès change, une session de portail expire, le pair redémarre. Distinguez une reconnexion interne d'une sortie de processus gérée par le gestionnaire de services, car les deux ont des propriétaires différents et laissent des preuves différentes.

L'authentification interactive limite la reprise sans surveillance. Une unité en arrière-plan ne déverrouille pas un trousseau de bureau et ne répond pas à une demande MFA, suivez donc l'arrangement d'identifiants approuvé pour le contexte du service.

Décidez séparément ce que les applications peuvent faire pendant que le tunnel est coupé. La reprise rétablit une connexion, tandis qu'une politique de blocage décide si le trafic direct est autorisé dans l'intervalle.