O enderezo cero de UDP ASSOCIATE en Indy non é o destino do datagrama

Separe o enderezo de asociación do cliente, o relé SOCKS devolto e o destino codificado en cada paquete UDP.

0.0.0.0:0 nunha solicitude UDP ASSOCIATE de Indy pode ser intencionado. Esa solicitude describe o extremo UDP esperado do lado do cliente, e RFC 1928 permite ceros cando se descoñece. Non selecciona o servizo final.

O BND.ADDR/BND.PORT da resposta identifica o relé ao que o cliente envía os datagramas encapsulados.

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

En Indy, TIdUDPClient.Connect chama OpenUDP do proxy transparente. TIdSocksInfo fornece os campos de asociación en cero. Despois, SendBuffer pasa o servizo desexado a SendToUDP, que constrúe a cabeceira de destino SOCKS UDP antes dos datos da aplicación.

Se a asociación ten éxito pero o tráfico falla, inspeccione o relé devolto, o destino codificado e a ruta de resposta UDP. NAT/cortafogos poden admitir o intercambio TCP mentres bloquean UDP.

Manteña aberta a conexión de control TCP; pechala remata a asociación. SOCKS4/4a carecen desta operación, e a etiqueta SOCKS5 por si soa non garante que un servidor admita UDP.

Artigos relacionados