ifconfig-noexec ne sauvera pas votre session SSH : ce qu'il fait
Il supprime la configuration de l'adresse d'interface propre à OpenVPN. Il ne réserve pas de route de réponse pour SSH, ne désactive pas toutes les modifications de route et ne fournit pas l'adresse manquante.
Quelque part dans un fil de forum, ifconfig-noexec est proposé comme le correctif qui maintient une session SSH en vie lorsqu'un tunnel démarre. Le raisonnement paraît plausible jusqu'à ce qu'on vérifie ce que l'option touche. Elle empêche OpenVPN de configurer l'adresse de l'interface du tunnel et confie ces valeurs à des scripts à la place ; sur la destination des réponses à votre connexion de gestion, elle ne dit rien. Croire le contraire produit un tunnel sans adresse utilisable et une session SSH qui meurt quand même.
Ce que l'option délègue réellement
Par défaut, le client monte le périphérique tunnel et attribue les adresses locale et distante que le serveur lui a remises. Avec ifconfig-noexec défini, cette étape est ignorée, et les valeurs négociées sont exportées vers l'environnement du script pour qu'autre chose les applique.
La propriété se déplace. Rien n'est inventé à sa place.
La question à laquelle l'option répond est donc qui configure l'interface, et la question à laquelle elle ne répond pas est comment les paquets trouvent le chemin du retour vers vous. Gardez ces deux aspects séparés, sinon vous passerez une soirée à modifier des routes pour compenser une interface sans adresse.
Trois options similaires aux tâches différentes
La famille est facile à confondre parce que les noms diffèrent d'un mot et que les symptômes se recouvrent. Lisez ce que chacune supprime avant d'en choisir une.
| Option | Ce qui cesse de se produire |
|---|---|
ifconfig-noexec | La configuration de l'adresse du tunnel par OpenVPN lui-même ; les valeurs vont à des scripts à la place |
route-noexec | L'ajout et la suppression automatiques de routes ; les détails de route vont à un script |
route-nopull | Les routes poussées par le serveur et les options associées comme le DNS sont rejetées |
Ce sont des alternatives à comprendre séparément, pas un ensemble à coller ensemble. Supprimer la configuration d'adresse ne supprime pas les changements de route, les règles de pare-feu ni les options poussées qui portent le DNS. Un script délégué est aussi libre de changer les routes, et c'est une décision que vous confiez plutôt que d'éviter.
Si un client fournisseur enveloppe le moteur, utilisez son intégration prise en charge au lieu de déposer une directive de bas niveau dans un profil et d'espérer que l'enveloppe la respecte. Les enveloppes régénèrent souvent le profil à la connexion, si bien qu'une modification manuelle disparaît sans erreur. Vérifiez où le client conserve ses réglages avant de passer une soirée sur le fichier. Cela vaut pour chaque ligne du tableau, pas seulement pour celle qui vous a fait venir.
La session SSH que vous vouliez protéger
Une connexion SSH a une adresse source, une adresse de destination et un chemin de réponse. Sur un serveur qui vient d'installer un tunnel complet par défaut, la réponse à votre adresse publique correspond au tunnel, et la passerelle VPN la rejette.
Rien dans la configuration d'adresse de l'interface du tunnel ne change cela.
Ce qui corrige cela, c'est une route plus précise pour votre adresse de gestion via la passerelle d'avant-tunnel, ou une règle de politique qui oriente ce trafic, plus les réglages de filtrage que votre hôte applique. Les deux problèmes apparaissent parfois ensemble, et c'est ainsi que l'un est pris pour un remède à l'autre. Testez-les séparément : montez le tunnel sans l'option, examinez l'adresse de l'interface et le chemin de réponse, puis décidez lequel des deux est réellement cassé.
Ce qu'un script délégué doit reprendre à son compte
Si vous voulez vraiment qu'un autre propriétaire configure l'interface, énumérez le travail : appliquez les adresses locale et distante, montez le périphérique, restaurez ou retirez l'adressage au démontage, et faites de même après une reconnexion. Les valeurs d'une session réussie ne doivent pas être codées en dur, car le serveur peut en fournir une autre paire la fois suivante.
Les variables d'environnement exportées par le client sont la seule entrée prise en charge pour ce travail.
env | grep -E '^ifconfig_|^route_'Dans un script route-up, ces variables sont disponibles ; depuis une tâche cron ou un shell manuel, elles ne le sont pas. Confirmez le crochet de cycle de vie utilisé par votre version, et confirmez que ce crochet s'exécute avec assez de privilèges pour changer l'interface, car le client a peut-être déjà basculé vers un utilisateur non privilégié.
Testez tout le cycle de vie, pas une seule session
Montez le tunnel, vérifiez l'adresse sur le périphérique, puis reconnectez-vous et vérifiez-la à nouveau. Une configuration qui fonctionne une fois et échoue au second essai signifie généralement que l'étape déléguée ne s'exécute qu'à la première connexion.
Testez ensuite les deux critères d'acceptation ensemble : une nouvelle connexion SSH par le chemin de gestion prévu fonctionne, et une application autorisée utilise le tunnel correctement.
Une ancienne session SSH qui survit par hasard alors que le tunnel n'a pas d'adresse n'est pas une réussite, et c'est exactement l'état que produit cette option quand personne ne reprend le travail. Vérifiez d'abord l'adresse de l'interface, puis le chemin de réponse de gestion, puis l'application. Si deux des trois sont faux, l'option a déplacé le travail sans lui donner de propriétaire.