Deux appareils, un seul Wi-Fi, des sorties VPN différentes : ce qui le décide

Deux ordinateurs portables sur le même routeur domestique peuvent atteindre Internet par des sorties VPN différentes, et le Wi-Fi partagé n’a rien à y voir. Ce qui décide du résultat, c’est l’endroit où tourne le tunnel et la politique qui choisit le chemin de chaque requête. La croyance inverse est aussi répandue et aussi fausse : deux appareils dotés de profils séparés ne produisent pas automatiquement deux adresses publiques. Les deux erreurs viennent de traiter une adresse comme s’il y en avait trois.

Trois adresses, et une seule d’entre elles sort

Un ordinateur portable possède une adresse sur le LAN domestique qui l’identifie sur le segment local, et il peut aussi avoir une adresse de tunnel attribuée à l’intérieur du VPN. Ni l’une ni l’autre n’est visible pour un service distant. Ce que ce service enregistre, c’est l’adresse de sortie publique de l’appareil qui finit par envoyer le paquet, après toute traduction sur le chemin.

La RFC 3022 trace la distinction qui explique l’essentiel de la confusion ici. Le NAT traditionnel fait correspondre des adresses internes à des adresses publiques, tandis que la traduction de ports permet à de nombreuses adresses internes de partager une seule adresse publique en même temps. Un foyer avec une adresse publique et plusieurs appareils relève du second cas, et c’est le comportement par défaut presque partout.

Comptez les adresses publiques, pas les profils. Deux clients avec des adresses de tunnel différentes et la même politique de sortie produisent une seule adresse observée, et un seul client dont la sortie est routée autrement peut en produire une autre. Cette unique comparaison est tout le test. Le reste n’est qu’une supposition sur l’extrémité distante.

Ce qui rend deux sorties réellement différentes

Une sortie est différente lorsque le dernier appareil avant Internet utilise une autre adresse publique pour ce trafic. Cela peut arriver parce que le VPN se termine ailleurs, parce que le pool de sortie attribue une autre adresse, ou parce que le fournisseur achemine la requête par une autre sortie. Les trois sont des décisions de politique prises à l’extrémité distante, et aucune n’est visible depuis le routeur domestique.

Deux appareils qui exécutent chacun leur client avec le même profil atterrissent généralement dans le même pool et reçoivent souvent la même sortie pour une session donnée. Ce n’est pas un défaut, c’est le comportement normal d’un pool partagé. Obtenir des sorties distinctes signifie généralement demander au service des attributions distinctes plutôt que configurer le client deux fois.

Lisez les conditions du service sur les connexions simultanées avant de concevoir autour d’une garantie. Une seconde connexion est une autorisation de se connecter, pas une promesse d’adresse exclusive. Si les conditions sont muettes, demandez au fournisseur au lieu de supposer. La réponse change la conception plus que n’importe quel réglage du client.

Pourquoi des profils séparés ne sont pas des sorties séparées

Un profil décrit comment atteindre le VPN et comment s’authentifier, et il ne dit presque rien de ce qui se passe ensuite. La sortie est choisie par l’extrémité distante, où vivent le routage, les pools d’adresses et la politique de traduction. Dupliquer un profil sur une seconde machine duplique la configuration du client, pas la décision du serveur.

L’inverse est vrai aussi. Un serveur VPN peut présenter plus d’une sortie publique lorsque son routage et sa politique de traduction sont construits ainsi, tandis que des serveurs séparés peuvent alimenter une seule sortie en aval. Le nombre de noms de serveurs dans votre configuration ne dit donc rien du nombre d’adresses. C’est pourquoi la configuration est le mauvais endroit pour chercher cette réponse.

La seule réponse fiable vient d’une requête effectuée à travers le dispositif que vous comptez utiliser. Tout le reste est une inférence.

Où placer la séparation

Un tunnel sur le routeur couvre tout le foyer, ce qui est pratique et produit exactement une sortie partagée pour chaque appareil derrière lui. Un client sur chaque appareil vous donne un contrôle par appareil, mais exige que chaque appareil soit provisionné et le reste. Un routeur capable de politiques se place entre les deux, choisit un chemin par appareil, et il ne fonctionne que s’il identifie les appareils de façon fiable à travers les reconnexions et les changements DHCP.

Créer un autre bail DHCP privé sur le routeur n’est pas la même chose que créer une autre adresse publique. Cela change la vue locale et laisse la sortie intacte. La séparation vit dans la politique de sortie, que cette politique soit sur le routeur ou dans le service VPN.

Quelle que soit la forme choisie, écrivez la responsabilité : qui provisionne un appareil, qui renouvelle son identifiant et qui remarque quand il cesse d’utiliser le chemin prévu.

Vérifiez la sortie que vous avez réellement obtenue

Faites la vérification depuis l’application qui compte, et comparez la même famille d’adresses sur les deux appareils. Un résultat IPv4 de l’un et un résultat IPv6 de l’autre ne prouvent rien pour aucun des deux. Répétez ensuite la vérification après une reconnexion, car l’attribution du pool peut changer entre les sessions.

Exécutez-la depuis un terminal à l’intérieur de la politique du tunnel, pas depuis un appareil qui la contourne. Le mauvais hôte produit une réponse fausse et assurée.

curl -4 -sS https://api.ipify.org; echo
curl -6 -sS https://api64.ipify.org; echo
ip route get 1.1.1.1

Si les deux appareils affichent la même adresse IPv4, ils partagent une sortie quel que soit le nombre de tunnels actifs. Décidez ensuite de ce qui se passe quand le tunnel échoue : un client qui retombe sur le chemin direct remet les deux appareils sur l’adresse du domicile, et la séparation disparaît sans erreur. Confirmez ce comportement de repli avant de décrire le dispositif comme deux sorties, et rappelez-vous que des adresses différentes sont un résultat réseau et non deux identités anonymes.