Deux comptes de session Mac ne séparent pas le trafic VPN

Deux comptes de session sur le même Mac ressemblent à deux mondes séparés jusqu'à ce que le réseau arrive. Un tunnel démarré dans une session peut encore changer ce que vit l'autre session, selon quel client le possède et quelle politique l'accompagne. Décrivez la séparation dont vous avez besoin avant de choisir un mécanisme pour l'imposer. L'ordre compte, car un mécanisme choisi en premier tend à redéfinir l'exigence autour de lui.

Trois questions font l'essentiel du travail : quelles applications de qui ont besoin de quelles ressources privées, si les deux sessions doivent être actives en même temps et ce que ces applications sont autorisées à faire lorsque leur tunnel est indisponible.

Partez du trafic, pas de la liste des comptes

Changer de compte est une frontière d'identité, pas une frontière de routage. macOS charge une configuration VPN pour le compte qui la possède, mais l'interface, ses routes et toute politique à l'échelle du système qu'elle installe appartiennent à la machine. Si l'exigence est que seules les applications d'une personne entrent sur le réseau d'entreprise, la conception doit le dire en termes d'applications et de destinations, pas en termes de qui est connecté. Sinon, le second compte hérite de ce que le client du premier a laissé.

Écrivez le comportement requis en une phrase : le courrier et l'accès aux fichiers d'un utilisateur suivent le tunnel géré, la navigation de l'autre utilisateur reste sur la connexion domestique, et aucun des deux chemins n'hérite de la route par défaut de l'autre. Cette phrase est vérifiable ; une histoire de changement de session ne l'est généralement pas.

Canal du profil et portée du trafic sont deux choses différentes

Apple prend en charge des dispositions VPN gérées fournies par utilisateur ou par appareil, et un guide de déploiement décrit ces modèles avec une intégration dépendante du fournisseur. Le canal de livraison dit qui reçoit la configuration et qui la possède. Il ne définit pas à lui seul quel trafic est capturé, car l'implémentation du client et la politique configurée en décident encore.

Là où un mode documenté conscient de l'utilisateur ou de l'application peut exprimer l'exigence, c'est le chemin le plus court. Vérifiez ensuite les applications et identités réelles plutôt que de faire confiance aux noms : deux copies de la même application ne sont pas deux chemins réseau différents, et un profil qui liste une application ne garantit pas que ses processus auxiliaires soient couverts.

Un système invité est une vraie frontière avec de vraies limites

Une machine virtuelle vous donne un système d'exploitation séparé avec sa propre pile réseau, si bien qu'un invité peut exécuter son propre tunnel et ses propres applications sans toucher aux routes de l'hôte. C'est une séparation plus forte qu'un second compte de session, et c'est aussi plus de travail de maintenance. Décidez si ce coût achète une frontière dont vous avez réellement besoin avant de le proposer.

Le mode de réseau virtuel doit encore être examiné. Que l'invité soit ponté, derrière NAT ou isolé détermine ce qu'il peut atteindre et ce qui peut l'atteindre, et les applications de l'hôte ne deviennent pas des applications invité parce que l'invité se trouve connecté. Vérifiez aussi la politique de blocage, sinon un tunnel invité tombé reviendra sur le chemin de l'hôte d'une manière que personne n'avait prévue.

Un proxy est plus étroit qu'un compte utilisateur

Une application hôte peut atteindre un véritable service proxy exécuté dans un invité ou un conteneur approuvé, et cela couvre le trafic que l'application envoie réellement via le protocole pris en charge. Cela ne couvre pas chaque processus possédé par ce compte Mac, ni le trafic que l'application envoie hors du protocole proxy.

Autre prudence sur les machines partagées : un écouteur TCP lié au loopback de l'hôte n'est pas une vérification de nom d'utilisateur. Restreindre un proxy à la machine locale le garde hors du réseau, mais n'autorise pas un utilisateur local face à un autre déjà connecté. Gardez l'authentification du service explicite si cette distinction compte.

Prouvez la frontière avec deux tests

Exécutez les deux chemins et observez-les séparément. Sous le compte prévu, ouvrez l'application qui a besoin de la ressource privée et confirmez qu'elle atteint le service géré ; sous l'autre compte, confirmez que la navigation ordinaire garde le chemin domestique. Puis cassez le tunnel exprès et vérifiez le comportement de repli de chaque côté, car c'est là que la plupart des conceptions échouent silencieusement. Faites les contrôles dans la même heure aussi, pour qu'un réseau changé ne contamine pas la comparaison.

Si un conteneur ou un invité exécute le tunnel, ajoutez un troisième contrôle : confirmez qu'une application Mac native en dehors se comporte toujours comme prévu. Choisissez la disposition la plus simple dont vous pouvez démontrer la portée, et n'étiquetez pas les machines virtuelles comme universellement nécessaires ni le changement de compte comme universellement suffisant avant d'avoir fait ces tests.