L'adresse nulle d'UDP ASSOCIATE dans Indy n'est pas la cible du datagramme

Distinguez l'adresse d'association du client, le relais SOCKS renvoyé et la cible encodée dans chaque paquet UDP.

0.0.0.0:0 dans une requête UDP ASSOCIATE d'Indy peut être volontaire. Cette requête décrit le point de terminaison UDP attendu côté client, et la RFC 1928 autorise les zéros lorsqu'il est inconnu. Elle ne choisit pas le service final.

Le BND.ADDR/BND.PORT de la réponse désigne le relais auquel le client envoie les datagrammes encapsulés.

TCP control: client → SOCKS5 proxy → UDP association reply
UDP payload: client → returned relay address → target service

Dans Indy, TIdUDPClient.Connect appelle OpenUDP du proxy transparent. TIdSocksInfo fournit les champs d'association à zéro. Plus tard, SendBuffer transmet le service voulu à SendToUDP, qui construit l'en-tête de destination SOCKS UDP avant les données applicatives.

Si l'association réussit mais que le trafic échoue, inspectez le relais renvoyé, la destination encodée et le chemin de réponse UDP. Les NAT/pare-feux peuvent autoriser l'échange TCP tout en bloquant l'UDP.

Gardez la connexion de contrôle TCP ouverte ; sa fermeture met fin à l'association. SOCKS4/4a n'ont pas cette opération, et l'étiquette SOCKS5 seule ne garantit pas qu'un serveur prenne en charge l'UDP.

Articles similaires