O endereço zero do UDP ASSOCIATE no Indy não é o destino do datagrama

Separe o endereço de associação do cliente, o relay SOCKS devolvido e o destino codificado em cada pacote UDP.

0.0.0.0:0 num pedido UDP ASSOCIATE do Indy pode ser intencional. Esse pedido descreve o endpoint UDP esperado do lado do cliente, e a RFC 1928 permite zeros quando ele é desconhecido. Não seleciona o serviço final.

O BND.ADDR/BND.PORT da resposta identifica o relay para o qual o cliente envia os datagramas encapsulados.

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

No Indy, TIdUDPClient.Connect chama OpenUDP do proxy transparente. TIdSocksInfo fornece os campos de associação zerados. Mais tarde, SendBuffer passa o serviço desejado para SendToUDP, que monta o cabeçalho de destino SOCKS UDP antes dos dados da aplicação.

Se a associação funcionar mas o tráfego falhar, inspecione o relay devolvido, o destino codificado e o caminho de resposta UDP. NAT/firewalls podem permitir a troca TCP e bloquear o UDP.

Mantenha a conexão de controle TCP aberta; fechá-la encerra a associação. SOCKS4/4a não têm essa operação, e o rótulo SOCKS5 sozinho não garante que um servidor suporte UDP.

Artigos relacionados