Une connexion VPN sur un PC partagé : qui d'autre obtient la route ?

Partager une station de travail soulève une question à laquelle un portable mono-utilisateur n'a jamais à répondre : une fois qu'une personne authentifie le tunnel, qui d'autre peut l'utiliser ? La connexion identifie un sujet, et la route qu'elle installe décrit une portée, et ces deux choses ne sont pas le même objet. Entre elles se trouvent le système d'exploitation, la configuration du client et ce que le service privé exige de lui-même. Comparer les points d'application est le seul moyen de répondre sans deviner.

Une connexion, plusieurs portées

L'authentification répond qui a été admis. La route répond quels paquets peuvent sortir par le tunnel. L'autorisation répond quel service acceptera la connexion résultante, et aucune des trois n'implique la suivante.

Un tunnel à l'échelle de l'hôte est la valeur par défaut courante, et il rend l'écart évident. La route se trouve dans la table du noyau, donc tout processus qui utilise cette table peut atteindre le réseau privé, y compris celui lancé par un utilisateur qui n'a jamais vu la boîte de dialogue VPN. Ce n'est pas un défaut du tunnel ; c'est ce que signifie une route à l'échelle du système. Le service privé peut encore refuser la connexion, et c'est pourquoi l'accessibilité et l'autorisation exigent des réponses distinctes.

Écrire les quatre questions avant de tester empêche la revue de se réduire à l'une d'elles.

Où se situe réellement la frontière

Quatre dispositions couvrent la plupart des machines : un tunnel à l'échelle de l'hôte, une connexion par utilisateur, une liste d'applications autorisées et un espace de noms réseau ou une machine virtuelle séparés.

Chacune place le point d'application ailleurs, et les différences comptent plus que les étiquettes. Une connexion par utilisateur est appliquée par les autorisations du profil, non par l'écran de connexion du bureau. Une liste d'applications autorisées est appliquée à l'intérieur du client, qui décide de ce qu'il transportera. Un espace de noms ou une VM applique à la frontière de l'interface, si bien qu'un processus à l'intérieur ne voit pas du tout la route de l'hôte. Le nombre d'écrans de connexion sur la machine ne dit rien d'aucune d'elles.

Lire la table ligne par ligne montre que la vraie question n'est pas l'existence d'une isolation, mais l'endroit où elle est mise en œuvre.

Comparez quatre points d'application

Sous Linux, la table de routage est la première chose à inspecter, car un tunnel à l'échelle de l'hôte y apparaît et un espace de noms non. Exécuter la recherche en tant que second utilisateur est l'étape que les gens sautent ; la réponse diffère de celle obtenue en tant que soi-même, et cela explique le rapport.

Les deux vérifications suivantes portent sur la stratégie, non sur le routage. Une règle de pare-feu correspondant à un UID s'applique au trafic généré localement, elle peut donc séparer deux utilisateurs sur un même hôte même lorsque les deux partagent la route. Un profil de connexion avec une liste d'autorisations explicite est appliqué par le gestionnaire de réseau à l'activation. Aucune des vérifications n'exige de modifier le tunnel, et c'est pourquoi elles valent la peine avant toute refonte.

ip route get 10.40.2.10
sudo -u bob ip route get 10.40.2.10
nmcli connection show vpn-work | grep -i permission
sudo nft list ruleset | grep -n skuid

Si la seconde recherche montre la route du tunnel, la frontière n'est pas là où la conception le supposait.

Les règles de sessions simultanées sont un contrôle distinct

Les passerelles limitent souvent le nombre de sessions qu'un compte peut détenir, et cette limite n'a rien à voir avec les utilisateurs locaux. Elle restreint le compte, si bien qu'une seconde personne qui se connecte avec les mêmes identifiants peut mettre fin au tunnel de la première.

Lisez l'échec avant de supposer un problème d'isolation local. Une limite de sessions produit une déconnexion à la passerelle, tandis qu'un problème de portée produit un tunnel qui fonctionne mais ne transporte simplement pas le trafic de l'autre utilisateur. Ces deux symptômes mènent à des correctifs complètement différents. Conservez le message exact du client, car il nomme généralement la règle. Demandez au propriétaire du profil le flux de travail approuvé plutôt que de contourner la limite.

Une machine virtuelle n'exempte personne de cette règle et ajoute sa propre conception réseau et d'identifiants.

Testez le contexte qui vous importe

Testez l'utilisateur et l'application prévus, puis testez un contexte qui devrait être refusé. Une revue qui ne prouve que le mot de passe d'origine fonctionne a testé l'authentification et rien d'autre.

sudo -u bob curl -sS -m 5 https://intranet.internal/health
wg show
ss -tnp | grep -E ':443|:51820'

Notez le point d'application à côté de chaque résultat : la table de routage, une règle d'UID, une autorisation de profil ou la stratégie de sessions de la passerelle. Cette trace rend le changement suivant vérifiable. Elle empêche aussi la même question d'être rouverte chaque fois que quelqu'un remarque un second écran de connexion. L'accessibilité n'est pas l'autorisation, et ni l'une ni l'autre n'est l'isolation.