Ce que ProxyChains intercepte et ce qu'il laisse tranquille

ProxyChains-NG ne crée pas de tunnel. Il précharge une bibliothèque qui remplace les appels libc liés au réseau à l'intérieur du seul programme qu'il lance, la frontière est donc un appel dans un processus, et non une route à l'échelle de l'appareil. Cette distinction décide de ce qu'un test réussi prouve vraiment. Un curl qui fonctionne à travers la chaîne confirme un seul appel accroché, pas que la résolution de noms, UDP ou chaque processus enfant aient suivi le même chemin. Le guide ci-dessous vérifie la couverture en trois étapes, puis énumère ce que le crochet ne peut pas atteindre.

Comment la précharge atteint une connexion

Au démarrage, le lanceur place libproxychains dans LD_PRELOAD puis exécute le programme cible. La bibliothèque résout les vrais symboles libc et les remplace par ses propres versions de fonctions telles que connect et getaddrinfo. Les appels qui passent par ces symboles sont réécrits vers le proxy SOCKS ou HTTP du fichier de configuration. Les appels qui prennent un autre chemin ne rencontrent jamais le crochet, et c'est pourquoi la garantie vaut par appel et non par machine.

Seuls les programmes liés dynamiquement participent, et les binaires setuid sous exécution sécurisée ignorent totalement la précharge. Les enfants héritent de l'environnement, mais seulement tant que le lanceur le maintient en place.

Confirmez que la bibliothèque est chargée dans ce processus

Lancez la requête et inspectez le processus vivant plutôt que le shell qui l'a lancé. Le fichier maps montre chaque objet partagé actuellement mappé dans le processus.

proxychains4 -q curl -sS --max-time 8 https://example.com/ -o /dev/null &
pgrep -a curl
grep libproxychains /proc/$(pgrep -n curl)/maps

Une correspondance confirme la présence de la bibliothèque accrochée, ce qui est nécessaire mais pas suffisant. Un résultat vide signifie généralement que vous avez inspecté un autre processus, par exemple un navigateur qui a remis l'URL à une instance démarrée avant le lanceur. Vérifiez avec ldd que le binaire est lié dynamiquement avant de chercher autre chose, car une compilation statique ne peut pas charger la précharge du tout. Lisez ensuite la liste de proxys dans la configuration que le lanceur a réellement utilisée, car un chemin obsolète ou un port fermé produit un crochet qui fonctionne sans chaîne qui fonctionne.

Tracez les connexions qui quittent le processus

La présence de la bibliothèque ne prouve pas que chaque appel a été réécrit, suivez donc les appels système. Exécutez une requête sous le traceur et lisez où les sockets sont réellement allés.

strace -f -e trace=connect -o /tmp/pc.trace proxychains4 -q curl -sS https://example.com/ -o /dev/null
grep -o "sin_port=htons([0-9]*)" /tmp/pc.trace | sort -u

La trace doit montrer uniquement les connexions vers votre point de terminaison proxy, avec le port correspondant à l'entrée du fichier de configuration. Si les adresses de destination du site cible apparaissent directement dans la trace, cet appel a contourné le crochet, et c'est précisément la constatation que vous cherchiez. Comparez les numéros de port avec la liste de proxys au lieu de faire confiance au nom du fichier, car une configuration restante d'un autre projet est une source courante d'accès direct silencieux. Conservez la trace pour le procès-verbal de recette ; cela prend quelques secondes et tranche les discussions sur la couverture.

Décidez ce que le crochet ne peut pas couvrir

Le projet proxychains-ng limite la redirection à TCP et avertit que les scripts, les processus d'arrière-plan et les modules chargés peuvent se comporter différemment du programme principal. UDP et ICMP se situent hors du mécanisme, donc tout ce qui en dépend a besoin de sa propre voie prise en charge. DNS suit le réglage proxy_dns et le comportement propre au résolveur de l'application, ce qui signifie qu'une requête HTTPS réussie ne vous dit rien sur la résolution de noms. Gardez aussi la validation des certificats là où elle doit être : atteindre un serveur via un proxy n'est pas une raison de désactiver les contrôles d'identité.

Si le repli direct doit être impossible, utilisez une frontière d'application qui contrôle le trafic lui-même, comme un espace de noms réseau, des règles de pare-feu ou un VPN, et gardez-la séparée du crochet de bibliothèque. Le crochet est un outil de compatibilité pour un programme nommé, pas un kill switch. Notez le programme, la commande exacte, le port proxy vu dans la trace et si DNS a été résolu à distance ; ces quatre faits font la différence entre un périmètre vérifié et un périmètre d'espoir.