Le navigateur du téléphone signale une adresse dans un autre pays et l'ordinateur portable connecté à son partage de connexion signale toujours l'opérateur mobile. Aucune des deux observations n'est fausse, et la contradiction que les gens voient vient de l'hypothèse que partager une connexion internet revient aussi à partager un tunnel. Trois conditions décident si le trafic de l'appareil rattaché entre dans le VPN du téléphone, et une seule d'entre elles concerne les réglages du téléphone. Parcourez-les avant de chercher une fonction de partage qui n'existe peut-être pas.

Ce que le partage de connexion transmet réellement

Le partage de connexion donne à l'ordinateur un chemin vers internet via l'interface mobile du téléphone. Le téléphone transmet ces paquets et, dans le cas ordinaire, traduit les adresses de l'ordinateur à leur sortie. C'est une fonction de transmission, et transmettre n'est pas la même chose que capturer du trafic dans un tunnel.

Que les paquets transmis entrent ensuite dans le VPN du téléphone dépend de la façon dont l'application VPN a installé ses routes et ses règles. Une application qui ne capture que le trafic originaire du téléphone ne verra pas les paquets que le noyau transmet pour le compte d'un client rattaché.

C'est pourquoi les deux observations coexistent si facilement. Le navigateur du téléphone utilise le tunnel, les paquets de l'ordinateur empruntent le chemin de transmission, et rien dans l'un ou l'autre affichage ne vous ment. Les deux appareils ne posent simplement pas la même question à la même interface. Dès que vous voyez cette séparation, la plainte « pourquoi mon ordinateur n'est-il pas protégé » devient une question de conception plutôt qu'un bug.

Première condition : quel tunnel le téléphone exécute

Commencez par identifier la portée du VPN sur le téléphone. Un tunnel pour tout l'appareil, un tunnel par application et un proxy uniquement pour le navigateur sont trois choses différentes, et seul le premier a quelque chance de couvrir le trafic transmis. Regardez la description du fournisseur sur ce que l'application capture, pas l'icône de la barre d'état.

Vérifiez ensuite ce que le fournisseur dit du partage de connexion. Certains documentent explicitement que le trafic ordinaire du partage est hors du tunnel, ce qui est la réponse honnête pour un service grand public qui n'a jamais promis d'être un routeur. Le guide de Proton VPN pour le partage de connexion Android est un exemple publié de cette distinction ; la documentation de votre propre fournisseur est celle qui compte pour votre appareil.

Une icône VPN dans la barre d'état vous dit que le téléphone a un tunnel. Elle ne vous dit pas quelles interfaces ce tunnel couvre, et c'est dans cet écart que vit l'essentiel de la confusion.

Deuxième condition : le partage de connexion est-il inclus

Même un tunnel pour tout l'appareil peut exclure par conception le trafic transmis, car les règles de routage de l'application ont été écrites pour des paquets générés localement. Inclure des clients rattachés exige généralement que le fournisseur le prenne explicitement en charge, ou un appareil rooté avec des règles personnalisées que la plupart des gens ne devraient pas tenter.

Passer du Wi-Fi à l'USB ne change rien. Le sous-système de partage prend en charge plusieurs transports, mais le transport n'est pas la décision de routage. Un câble rend la liaison plus stable et ne fait rien pour la couverture du tunnel, et c'est pourquoi le conseil « utilisez simplement l'USB » répond à une autre question que celle posée.

Les vieilles recettes qui vident les règles du pare-feu et supposent des noms d'interface précis ne sont pas des instructions portables. Elles ont été écrites pour un appareil précis, une ROM précise et une année précise, et les appliquer à un téléphone actuel cassera plus probablement le partage qu'il n'étendra un tunnel.

Troisième condition : quelle identité la destination exige

C'est la condition qui tranche généralement la conception, et elle n'a rien à voir avec les partages de connexion. Si l'ordinateur doit atteindre le réseau d'un employeur, l'identité qui compte appartient à l'ordinateur, et un VPN grand public sur le téléphone ne peut pas la fournir.

ip -brief addr show
curl -sS https://ifconfig.me/ip
dig +short myip.opendns.com @resolver1.opendns.com

Exécutez ces commandes sur l'ordinateur, pas sur le téléphone, car la question est ce que la destination voit depuis l'appareil qui vous intéresse. Une adresse publique signalée par le téléphone répond à une question sur le téléphone.

Même un résultat concordant depuis l'ordinateur reste une preuve limitée. La résolution de noms, les autres applications et le comportement en cas de défaillance du tunnel appartiennent à l'appareil dont vous testez la couverture, et une seule requête HTTP ne caractérise aucune de ces choses. Testez l'application qui vous importe vraiment, puis retestez-la avec le tunnel délibérément déconnecté.

Que faire à la place, par ordre d'effort

La réponse correcte la moins coûteuse est d'exécuter le VPN sur l'ordinateur. Connectez-le au partage de connexion, laissez le téléphone fournir la connexion mobile sous-jacente et établissez le tunnel depuis l'appareil qui a besoin de l'identité. Cela fonctionne avec les VPN d'entreprise, qui est le cas qui compte le plus.

Si l'appareil ne peut pas du tout exécuter un client VPN, cherchez une passerelle de partage explicitement prise en charge ou un routeur de voyage qui termine le tunnel. Lisez sa documentation pour la plateforme réelle au lieu de supposer qu'une fonction de partage est cette passerelle.

Si ni l'un ni l'autre n'est possible, acceptez la limitation plutôt que de la contourner avec une recette que vous ne pouvez pas maintenir. Le VPN du téléphone couvre le téléphone ; l'ordinateur a besoin de son propre chemin, et le savoir d'avance vaut plus qu'un après-midi d'expériences d'interfaces. Documentez l'arrangement pour que la personne suivante ne le redécouvre pas pendant un incident. Une ligne dans le wiki de l'équipe suffit.

Articles similaires