Redirection de ports sur le partage de connexion Android : trois points d’entrée expliqués

Vous avez activé le point d’accès, connecté le VPN, ouvert un port dans l’application, et l’autre appareil ne peut toujours pas se connecter. La pièce manquante n’est presque jamais le port lui-même. C’est la question de savoir quelle machine possède la socket d’écoute et quelle adresse un autre appareil est censé joindre. Je déroule ce raisonnement depuis le téléphone vers l’extérieur, car l’écran où vous vous trouvez vous dit lequel des trois points d’entrée vous testez réellement.

Partez de l’endroit où le service tourne réellement

Ouvrez l’application censée accepter la connexion et lisez sa propre page d’état. Si elle indique qu’elle écoute, notez l’adresse sur laquelle elle s’est liée, car ce seul détail décide de la plupart des cas ci-dessous. Une application liée à 127.0.0.1 n’est joignable que depuis le téléphone lui-même, et aucun client du point d’accès, mappage opérateur ou sortie VPN n’y changera rien.

Confirmez ensuite quel appareil fait tourner le service. C’est soit le téléphone, et la socket appartient alors à cette application, soit un ordinateur portable derrière le point d’accès, et l’écouteur comme son pare-feu appartiennent alors au portable tandis que le téléphone ne fait que transmettre les paquets. Ce sont des conceptions différentes avec des propriétaires différents, et les confondre explique pourquoi un port ouvert d’un côté ne fait rien de l’autre.

Sur une compilation débogable, adb shell peut lister les sockets via /proc/net/tcp, mais pour la plupart des gens l’état affiché par l’application est la source honnête. Cela évite aussi le piège de tester une socket que l’application a ouverte sur une adresse que vous n’attendiez pas.

Premier point d’entrée : un autre appareil sur le point d’accès

C’est le cas local, et le plus facile à réussir. L’autre appareil joint le téléphone à l’adresse qu’il voit comme sa passerelle, sur le port écouté par l’application, et rien à l’extérieur du point d’accès n’a besoin d’intervenir. Aucun mappage opérateur n’est nécessaire et aucune fonctionnalité de fournisseur ne doit exister, car le trafic ne quitte jamais le segment local.

Deux choses le cassent. L’application liée à la boucle locale, ou la stratégie de client du téléphone qui n’autorise pas la connexion locale. Testez avec le protocole propre à l’application plutôt qu’avec un simple TCP connect si l’application s’authentifie, car un écouteur qui accepte puis refuse ressemble à distance à un port fermé.

Si le service tourne plutôt sur un portable partagé en connexion, l’adresse du point d’accès du téléphone n’est pas du tout la destination. Il vous faut l’adresse du portable sur l’interface du point d’accès et un écouteur sur le portable, et le téléphone n’est plus propriétaire de rien sauf du transfert.

Deuxième point d’entrée : le chemin de l’opérateur

Joindre le téléphone depuis le réseau mobile est un autre problème, et la plupart du temps cela ne fonctionne tout simplement pas en IPv4. Les opérateurs placent les téléphones derrière une translation partagée, et c’est pourquoi RFC 6598 réserve une plage d’adresses partagées pour exactement ce montage. Une connexion entrante non sollicitée n’a aucun mappage par lequel arriver, et aucune configuration locale n’en crée un, car le traducteur n’est pas votre appareil.

L’accès root ne change pas cela non plus. Il vous donne le contrôle de la pile du téléphone, pas du traducteur de l’opérateur, et les recettes qui promettent le contraire supposent généralement une adresse publique que l’opérateur n’a jamais attribuée. Là où l’opérateur propose un préfixe IPv6 public, un chemin entrant peut exister, mais l’écouteur et le pare-feu du téléphone ont encore besoin d’une autorisation délibérée avant que quoi que ce soit réponde.

Troisième point d’entrée : la sortie VPN

L’adresse qu’un site web affiche tant que le tunnel est actif est celle de la sortie pour le trafic sortant couvert. Ce n’est pas la même chose qu’une adresse qui accepte des connexions entrantes en votre nom. L’utiliser en entrée exige une fonctionnalité que le fournisseur propose réellement, comme un port redirigé ou un mappage entrant lié à votre compte, plus un chemin utilisable depuis la sortie jusqu’au client.

Une règle d’autorisation locale ne peut pas fabriquer ce mappage. Ce qu’elle peut faire, c’est changer le chemin que prennent les réponses de l’application, ce qui compte lorsque l’application est exclue du tunnel : la requête et la réponse peuvent se retrouver dans des contextes réseau différents, et la connexion échoue d’une manière qui ressemble à un problème de pare-feu.

Testez un chemin de bout en bout, puis nommez le propriétaire

Écrivez le tuple avant de tester : source visée, adresse de destination, transport, port, et la machine qui possède la socket d’écoute. Si un élément est une supposition, le test ne vous apprendra rien d’utile, et vous finirez par modifier une seconde couche pour expliquer la première.

Testez ensuite ce seul chemin autorisé en gardant l’authentification de l’application intacte. Évitez de publier un écouteur large ou de désactiver des contrôles sans rapport juste pour faire répondre une vérification ambiguë d’adresse publique, car ces deux changements survivent au test et aucun ne prouve que la conception fonctionne.

Le sous-système de partage de connexion d’Android achemine le trafic descendant sur son propre chemin, distinct de la capture VPN ordinaire des applications, si bien qu’un navigateur qui fonctionne sur un portable partagé ne dit rien de l’accès entrant à un service sur le téléphone. Avant de déclarer que cela fonctionne :

• La socket d’écoute se trouve sur une adresse que le pair visé peut joindre, pas sur la boucle locale.
• Le pair utilise l’adresse qui appartient à ce point d’entrée, pas l’adresse de sortie affichée sur une page d’état.
• Tout mappage côté opérateur ou fournisseur est une fonctionnalité prise en charge, pas une règle que vous avez ajoutée localement.
• La requête et la réponse passent par le même contexte réseau, et l’authentification de l’application réussit toujours.