Proxy SOCKS SSH sur Android : pourquoi la moitié de vos applications ne se connecte pas

Vous vous connectez en SSH, ajoutez -D 1080, et la commande réussit. Un écouteur SOCKS existe maintenant sur le téléphone, et la moitié des applications sortent toujours par les données mobiles. C'est le résultat normal, pas un tunnel cassé : ssh -D crée un point de proxy, et les applications Android n'utilisent un proxy que si quelque chose les y oblige. Parcourir la chaîne étape par étape montre où vit réellement chaque partie du travail.

Commencez là où le trafic commence

Choisissez une application qui devrait utiliser le tunnel et vérifiez si elle a son propre réglage de proxy. Un navigateur avec un champ SOCKS est le cas facile : pointez-le vers 127.0.0.1:1080, activez le DNS distant si le réglage existe, et la requête passe. Un client de messagerie, une application de cartes ou un jeu sans ce champ n'ont aucun moyen d'utiliser l'écouteur, et rien de ce que vous tapez dans la commande SSH ne change cela.

Avant d'impliquer quoi que ce soit d'autre, prouvez que l'écouteur fonctionne depuis le shell du téléphone avec un client qui parle SOCKS directement :

ssh -N -D 1080 [email protected]
curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me

L'adresse qui revient doit être celle du serveur SSH, pas celle du téléphone. Si c'est le cas, la moitié proxy est terminée et le reste du travail concerne la couverture. Sinon, corrigez d'abord le côté SSH : authentification par clé, capacité du serveur à atteindre la destination, et sortie propre au serveur SSH.

Ajoutez la pièce dont Android a besoin

Les applications sans réglage de proxy ont besoin de quelque chose qui capture leurs paquets et les transforme en connexions proxy. Sur un appareil non rooté, c'est un adaptateur de service VPN : une application qui prend l'interface virtuelle et transmet le trafic sélectionné vers l'écouteur SOCKS local. La chaîne devient application, adaptateur, écouteur SOCKS, connexion SSH, destination.

Installez l'adaptateur, accordez-lui l'autorisation VPN et choisissez les applications ou routes qu'il doit capturer. L'icône de clé dans la barre d'état représente alors l'adaptateur, pas un VPN commercial distinct. Android n'autorise qu'une connexion de service VPN active par profil utilisateur, donc lancer une seconde application VPN n'ajoute pas une couche sur la chaîne : elle entre en concurrence pour le même rôle.

C'est aussi l'étape où un test réussi peut vous tromper. Si l'adaptateur est configuré pour ne capturer que le navigateur déjà pointé vers le proxy, tout fonctionne et rien d'autre n'est couvert. Lisez la liste de capture avant de conclure que l'appareil est tunnelisé.

Gardez le transport SSH hors de la capture

La connexion SSH elle-même ne doit pas être réinjectée dans le tunnel SOCKS qu'elle maintient. Si l'adaptateur capture le trafic de l'application SSH, le tunnel dépend d'une connexion qui attend le tunnel, et le résultat est une boucle qui se bloque ou échoue dès que l'adaptateur démarre.

Les implémentations intégrées protègent leur propre socket de transport. Avec des applications séparées, il vous faut une exclusion prise en charge : laissez l'application SSH hors de la capture, ou excluez le point de terminaison SSH par adresse. Les deux ont un coût. Exclure toute une application de terminal retire aussi du tunnel son activité réseau sans rapport, et une exception d'adresse casse quand l'adresse du serveur change ou quand le nom se résout autrement à la connexion suivante.

Vérifiez l'exclusion depuis l'extérieur : reconnectez l'adaptateur, puis confirmez que la session SSH survit et que la requête proxifiée rapporte toujours l'adresse du serveur. Une session qui fonctionne jusqu'au démarrage de l'adaptateur puis se fige, c'est la boucle.

Suivez le DNS et l'UDP jusqu'au bout de la chaîne

Le transfert dynamique d'OpenSSH transporte des connexions TCP. Ce n'est pas un transport UDP-associate ni ICMP, et un adaptateur ne peut pas inventer un transfert UDP en acceptant des paquets UDP. Tout ce qui exige UDP, y compris QUIC et les médias WebRTC, échouera ou retombera sur TCP selon l'application.

Le DNS a besoin de sa propre décision. Une application qui résout un nom localement envoie la requête via le résolveur normal avant de se connecter, donc le tunnel transporte la connexion mais pas la résolution. Un client conscient du proxy avec une option de DNS distant l'évite ; une application capturée sans cette option non. Vérifiez quel résolveur a répondu au lieu de supposer que l'adaptateur l'a changé.

Gardez l'écouteur SOCKS lié au loopback, vérifiez la clé d'hôte du serveur SSH à la première utilisation, et laissez la validation HTTPS normale en place pour le site final. SSH protège le segment téléphone-serveur ; il ne chiffre pas ce que le serveur fait ensuite.

Vérifiez les deux durées de vie et décidez

L'adaptateur et la session SSH ont des durées de vie distinctes. Si SSH tombe alors que l'adaptateur continue de capturer, les applications peuvent se bloquer sans erreur évidente, car leurs paquets entrent encore dans une interface virtuelle qui n'a plus de sortie fonctionnelle. Si l'adaptateur s'arrête, les applications passent en direct ou sont bloquées, selon la politique VPN de l'appareil.

Testez les deux sens délibérément : tuez la session SSH avec l'adaptateur en marche, puis arrêtez l'adaptateur pendant que SSH reste actif. Ce que fait le téléphone dans chaque cas est la politique que vous déployez réellement, quoi qu'aient affirmé les instructions d'installation.

Si le flux de travail exige une couverture de tout l'appareil avec un mode de défaillance prévisible, un vrai VPN IP, ou un adaptateur maintenu conçu pour cette chaîne, est la réponse honnête. Une session shell laissée active à côté d'une application de capture sans rapport n'est pas un tunnel d'appareil maintenu ; ce sont deux composants sans accord sur ce qui se passe quand l'un d'eux se termine.