Routes persistantes pour un VPN Mac : networksetup ou un hook de connexion ?

Une route saisie après chaque connexion résout l’instant et non la semaine. Sous macOS, le choix durable est généralement un préfixe stocké avec le service VPN, car le service le réinstalle à chaque connexion et le retire lorsque le service est arrêté. Les alternatives sont un route add temporaire pour tester et un hook de connexion pour les adresses connues seulement après la négociation.

Décidez si la route appartient au service ou à la session

Demandez de quoi dépend le préfixe. S’il s’agit d’un réseau privé fixe derrière un service VPN natif, la route appartient à ce service. S’il dépend d’une adresse de pair qui change à chaque connexion, un hook ou une tâche pilotée par l’état peut être le meilleur propriétaire. Si vous ne vérifiez un chemin que pour les cinq prochaines minutes, une route temporaire suffit.

La route liée au service a le cycle de vie le plus propre. Elle apparaît avec le service et disparaît lorsque le service n’est pas connecté, elle ne peut donc pas survivre au tunnel vers lequel elle pointe. Cette propriété vaut plus que la commodité d’une commande d’une ligne.

Une route liée à la session appartient à l’interface, et ce numéro change sans préavis. Une reconnexion peut donner au tunnel un nom utun différent de celui utilisé par la session précédente, ce qui transforme une commande codée en dur en une route qui ne pointe vers rien ou, pire, vers un autre tunnel.

Lisez l’état actuel de la route et du service

Commencez par les noms que le système utilise réellement. Le nom du service dans Réglages Réseau est l’identifiant des commandes ci-dessous, et la table de routage actuelle montre ce que le client connecté a installé. Lisez les deux pendant que le tunnel est actif.

scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5

Cette recherche montre quelle passerelle et quelle interface le noyau choisirait pour cette adresse en ce moment. S’il choisit déjà le tunnel, le préfixe est couvert et une nouvelle route serait redondante. S’il choisit le routeur local, le tunnel manque ce préfixe.

Notez l’adresse du pair pendant que vous êtes connecté. Elle devient la valeur de passerelle dans la route liée au service, et c’est généralement la destination affichée pour la route par défaut du tunnel dans netstat -rn.

Stockez le préfixe avec networksetup

L’outil networksetup attache des routes supplémentaires à un service réseau. Pour un service nommé OfficeVPN et un préfixe privé atteint via le pair du tunnel, la forme est :

sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN

Chaque triplet après le nom du service donne une destination, son masque réseau et le pair du tunnel comme passerelle. Un seul appel peut porter plusieurs préfixes, et un appel vide efface la liste stockée. Le lecteur est l’étape de vérification ; si la liste est vide, l’ensemble ne s’est pas appliqué au service que vous croyez.

La passerelle doit être le pair du tunnel, pas le routeur physique. Une route qui nomme la passerelle locale envoie le préfixe privé par l’interface physique, ce qui est l’échec d’origine avec des étapes en plus. Un pair obsolète est la raison la plus courante pour laquelle une route d’apparence correcte ne transporte jamais de trafic. Relisez le pair depuis l’état connecté au lieu de copier une adresse depuis une vieille note.

N’utilisez route add que pour un test

Une route directe est utile pour prouver qu’un préfixe fonctionne avant de le rendre permanent. La forme avec interface évite une recherche de passerelle :

sudo route -n add -net 10.20.0.0/16 -interface utun4

La route disparaît à la prochaine reconnexion et dépend du numéro d’interface qui existe aujourd’hui. Cela en fait un diagnostic, pas un déploiement. Si le test fonctionne et que la route liée au service non, comparez d’abord la valeur de passerelle ; c’est le champ le plus souvent faux.

Méfiez-vous des conseils qui remplacent la route par défaut du VPN pour forcer la séparation. Un client qui impose un tunnel complet peut réinstaller ses routes après une reconnexion ou un rafraîchissement de politique, la modification manuelle est donc annulée en silence. Quelques préfixes privés sont un problème de routage ; garder tout le trafic internet local contre une politique de tunnel complet est une décision côté serveur.

Ne choisissez un hook que lorsque l’adresse est négociée

Pour les liens basés sur PPP comme L2TP, macOS exécute /etc/ppp/ip-up une fois le lien établi. Le script reçoit le nom de l’interface et les adresses locale et distante négociées, il peut donc ajouter une route qui dépend du pair attribué par le serveur. C’est exactement le cas qu’une route de service fixe ne peut pas exprimer.

IKEv2 et les clients de fournisseurs peuvent ne pas utiliser du tout ce chemin PPP, ce qui signifie que le script peut rester silencieux pendant toute la session. Lorsque cela se produit, une tâche launchd qui interroge scutil --nc status et réagit à un changement d’état est le mécanisme équivalent, avec un petit délai.

Quel que soit le hook utilisé, rendez-le idempotent et faites-lui retirer uniquement les routes qu’il a créées. Un script qui supprime toutes les routes mentionnant le tunnel finira par supprimer la route qui maintient le serveur VPN joignable, et la connexion tombera dès qu’il réussira.

Terminez en vérifiant la destination privée, la navigation ordinaire et un cycle de reconnexion ou de veille. Inspectez ensuite scutil --dns, car la résolution de noms est une politique distincte et une route qui fonctionne ne prouve pas que les noms privés se résolvent.