Un socket .NET a besoin d'une poignée de main SOCKS
Expliquez ce qu'un socket TCP .NET brut doit faire avant que les octets de l'application ne circulent via un proxy SOCKS.
Pointer Socket.Connect() vers un serveur SOCKS ouvre une connexion TCP vers ce serveur. Les octets suivants doivent encore parler SOCKS. Envoyer immédiatement le protocole de l'application laisse le serveur en attente d'une autre conversation.
Avec SOCKS5, l'établissement de la connexion comprend la négociation de méthode, un éventuel échange d'authentification retenu et une requête nommant la destination. Seule une réponse réussie ouvre le chemin aux octets de l'application. Ces étapes sont définies dans la RFC 1928.
Gardez la négociation dans la couche de connexion
Une application dotée de son propre protocole TCP peut utiliser un connecteur conscient du proxy qui renvoie un flux établi. Le reste de l'application lit et écrit ensuite dans ce flux. Un connecteur doit tenir compte des lectures partielles, des adresses de longueur variable, des échecs d'authentification et d'un délai pour la négociation.
Une implémentation écrite à la main qui lit un tampon de taille fixe et suppose le succès est fragile. TCP ne préserve pas les frontières des messages SOCKS. Lisez la réponse complète décrite par son type d'adresse avant de démarrer le protocole applicatif. Un lecteur de réponses CONNECT pour .NET 7+ illustre cette étape.
Si une bibliothèque maintenue fournit déjà cette couche de connexion, vérifiez ses versions SOCKS prises en charge, ses méthodes d'authentification et son framework cible. Un lien de forum vieux de dix ans est un point de départ pour enquêter, pas une preuve de compatibilité actuelle.
La configuration du client HTTP a une portée distincte
Le réglage de proxy d'un client HTTP configure ce client HTTP. Il ne modifie pas chaque socket brut du processus. L'API Socket accepte un point de terminaison réseau et laisse la négociation de niveau supérieur à l'appelant.
Pour un protocole applicatif chiffré, effectuez sa poignée de main TLS après l'établissement du tunnel proxy. Validez l'identité de la destination visée à cette étape. L'authentification du proxy et celle de la destination restent distinctes même si elles utilisent le même flux sous-jacent.