Un fichier d’options pppd partagé casse-t-il vos autres VPN ?

Vous ajoutez une ligne pour qu’un profil PPTP récalcitrant se connecte, et une semaine plus tard le client L2TP qui fonctionnait depuis des mois s’arrête. La lecture évidente est que les deux protocoles entrent désormais en conflit. Le plus souvent, les deux clients lancent pppd, tous deux lisent les mêmes valeurs par défaut, et la ligne ajoutée n’a jamais été limitée au profil que vous corrigiez. Le fichier d’options partagé est le couplage, et les protocoles sont innocents.

Ce qu’un client hérite au démarrage

Un client reposant sur PPP construit rarement sa ligne de commande à partir de rien. Il lance pppd, qui lit les valeurs système par défaut, puis tout fichier utilisateur ou de terminal, puis les arguments transmis par le client ; le client peut aussi le pointer vers un fichier peer. Chacune de ces couches peut porter un plugin, une méthode d’authentification ou une directive de route, et la première couche qui définit une option protégée peut la verrouiller contre les modifications ultérieures.

La question utile n’est donc pas de savoir quel VPN est cassé, mais quelle couche a fourni le réglage. Un client qui génère ses propres arguments paraît autonome et hérite pourtant de tout ce que contient le fichier système.

Identifier l’origine de la ligne avant de la modifier

Commencez par examiner le processus en cours pendant qu’une connexion est établie. La ligne de commande indique quels fichiers ont été passés explicitement, et tout ce qui n’y figure pas provient d’un chemin par défaut.

ps -o pid=,args= -C pppd

Si la liste d’arguments contient un nom de peer, lisez ce fichier. Sinon, le réglage que vous cherchez se trouve dans un chemin partagé. Le manuel de pppd indique l’ordre dans lequel ces fichiers sont lus et les options qu’un utilisateur normal ne peut pas remplacer, ce qui explique qu’une ligne ultérieure ne produise parfois aucun effet. Une option protégée, comme un chemin de plugin, ne peut pas être remplacée par une ligne utilisateur ultérieure : modifier le mauvais fichier n’a donc aucun effet visible.

La ligne de plugin qui suit chaque client

Un plugin chargé dans le fichier système est le pire cas, car il change ce qu’un nouveau processus PPP tente de charger, quel que soit le bouton sur lequel l’utilisateur a cliqué. Le plugin L2TP en est l’exemple classique : correct pour un profil, inutile ou nuisible pour un profil PPTP qui part des mêmes valeurs par défaut.

Déplacez-le vers un fichier peer que le client sélectionne, ou vers les réglages propres à la connexion du client lorsqu’il les prend en charge. Le supprimer purement et simplement répare le second client et casse le premier : c’est ainsi que ces problèmes circulent entre les équipes.

Vérifier chaque client après le déplacement

Testez les deux connexions depuis la même machine, l’une après l’autre, et lisez les options négociées plutôt que la boîte de dialogue de réussite. Le dump ci-dessous affiche l’ensemble des options que pppd a réellement assemblé, la seule liste qui compte.

sudo pppd call office debug dump

Répétez l’opération pour le second client et comparez les deux sorties. L’option que vous avez déplacée doit apparaître dans exactement l’une d’elles. Si elle apparaît dans les deux, le client la régénère et la correction appartient à ce profil plutôt qu’au fichier partagé. Notez désormais où réside le réglage, à côté de la connexion, pour que la personne suivante ne redécouvre pas le couplage en le cassant à nouveau.