Ouvrir un second navigateur ne crée pas une seconde route VPN

Deux navigateurs, deux fenêtres, l’une sur le compte professionnel et l’autre sur un compte personnel, et l’hypothèse est qu’ils empruntent désormais des chemins différents. Ils ne le font pas. La séparation des profils garde les cookies à part, tandis que la décision de routage se prend sous le navigateur et ignore quel profil a demandé. Une seconde voie exige une règle qui la choisit, et il n’existe que quelques endroits où cette règle peut vivre.

Séparer l’état n’est pas séparer le chemin

Un profil de navigateur isole le stockage : cookies, historique, extensions et parfois identifiants. Cette isolation s’applique à l’intérieur d’un seul arbre de processus et n’a rien à dire sur l’interface qui transporte un paquet.

Les fenêtres privées vont plus loin en apparence et pas d’un pas en routage. Tout ce que le navigateur envoie sort toujours par le chemin choisi par le système d’exploitation, sauf si quelque chose entre la socket et le réseau le change. Confondre l’isolation du stockage avec l’isolation réseau crée des attentes qu’aucun éditeur de navigateur n’a promises et qu’aucun test ne peut satisfaire.

Ce qui choisit réellement une route

Quatre choses peuvent choisir un autre chemin : une règle VPN par application qui correspond à l’exécutable ou au paquet, un proxy configuré dans le navigateur ou le système, un espace de noms réseau ou un conteneur, et un second appareil physique. Chacune change quelque chose de réel, et chacune a un coût.

Une règle par application est la réponse habituelle sur les plateformes mobiles, où le service VPN reçoit une liste de paquets. Sur un poste de travail, cela dépend du client, et une règle qui correspond à l’exécutable couvre tous les profils que cet exécutable ouvre. Si deux profils ont réellement besoin de chemins différents, il leur faut généralement deux processus aux identités différentes plutôt que deux onglets. C’est pourquoi une installation partagée du navigateur ne peut jamais être la frontière dans une conception par profil.

Les proxys au niveau applicatif ajoutent un intermédiaire de plus

Un réglage de proxy dans le navigateur crée bien un chemin séparé, et il crée aussi une relation de confiance séparée avec celui qui exploite le proxy. C’est un arrangement légitime pour un profil, et il n’équivaut pas à une couverture de tout l’appareil.

Choisissez le proxy délibérément : un écouteur SOCKS sur le même hôte, un proxy authentifié à l’intérieur du tunnel, ou un service distant. Mélanger un proxy à un VPN en tunnel complet produit des chemins imbriqués où les modes de défaillance se multiplient.

Vérifiez la requête réelle de chaque navigateur

Envoyez la même requête depuis chaque navigateur et comparez l’adresse de sortie observée, plutôt que de comparer les pages de réglages. Un proxy configuré qui échoue silencieusement à se connecter est un moyen très courant de revenir sur le chemin par défaut.

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --proxy socks5h://127.0.0.1:1080 https://api.ipify.org
dig +short example.com

Répétez ensuite la requête avec le proxy forcé et avec le tunnel coupé, pour voir quelle couche transporte réellement le trafic. Notez aussi la réponse DNS, car un navigateur doté de son propre résolveur chiffré peut contourner entièrement le chemin du système et afficher quand même la page que vous attendiez.

Écrivez la correspondance prévue en deux lignes : quel processus utilise quel chemin, et qui possède chacun d’eux. Gardez aussi les identités de compte à l’esprit, car deux chemins n’empêchent pas la même connexion d’être présentée aux deux destinations. Retestez après la prochaine mise à jour du navigateur, car un réglage de proxy se perd facilement et se remarque difficilement.