Proxychains DNS : pourquoi les noms d'hôtes reçoivent des adresses IP synthétiques

Un programme sous proxychains résout un nom d'hôte ordinaire vers une plage d'adresses inhabituelle. Cette adresse peut être une valeur de comptabilité interne à l'enveloppe plutôt qu'une réponse DNS provenant d'Internet.

Dans son mode proxy-DNS, proxychains-ng peut mémoriser un nom d'hôte, renvoyer une adresse synthétique à l'application, puis retraduire cette valeur en nom d'hôte lorsque la connexion interceptée est ouverte via un proxy.

Le marqueur n'est pas l'IP de sortie

La configuration d'exemple documente proxy_dns et remote_dns_subnet. La plage de mappage réservée est configurable. Ce n'est pas une adresse que vous devriez vous attendre à pinguer ou à publier comme source publique du proxy.

Cela suppose que les appels de résolution de nom et de connexion concernés soient interceptés dans le processus prévu. Un programme qui effectue son propre DNS par un autre mécanisme, conserve le marqueur pour un usage ultérieur sans rapport ou contourne le chemin de socket accroché peut se comporter différemment.

Cette limite explique pourquoi une adresse synthétique dans un journal ne prouve pas, à elle seule, que toute l'application utilise correctement le DNS distant. De même, un utilitaire DNS séparé en dehors du processus enveloppé ne teste pas la connexion mappée de l'application.

Distinguez le marqueur de l'application, l'adresse de destination réelle choisie côté proxy et la sortie publique observée par le site. Ils remplissent des rôles différents et n'ont pas besoin de correspondre.

Lors du débogage, gardez le nom d'hôte dans vos notes et identifiez le processus enveloppé exact et la configuration. Remplacer manuellement un marqueur suspect peut écarter le mappage dont l'enveloppe avait besoin pour récupérer ce nom d'hôte, transformant une indirection compréhensible en connexion vers la mauvaise destination.