El lien que vous avez fourni n'est pas une configuration de SOC pour S S S mais une mandataire transparent c'est-à-dire qu'il prend le trafic TCP/UDP et SOCKSify avant de l'envoyer par shadowsocks tunnel. Mais vous devez faire en sorte que votre trafic SOCKS-aware avant de le diriger vers le proxy SOCKS. Il faut soit configurer les applications individuelles (qui ont un support intégré pour SOCKS), soit appliquer le proxy à l'ensemble du système de manière transparente (ce que vous essayez de faire).
LES LIMITES DU PROXY SOCKS :
Il semble qu'AFWall+ soit capable de créer une politique de transfert NAT.
AFWall+ utilise iptables à l'arrière et il peut exécuter votre script sur les changements de réseau. L'application d'un proxy global est (au moins partiellement) possible avec Proxifier des applications comme ProxyDroid (qui est iptables -) et ChaussettesDroid (qui est basé sur le VPN/routage). Je n'ai aucune affiliation avec l'un ou l'autre.
Si vous travaillez manuellement à partir de l'interface CLI, vous pouvez utiliser une méthode transparente. Redirecteur TCP/UDP vers proxy comme redsocks en combinaison avec iptables . shadowsocks fournit son propre outil similaire ( ss-redir ), tout comme Tor.
Je n'ai coché aucune application, donc je suppose que cela signifie que toutes les applications passent par un script personnalisé, n'est-ce pas ?
Non. Le problème avec le iptables est que SOCKS5 est un protocole de couche 5 dans le modèle OSI. Ainsi, il ne peut pas transporter tout le trafic de toutes les applications . La plupart du trafic généré par les applications est de type TCP, ce qui fonctionne bien avec SOCKS et est facile à configurer. Mais certains jeux, les applications VoIP et surtout les DNS traditionnels génèrent du trafic TCP. UDP qui n'est pas pris en charge par de nombreux proxys SOCKS5. Par exemple openssh y tor les deux ne le font pas, shadowsocks a toutefois Associé UDP caractéristiques. Mais il ne fonctionne pas avec simple DNAT o REDIRECT (probablement parce que SO_ORIGINAL_DST n'est pas disponible pour les sockets UDP, je ne connais pas les détails). Vous pouvez éventuellement rediriger le trafic uniquement vers un socket fixe (IP:PORT), par exemple un serveur DNS ou un serveur de jeux.
TPROXY est l'alternative ici, mais le problème est qu'elle ne fonctionne qu'avec PREROUTING c'est-à-dire le trafic provenant de l'extérieur, et non celui généré sur l'appareil. Vous devez donc effectuer une configuration supplémentaire pour acheminer votre trafic sur l'appareil sans NATing vers un serveur proxy local (généralement une passerelle par défaut) où vous configurerez les éléments suivants TPROXY .
Compliqué ? C'est pourquoi VPN est préférable. Même si vous devez utiliser un proxy pour contourner les pare-feux, le tunnelage VPN par proxy vous épargne les complexités de la redirection du trafic . Le VPN fonctionne à un niveau inférieur de la pile réseau (L2/L3 dans OSI), il transporte donc sans problème tout le trafic IP, y compris les échos ICMP ( ping ) etc. qui ne peuvent en aucun cas être envoyés par SOCKS. Un autre point positif est que le VPN peut être tunnelé à travers proxies transparents - comme shapeshifter-dispatcher y stunnel - ou les proxys SOCKS qui sont destinés à transfert d'un seul port - comme obfs4proxy .
S'il n'y a pas de transfert de port unique (tunneling), SOCKS5 doit être une proxy au niveau de l'application c'est-à-dire qu'il devrait être capable de transférer des ports arbitraires de différentes applications comme le fait le transfert dynamique de port SSH.
tun2socks est une autre méthode de SOCKSification qui collecte le trafic TCP/UDP sur une tun (comme pour un VPN, sans NAT) et le fait passer par un proxy SOCKS. Il a récemment ajouté le support des associés UDP. Auparavant, on utilisait Passerelle UDP fonctionne également très bien, mais elle nécessite l'exécution d'un démon distinct ( udpgw ) ainsi que le serveur proxy. tun2socks est un Solution sans racine parce que les applications - comme SocksDroid et de nombreux autres pare-feu, renifleurs, etc. - qui utilisent cette méthode s'appuient sur les fonctionnalités VPN d'Android.
... et faire croire aux applications Google qu'elles ne sont pas connectées via un VPN (les applications Google mettent en œuvre des mesures de sécurité supplémentaires lorsqu'elles se connectent via un VPN). VPNService ...
Avec les deux méthodes ci-dessus (VPN via un tunnel et Tun-to-SOCKS), il n'est pas nécessaire d'utiliser l'option d'Android VPNService (si cela vous pose problème). Sur un appareil enraciné, vous pouvez obtenir une adresse statique openvpn o tun2socks et exécutez-le via le CLI. C'est beaucoup moins compliqué que de configurer un proxy par le biais de iptables . Dans le premier cas, cependant, vous avez besoin d'un serveur VPN évidemment.
SOCKS IFIER TOUT LE DISPOSITIF :
Comme vous ne souhaitez pas opter pour une solution basée sur le VPN/routage, voici une solution simple. iptables -La méthode est basée sur l'analyse des données.
Obtenez d'abord redsocks pour l'architecture de votre appareil (ou essayez celui-ci para aarch64 o celui-ci para armeabi-v7a ). Créer le fichier de configuration :
// redsocks.conf
// general configuration
base {
redirector = iptables;
}
// for TCP
redsocks {
local_ip = "127.0.0.1"; local_port = "12345";
ip = "192.168.1.1"; port = "1088"; type = socks5;
}
// for UDP, assuming your SOCKS5 proxy supports UDP associate
redudp {
local_ip = "127.0.0.1"; local_port = "12345";
ip = "192.168.1.1"; port = "1088";
dest_ip = "1.1.1.1"; dest_port = "53"; /* set whatever DNS server */
}
* Voir redsocks.conf.exemple pour plus de détails et d'options.
Cours :
#!/system/bin/sh
IPTABLES="/system/bin/iptables -w5 -t nat"
# create new chain
$IPTABLES -N PROXY
$IPTABLES -I OUTPUT -j PROXY
# exclude local traffic, see: http://manpages.org/ss-redir
$IPTABLES -A PROXY -d 127.0.0.0/8 -j RETURN
$IPTABLES -A PROXY -d 192.168.0.0/16 -j RETURN
# socksify whole TCP traffic
$IPTABLES -A PROXY -p tcp -j DNAT --to 127.0.0.1:12345
# socksify only DNS UDP traffic
$IPTABLES -A PROXY -p udp --dport 53 -j DNAT --to 127.0.0.1:12345
echo "Ctrl^C to exit."
trap "$IPTABLES -D OUTPUT -j PROXY; $IPTABLES -F PROXY; $IPTABLES -X PROXY" EXIT
# run socksifier
redsocks -c /path/to/redsocks.conf
Vous pouvez ajouter des iptables à AFWall+. redsocks peut être exécuté en tant que init service avec UID non-Root, capacités abandonnées et contexte SELinux restreint. Voir Comment lancer un exécutable au démarrage ?
RELATION :
