OpenVPN auth-nocache : ce qui se passe à la connexion suivante

Activez auth-nocache et l’avertissement sur la mise en cache du mot de passe disparaît, avec la copie des identifiants qu’OpenVPN conservait pour la prochaine renégociation. Que cela devienne une invite, une nouvelle tentative silencieuse ou un tunnel coupé dépend de l’origine des identifiants la seconde fois. Cela en fait une comparaison entre formes de déploiement, pas un verdict sur l’option. Lisez la forme que vous exploitez réellement avant de modifier un profil.

D’où doit venir le second jeu d’identifiants

OpenVPN applique auth-nocache aux secrets recueillis par auth-user-pass et askpass : une fois utilisés, le processus les abandonne au lieu de les garder pour la prochaine poignée de main. Une renégociation arrive sur un minuteur, une fois par heure par défaut, si bien que la seconde demande survient longtemps après que la personne qui a saisi le mot de passe est passée à autre chose. Cet écart est toute l’histoire. Avec le cache activé, le client rejoue la copie stockée sans demander à personne ; avec le cache désactivé, il doit trouver le secret ailleurs ou échouer.

Dressez donc la liste de tous les endroits d’où le secret pourrait venir à ce moment-là, et soyez honnête sur ceux qui existent sur l’hôte. Une personne devant un terminal, un fichier que auth-user-pass ou askpass peuvent lire, ou un jeton de session émis par le serveur sont les trois qui comptent ici. Si aucun n’est disponible, la renégociation échoue une heure après le changement, et non au moment où vous l’avez fait.

Trois formes, trois points de défaillance

Un client de bureau avec une personne devant lui est le cas léger : l’invite revient, quelqu’un saisit à nouveau le mot de passe, et le coût est de l’attention. Un service, un conteneur ou un routeur qui exécute OpenVPN sans terminal est le cas dur, car personne n’est là pour répondre et la reconnexion autrefois silencieuse met désormais fin au tunnel. Un hybride se situe entre les deux et se comporte comme le cas de bureau jusqu’à ce que la session capable de répondre à l’invite disparaisse. Ce qui les sépare n’est pas la présence d’une interface graphique, mais l’existence d’une source d’identifiants au moment de la renégociation.

Rattachez votre déploiement à l’une de ces trois formes avant de changer quoi que ce soit, car le conseil que vous trouvez en ligne est presque toujours écrit pour la première. Appliquer la réponse de bureau à un service sans terminal, c’est ainsi qu’un tunnel qui a fonctionné des mois commence à tomber toutes les heures.

Directive ou option : choisissez l’une et sachez laquelle vous avez utilisée

Dans un profil, auth-nocache est une ligne à part ; sur un appel qui nomme explicitement un profil, c’est une option de cette ligne de commande, et le manuel d’OpenVPN liste les deux formes. Les deux font la même chose à la rétention des identifiants, et aucune ne touche au type d’interface ni ne répare un avertissement sans rapport présent dans le même journal. La différence est la persistance : l’option ne couvre que cette exécution, si bien qu’un service redémarré depuis un fichier unit ou un script enveloppe ne l’aura pas, sauf si l’enveloppe la transmet aussi.

auth-nocache
openvpn --config /path/client.ovpn --auth-nocache

Décidez quel artefact possède le réglage, modifiez-le là et nulle part ailleurs. Un profil modifié sur un portable plus une unit systemd qui le contourne par une option, voilà la paire qui produit un comportement contradictoire après un redémarrage.

Un fichier d’identifiants déplace le secret au lieu de le supprimer

Pointer auth-user-pass vers un fichier donne une source à chaque renégociation ultérieure, et place aussi le mot de passe quelque part qui survit aux redémarrages. Demandez qui peut lire ce fichier, si le démon peut encore le lire après avoir abandonné ses privilèges, et ce qui se passe quand le système de fichiers est monté en lecture seule ou qu’une vue de conteneur cache le chemin. Un secret sur disque et un secret en mémoire sont des problèmes différents, et résoudre l’un laisse l’autre en place. La rotation est l’étape que l’on saute : un mot de passe changé sur le serveur mais pas dans le fichier produit une panne qui se lit comme une panne réseau.

Gardez le fichier la propriété du compte qui exécute le démon, illisible par quiconque d’autre, et hors des sauvegardes qui quittent l’hôte. L’option auth-gen-token côté serveur d’OpenVPN remet au client un jeton de session après une connexion réussie, ce qui est une chose plus petite à laisser traîner que le mot de passe du compte. Écrivez l’étape de rotation à côté du fichier dans tous les cas, car le fichier survit généralement à la personne qui l’a créé.

Étirer la renégociation déplace le coût, elle ne le supprime pas

L’autre suggestion est d’augmenter reneg-sec jusqu’à ce que l’invite soit assez rare pour être ignorée. Cela réécrit le calendrier de rotation des clés de la session et repousse le même problème d’identifiants à un moment plus tardif et moins prévisible ; cela ne crée pas de source d’identifiants. Une politique qui renouvelle les clés selon un calendrier pour une raison donnée ne devrait pas être assouplie juste pour éviter de saisir un mot de passe.

Testez la reconnexion plutôt que la session dans laquelle vous êtes assis, car la session vivante ne prouve rien. Faites tomber le tunnel depuis le serveur, ou redémarrez le service client, et regardez ce que fait la prochaine renégociation sans personne au clavier. S’il se reconnecte, nommez le mécanisme qui a fourni le secret ; sinon, vous avez trouvé le coût réel de l’option sur cet hôte. L’un ou l’autre résultat vous donne une réponse qui tient pendant une panne au lieu d’une qui a tenu pendant les tests.

Sur une flotte administrée, celui qui possède le déploiement devrait pouvoir nommer trois choses : d’où viennent les identifiants, où ils sont stockés et qui les fait tourner. Si l’une de ces réponses est la personne qui a configuré l’hôte, l’option n’y est pas encore sûre.