Tethering inversé pour Android par USB : commandes, contrôles, retour arrière

Le tethering inversé déplace le trafic d’un téléphone vers un ordinateur et le fait sortir par la connexion de cet ordinateur. Un câble USB seul n’y suffit pas : le téléphone a besoin d’un service de capture qui prend en charge son routage, et l’ordinateur d’un relais qui achemine ces paquets plus loin. Le chemin comporte quatre sauts : l’application, la capture sur le téléphone, le relais USB et la sortie de l’hôte, et chacun a un propriétaire différent. Ce guide construit ce chemin, place le VPN de l’hôte à sa place et vérifie chaque saut avant de vous fier au résultat.

Cartographiez les sauts avant d’exécuter quoi que ce soit

Chaque saut applique sa propre politique, c’est pourquoi un résultat qui fonctionne à une extrémité ne dit rien de l’autre. L’application choisit une destination et un résolveur, le service de capture décide quel trafic entre dans le relais, le relais transmet vers les sockets de l’hôte, et le routage et le VPN de l’hôte décident de l’adresse que la destination finit par voir.

Un seul client du service VPN peut tenir le rôle de capture du téléphone à la fois, donc une seconde application VPN ordinaire ne s’empile pas sur le relais. Si le VPN appartient à l’ordinateur, le service de capture est le lien d’accès vers cet ordinateur, non la preuve qu’un tunnel distant protège déjà le résultat.

Préparez le relais avant de toucher au téléphone

Gnirehtet est l’exemple documenté de cette architecture : un client du service VPN sans root sur le téléphone plus un relais transporté par ADB sur l’hôte, prenant en charge TCP et UDP sur IPv4. Son dépôt indique aussi que le projet n’est plus maintenu activement, traitez-le donc comme la conception de référence et un outil fonctionnel pour un laboratoire, non comme un produit pris en charge à normaliser sur un parc administré.

adb devices
adb shell getprop ro.build.version.release
gnirehtet run

Exécutez d’abord adb devices. Un téléphone qui n’a pas accepté la clé de débogage de l’hôte se signale comme non autorisé, et le relais ne s’attachera pas tant que l’invite sur l’appareil n’est pas acceptée. gnirehtet run installe le client, démarre le relais et active la capture ; sur une version qui sépare les étapes, utilisez plutôt les sous-commandes documentées install, relay et start.

L’accès ADB est une relation de contrôle d’appareil, pas un réglage réseau. N’autorisez qu’un ordinateur que vous contrôlez, et prévoyez de révoquer cette autorisation une fois la tâche terminée.

Remettez le VPN de l’hôte dans le chemin

Le relais est un processus ordinaire de l’hôte, donc ses connexions suivantes suivent la table de routage de l’hôte. Un profil de tunnel complet les transporte ; un tunnel divisé peut ne pas le faire. Si le VPN de l’hôte utilise des contrôles par application, ajoutez le binaire du relais à l’ensemble autorisé, sinon le relais continue d’utiliser l’interface physique pendant que le navigateur paraît protégé.

ip route get 1.1.1.1
curl -4 https://ifconfig.me
sudo ss -tnp | grep -i relay

Exécutez les deux premières commandes avant et après la connexion du VPN de l’hôte. Si l’adresse ne change pas, le relais n’est pas sur le tunnel, quoi que dise la fenêtre du client. Un tunnel réservé au privé laisse aussi les destinations publiques sur la sortie normale de l’hôte, ce qui ressemble à une fuite mais correspond à la politique que vous avez configurée.

Le DNS est résolu sur l’hôte pour le trafic qui passe par le relais, donc le résolveur de l’hôte décide quel serveur voit les noms. Un réglage DNS privé sur le téléphone ne traverse pas le relais, et un test de résolveur côté téléphone ne décrira pas les requêtes de l’hôte.

Vérifiez chaque saut séparément

Trois contrôles, dans cet ordre : le téléphone atteint le relais, le relais atteint la destination selon la politique de l’hôte, et l’application résout et utilise correctement cette destination. Arrêtez-vous au premier échec au lieu de recharger des pages et de deviner.

adb shell dumpsys connectivity | grep -i -A3 vpn
adb logcat -s GnirehtetRelay:V Gnirehtet:V

Une entrée de réseau VPN dans le vidage de connectivité montre que le service de capture est actif ; le journal propre au relais montre si des flux arrivent. L’absence dans l’un des deux sépare proprement le problème : pas de capture, c’est le côté téléphone ; pas de flux, c’est le côté hôte.

Un navigateur qui fonctionne sur l’hôte prouve le chemin du navigateur de l’hôte, pas celui du processus relais. Comparez les adresses que chacun rapporte, et testez une ressource privée ainsi qu’une page publique, car un tunnel réservé au privé peut router l’une et pas l’autre.

Démontez et choisissez le comportement en cas d’échec

Le retour arrière fait partie du guide. Arrêtez et supprimez le relais, désinstallez le client de capture et révoquez l’autorisation de débogage de l’hôte dans les options de développement du téléphone une fois la tâche terminée.

gnirehtet stop
gnirehtet uninstall
adb kill-server

Décidez ce que le téléphone doit faire lorsque le relais disparaît. Sans choix explicite, il peut retomber sur les données mobiles et laisser fuir le trafic que vous cherchiez à router, alors réglez délibérément le comportement de blocage des connexions ou la politique VPN et testez le démontage avant de vous y fier.

Consignez l’hôte autorisé, la version du relais, la politique de tunnel de l’hôte et les étapes de démontage. Cette consignation rend la prochaine installation de tethering inversé reproductible au lieu d’un autre après-midi de redécouverte.