Destinations d'origine dans le transfert transparent TCP-vers-SOCKS
Explique pourquoi le transfert transparent TCP-vers-SOCKS exige un traducteur qui rétablit la destination d'origine avant de négocier avec le proxy.
Un pare-feu peut changer l'endroit où aboutit une connexion TCP. Il ne peut pas, par ce seul changement, apprendre à l'application d'origine à parler SOCKS.
Un serveur SOCKS ordinaire attend une négociation décrivant la destination demandée. Une application qui ignore le proxy envoie au contraire immédiatement ses propres octets de protocole. Redirigez ces octets directement vers un écouteur SOCKS et les deux parties seront en désaccord sur le premier message.
Le composant manquant est un traducteur
Un composant transparent de TCP vers proxy se place entre ces interfaces. Il découvre la destination que l'application avait demandée à l'origine, établit la session SOCKS ou HTTP CONNECT appropriée, puis relaie les données de l'application sur le flux obtenu.
Sur son chemin Linux iptables, le code source de redsocks récupère la destination préservée au moyen de SO_ORIGINAL_DST. D'autres systèmes d'exploitation et méthodes de redirection emploient des mécanismes différents. C'est une propriété du redirecteur et de la configuration réseau, non une fonction d'un client SOCKS ordinaire.
L'information sur la destination d'origine explique aussi pourquoi déplacer une règle de redirection de l'hôte proxy vers une passerelle sans rapport n'est pas toujours équivalent. Le processus récepteur a besoin des métadonnées qu'exige son mode d'interception. Une adresse réécrite ailleurs ne fournit peut-être plus cette information sous la forme attendue.
Gardez explicite la portée du traducteur. Une connexion TCP redirigée qui fonctionne ne démontre pas la prise en charge d'UDP arbitraire, d'ICMP ni de chaque chemin de résolution. Le protocole du proxy en amont et l'implémentation du traducteur définissent encore les opérations prises en charge.
Lorsqu'une configuration échoue juste après la connexion, vérifiez la frontière du protocole avant d'élargir les règles d'accès. Un écouteur SOCKS parfaitement joignable peut rejeter des octets qui n'ont jamais été une requête SOCKS.