La dirección cero de UDP ASSOCIATE en Indy no es el destino del datagrama

Separe la dirección de asociación del cliente, el relay SOCKS devuelto y el destino codificado en cada paquete UDP.

0.0.0.0:0 en una solicitud UDP ASSOCIATE de Indy puede ser intencional. Esa solicitud describe el extremo UDP esperado del lado del cliente, y RFC 1928 permite ceros cuando se desconoce. No selecciona el servicio final.

El BND.ADDR/BND.PORT de la respuesta identifica el relay al que el cliente envía los datagramas encapsulados.

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

En Indy, TIdUDPClient.Connect llama a OpenUDP del proxy transparente. TIdSocksInfo proporciona los campos de asociación en cero. Después, SendBuffer pasa el servicio deseado a SendToUDP, que construye la cabecera de destino SOCKS UDP antes de los datos de la aplicación.

Si la asociación tiene éxito pero el tráfico falla, inspeccione el relay devuelto, el destino codificado y la ruta de respuesta UDP. NAT/firewalls pueden admitir el intercambio TCP mientras bloquean UDP.

Mantenga abierta la conexión de control TCP; cerrarla termina la asociación. SOCKS4/4a carecen de esta operación, y la marca SOCKS5 por sí sola no garantiza que un servidor soporte UDP.

Artículos relacionados