Masquer le proxy SOCKS local dans les clients VPN Android pour éviter la détection
Les clients VLESS populaires sur Android laissent un proxy SOCKS local ouvert sur un port fixe, permettant aux applications de détecter le VPN et de récupérer l'IP externe du serveur. Des tests avec des outils comme RKNHardering le confirment — même en mode split-tunneling, l'interface TUN, les routes système, les listes de paquets et le proxy accessible sont tous visibles. La solution ? Générer dynamiquement un port aléatoire et une authentification pour SOCKS5 inaccessibles aux autres apps.
Comment fonctionne la détection et comment s'en protéger
Les applications scannent localhost à la recherche de ports SOCKS ouverts. Les clients standards (v2RayTun, v2rayNG, Hiddify) ne les masquent pas, entraînant des fuites. Voici la parade :
- Générer un port aléatoire (comme 45478) à chaque lancement.
- Créer automatiquement des identifiants uniques (ex. : upu6CHvvV:ZJC3GMDXKOLFdPKAfxBxrHiU).
- Faire tourner le proxy uniquement pour un usage interne via tun2socks.
Cela bloque les scans : les autres apps ne peuvent pas se connecter sans identifiants et ne repèrent pas l'IP réelle.
Configuration technique avec Xray et tun2socks
Xray-core propose des binaires multiplateformes pour VLESS/VMess. Pour un support TUN complet, on remplace le tunneling natif d'Xray par tun2socks (build statique linux-arm64). La configuration :
- Lancer Xray avec SOCKS5 sur un port aléatoire.
- tun2socks redirige le trafic du descripteur de fichier TUN vers le proxy.
- Un wrapper Flutter + Kotlin + C++ gère les processus.
Pour contourner les restrictions Android 10+ (violations W^X) : emballer les binaires en fichiers lib/*.so.
Exemple de journal de lancement :
[2026-04-12T09:44:46.641632] [INFO] Starting VPN
[2026-04-12T09:44:46.641818] [INFO] Underlying network set: 176
[2026-04-12T09:44:46.641946] [INFO] nativeSetMaxFds result (parent): 0
[2026-04-12T09:44:46.643867] [INFO] TUN established, dup fd=142
[2026-04-12T09:44:46.644004] [INFO] xray started
[2026-04-12T09:44:46.644130] [INFO] Starting tun2socks (native): /data/app/~~_xfukaXUtA4X7kd1BmB4UA==/com.teapodstream.teapodstream-zTL0GGuDWxPk8XDn0VkAiw==/lib/arm64/libtun2socks.so -device fd://142 -proxy socks5://upu6CHvvV:[email protected]:45478 -mtu 1500 -loglevel error -tcp-sndbuf 524288 -tcp-rcvbuf 524288 -tcp-auto-tuning
[2026-04-12T09:44:46.644247] [INFO] tun2socks started (pid=28880)
[2026-04-12T09:44:46.644399] [INFO] VPN connectedtun2socks utilise : MTU 1500, tampons TCP à 524288 octets, auto-tuning activé. Le processus suit le PID de tun2socks pour des arrêts propres.
Fonctionnalités du client
L'implémentation TeapodStream gère les cas d'usage principaux :
- Protocoles : VLESS, VMess, Trojan, Shadowsocks.
- Split-tunneling : exclure des apps du VPN.
- Abonnements URL avec mises à jour auto de config.
- Authentification proxy dynamique.
Des tests face à des détecteurs (de l'article original sur la vulnérabilité VLESS et RKNHardering) ne montrent aucune fuite SOCKS ou IP.
Points clés à retenir
- Masquez le SOCKS local avec ports et identifiants aléatoires — c'est la clé pour contrer les scans localhost.
- tun2socks + Xray offre un TUN robuste sans les tracas du tunneling natif.
- Emballer les binaires en .so contourne SELinux Android.
- Le split-tunneling ne masque pas les autres indices (TUN, routes).
- Le code open-source permet de tout vérifier.
— Editorial Team
Aucun commentaire pour le moment.