Trois façons de travailler sur plusieurs VPN sans confusion

Deux tunnels clients, un ordinateur portable et un onglet de navigateur encore connecté là où il ne devrait pas l'être. La partie difficile du travail sur plusieurs réseaux privés n'est pas la connexion ; c'est de savoir à quel contexte appartient une fenêtre quand on bascule. Un espace de travail répond à cette question : une identité, un ensemble d'applications, une politique de résolution et un endroit où regarder quand quelque chose se résout mal. Un mauvais jour, c'est la différence entre une correction de cinq minutes et une fuite de données.

Décidez si le travail est simultané

Si la réponse est non, arrêtez-vous ici et utilisez la disposition la plus simple disponible. Une connexion approuvée à la fois, connectée et déconnectée via le client qui possède le profil, élimine toute une classe de défaillances avant que l'une d'elles puisse survenir.

C'est la simultanéité qui augmente le coût : les préfixes qui se chevauchent, deux politiques de résolution et deux ensembles d'état d'applications doivent être séparés délibérément, pas par le temps.

Écrivez l'exigence honnêtement, car vouloir éviter une reconnexion n'est pas la même chose que d'avoir besoin des deux réseaux à la fois.

Le séquentiel est la disposition la moins chère

Le travail séquentiel ne demande aucune infrastructure supplémentaire, et son mode de défaillance est une session périmée plutôt qu'un conflit de routage. La discipline est dans la passation : terminez l'opération, fermez ce qui détient une connexion, déconnectez-vous et confirmez la connexion suivante avant de commencer à travailler.

Un onglet de navigateur ou un terminal qui reste ouvert ne porte pas son contexte réseau avec lui. Sa requête suivante va là où la machine route maintenant, ce qui peut être l'autre client.

Étiquetez les profils par client plutôt que par protocole, et gardez le propriétaire des identifiants visible dans le nom du profil. Un profil nommé work2 ne dit rien à personne au moment d'une bascule précipitée.

L'avantage de cette disposition est qu'elle est auditable. À tout instant, il y a un seul contexte réseau, et le journal montre quand il a changé.

Un espace de travail par client coûte l'isolement

Une machine virtuelle ou un environnement de développement distant par client réunit le client, les applications et les noms au même endroit. La bascule devient un changement de fenêtre plutôt qu'un changement de réseau, et les deux contextes ne peuvent pas fuir l'un dans l'autre par une route égarée.

Ce n'est pas gratuit. Vous maintenez désormais deux ou trois systèmes, vous les corrigez et vous décidez où vivent les fichiers et les identifiants. La machine virtuelle atteint aussi Internet via l'hôte, donc son chemin extérieur reste celui de votre ordinateur portable.

Vérifiez que le client et toute politique d'état de l'appareil autorisent cet environnement avant de bâtir l'habitude autour de lui. Un client qui refuse de fonctionner dans une machine virtuelle est un fait à découvrir tôt.

Une passerelle partagée est une infrastructure

Un routeur distinct transportant le trafic sélectionné transforme le problème en conception de réseau. Il fonctionne bien lorsque plusieurs personnes ont besoin du même réseau client, et il échoue quand quelqu'un le traite comme une boîte magique qui garde chaque client séparé.

Une passerelle qui bascule son tunnel actif est un seul contexte partagé avec une file d'attente, pas plusieurs réseaux indépendants. Nommez qui peut la modifier, quelles sources elle sert et ce qui se passe lorsque deux personnes ont besoin de clients différents en même temps. Sans cette réponse, la passerelle devient une source de pannes que personne ne possède. Elle devient aussi l'endroit où quelqu'un désactive discrètement une vérification pour tenir une échéance.

Écrivez la passation dans un enregistrement

L'enregistrement n'a pas besoin d'être sophistiqué ; il doit être assez précis pour que quelqu'un d'autre puisse le suivre. Sous Linux, un espace de noms est la version technique de la même idée, avec ses propres interfaces et sa propre table de routage.

Ces commandes créent un espace de noms, exécutent une commande à l'intérieur et montrent quelles connexions le client de bureau détient actuellement :

sudo ip netns add customer-a
sudo ip netns exec customer-a ip route
nmcli connection show --active

Les applications doivent encore être lancées à l'intérieur de l'espace de noms, et la configuration de résolution qui s'y trouve est un fichier distinct. Isoler les interfaces n'isole pas le presse-papiers, l'agent SSH ou un partage monté, et ce sont ces fuites que les gens oublient.

Choisissez la plus petite disposition qui préserve la séparation dont vous avez réellement besoin, et gardez la transition visible : le titre de la fenêtre, l'invite du terminal, le nom du profil et le propriétaire des identifiants doivent tous concorder avant qu'une requête privée soit envoyée.