Deux VPN à la fois ? Définir d’abord la frontière du point de terminaison

Deux clients VPN connectés en même temps placent un point de terminaison dans deux domaines de ressources, et c’est une question d’autorisation avant d’être une question de routage. Le fait que les tunnels soient chiffrés ne dit rien sur la question de savoir si les applications de ce portable doivent pouvoir atteindre les deux réseaux, ni si un pair d’un réseau doit pouvoir atteindre l’autre à travers lui. Parcourez les contrôles ci-dessous dans l’ordre et arrêtez-vous au premier auquel personne ne peut répondre. Approuver le chevauchement sans ces réponses, c’est ainsi qu’un arrangement commode devient discrètement un pont.

Partez du travail réel : de quelles ressources dans chaque réseau la personne a-t-elle besoin, et les deux propriétaires de réseau autorisent-ils un accès simultané depuis un seul appareil ?

Vérifiez qui autorise le chevauchement

Deux réseaux qui authentifient chacun le même utilisateur ont toujours des propriétaires distincts, et ces propriétaires peuvent avoir des hypothèses incompatibles sur des appareils également rattachés ailleurs. Interrogez les deux avant de concevoir quoi que ce soit. Une politique d’accès distant écrite pour des portables isolés n’a souvent aucune réponse pour une machine simultanément à l’intérieur d’un réseau partenaire.

Obtenez la réponse par écrit et conservez-la avec l’enregistrement du changement. Si un côté dit non, le reste de cette liste est théorique, et vous vous êtes épargné une revue de conception.

Ne traitez pas deux interfaces comme un routeur

Deux interfaces actives ne font pas automatiquement de l’appareil un routeur ni un pont Ethernet. Vérifiez la configuration prise en charge du transfert, du pontage, du NAT et du proxy avant de décrire quoi que ce soit comme un chemin de transit, et préservez toute tâche de routage autorisée et sans rapport que l’appareil assume déjà. Un portable qui exécute un réseau de conteneurs local ou un hôte de virtualisation n’est pas ici un observateur neutre.

Si l’exigence est réellement un transit de A vers B, cela relève d’un équipement réseau avec un propriétaire, un jeu de règles auditable et un processus de changement. Le faire accidentellement via un poste de travail est le résultat que ce contrôle existe pour éviter.

Traitez aussi le point de terminaison comme un point d’accès

L’appareil n’est pas seulement un client des deux réseaux ; c’est un hôte qui offre des services. Un service autorisé sur cette machine peut être joignable depuis un pair VPN selon le pare-feu de l’hôte et la politique du client, donc un port de gestion exposé sur le portable fait désormais partie de la surface d’attaque du réseau distant. Énumérez ce qui écoute avant de discuter des routes, car un port de débogage lié pèse plus que toute politique de tunnel. Limitez les services de l’hôte à leurs sources et usages prévus.

Traitez chaque réseau distant comme un domaine de ressources aux permissions explicites plutôt que d’accorder une confiance large parce que le trafic est arrivé chiffré. L’architecture zéro confiance du NIST sépare l’autorisation des ressources de la confiance implicite dans l’emplacement réseau, et c’est exactement la distinction qu’un portable à deux tunnels brouille.

Posez une question de plus tant que vous êtes là : si un service local ou une application autorisée était compromis, quelles ressources et quels identifiants deviendraient joignables depuis ce point d’appui ? Écrivez la réponse, car c’est l’énoncé de risque réel pour toute la conception.

Choisissez la frontière de travail adaptée au modèle de menace

Le routage par application peut affecter des programmes aux tunnels prévus, et des profils de travail, utilisateurs ou espaces de travail virtuels pris en charge peuvent ajouter des frontières d’identité et de données selon la plateforme. Alignez la frontière sur le modèle de menace plutôt que sur la démonstration : une séparation de routage sans séparation d’identité laisse encore un profil de navigateur détenir les deux sessions.

Un espace de noms réseau isole le routage et l’état réseau ; il n’isole pas chaque chemin du système de fichiers, le presse-papiers ni l’agent d’identifiants. Une machine virtuelle ou un profil géré nécessite de même une politique délibérée de partage et d’administration de l’hôte. Notez quels dossiers, assistants d’authentification et chemins de copier-coller restent disponibles, car ce sont les canaux qui transportent réellement des données entre les deux domaines.

Pour un travail séquentiel, un basculement intentionnel est généralement plus simple que de maintenir un accès concurrent. Terminez l’opération dépendante, puis vérifiez l’identité et la route de l’espace de travail suivant au lieu de laisser des outils d’arrière-plan attachés à un contexte ambigu.

Écrivez l’approbation comme une tâche, pas un slogan

Un enregistrement d’approbation devrait se lire comme une tâche : l’espace de travail de support peut atteindre la console de services du réseau A et le portail de tickets du réseau B, sans transfert autorisé de A vers B, sans agent d’identifiants partagé et sans synchronisation automatique de fichiers. Chaque partie de cette phrase correspond à quelque chose que vous pouvez configurer et tester.

Vérifiez ensuite les cas négatifs, pas seulement les positifs. Essayez d’atteindre une ressource qui devrait être hors de la frontière, confirmez que le service de l’hôte ne répond pas depuis l’autre côté, et vérifiez que l’assistant d’identifiants ne sert pas silencieusement les deux domaines.

Conservez l’enregistrement avec l’appareil, pas seulement dans le ticket, afin que la personne suivante qui hérite de l’arrangement sache quelle frontière était délibérée. Un portable à deux tunnels et sans frontière écrite est indistinguable d’une mauvaise configuration.