Les routes VPN Mac supplémentaires ont besoin d'un propriétaire, pas d'un script de connexion

Atteindre un préfixe privé via un VPN est une exigence qui a une durée : elle tient tant que cette connexion est utilisable, et elle cesse quand la connexion cesse. Un script de connexion ne peut pas l'exprimer, car la connexion et la montée du tunnel sont des moments différents, et le tunnel qui existe à la connexion n'est peut-être pas celui qui porte le trafic une minute plus tard. La première décision n'est pas quelle commande exécuter. C'est quel composant possède le préfixe.

Le préfixe a besoin d'un propriétaire, pas d'un instant

Commencez par écrire l'exigence sous forme de phrase avec un sujet : atteignez 10.77.0.0/24 via le VPN du Bureau tant que cette connexion est active. Cette phrase nomme le préfixe, la connexion et la condition, et elle exclut immédiatement deux substituts populaires : un hook de connexion et un nom d'interface comme ppp0 ou utun2.

Les noms d'interface sont attribués à l'exécution et ne sont pas stables d'une reconnexion à l'autre. Un hook qui correspond au nom vu la semaine dernière soit ne se déclenche pas, soit se déclenche sur l'interface de quelqu'un d'autre. Les deux issues se présentent comme un bug de routage plutôt que comme l'hypothèse périmée qu'elles sont. La même objection vaut pour tout script attaché à un nom qui n'existe que tant qu'un tunnel précis est monté.

Utilisez une source d'intention de route prise en charge

La passerelle, un profil géré ou le mécanisme de routes documenté du client propriétaire est le bon endroit, dès lors que ce mécanisme peut exprimer l'exigence. Lequel s'applique dépend du protocole et du fournisseur, et les clés ne voyagent pas entre eux, donc une valeur qui configure un profil OpenVPN ne vous dit rien sur le client natif L2TP ou IKEv2.

Pour les développeurs de tunnels de paquets, les réglages de tunnel IPv4 d'Apple exposent explicitement les routes incluses et exclues, et IPv6 a son pendant. Ce sont des API que le fournisseur utilise, pas la preuve que chaque panneau VPN natif offre à un administrateur une liste de routes arbitraire. Si la combinaison actuelle ne peut pas exprimer les préfixes dont vous avez besoin, l'étape suivante est un chemin de configuration pris en charge par l'opérateur, pas une autre application installée dans l'espoir qu'elle se comporte mieux.

La durée de vie inclut le nettoyage

Un assistant externe est parfois réellement nécessaire, et quand c'est le cas, « ajoute la route » est la plus petite partie de son travail. Il doit savoir quelle connexion il sert et quelle interface cette connexion utilise, attendre que l'état réseau pertinent se stabilise, rester idempotent quand il s'exécute deux fois de suite, et ne nettoyer rien qu'il n'a pas installé lui-même.

Cette dernière clause est celle qui fait mal. Un assistant qui supprime toutes les routes correspondant au préfixe du bureau finira, tôt ou tard, par supprimer une route qu'il n'a pas ajoutée. La panne qui en résulte est imputée au client VPN, car le client est la partie que l'utilisateur voit. Décider de ce qu'un assistant possède avant de l'écrire coûte moins cher que d'expliquer ensuite pourquoi un sous-réseau local a cessé de répondre.

La course à la reconnexion

Considérez une reconnexion rapide. La session A tombe, la session B monte et installe sa route, puis le nettoyage différé d'A s'exécute enfin. Si ce nettoyage retire des routes par préfixe, il emporte l'état valide de B, et la connexion qui fonctionnait il y a une seconde route désormais vers rien.

C'est une course de propriété, et ajouter un sommeil au script ne change que le camp qui la gagne. Le correctif consiste à conditionner le nettoyage à l'identité : comparez l'interface et la session que l'assistant a installées à celles encore en vigueur, et ne supprimez qu'en cas de correspondance.

Ce qu'il faut tester, et ce qu'une route ne peut pas faire

L'acceptation doit couvrir quatre transitions : la première connexion, une reconnexion sur une autre interface, une tentative de connexion qui échoue, et la déconnexion finale. Après chacune, lisez la route que le système a réellement choisie pour une adresse du côté distant, plutôt que celle que vous attendiez.

route -n get 10.77.0.5
netstat -rn -f inet

Incluez les cas délicats dans la même passe : IPv6 là où il est requis, un préfixe local qui chevauche le préfixe distant, et la route vers le point de terminaison public du VPN lui-même, qui doit continuer à fonctionner tant que le tunnel est monté. Puis notez ce qu'une route n'est pas. Elle sélectionne des paquets ; elle n'accorde pas de permission côté distant et elle ne crée pas de chemin de retour, et ces points restent des exigences distinctes avec des propriétaires distincts.

Le résultat que vous voulez est un préfixe qui suit son propriétaire de connexion pris en charge à travers chaque transition, plutôt qu'une commande qui a réussi une fois par hasard sur la machine où elle a été écrite.