Indys nul-UDP ASSOCIATE-adresse er ikke datagrammets mål

Adskil klientens associationsadresse, den returnerede SOCKS-relay og det mål, der kodes i hver UDP-pakke.

0.0.0.0:0 i en Indy UDP ASSOCIATE-anmodning kan være tilsigtet. Anmodningen beskriver det forventede UDP-endepunkt på klientsiden, og RFC 1928 tillader nuller, når det er ukendt. Den vælger ikke den endelige tjeneste.

Svarets BND.ADDR/BND.PORT angiver den relay, som klienten sender indkapslede datagrammer til.

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

I Indy kalder TIdUDPClient.Connect den transparente proxys OpenUDP. TIdSocksInfo leverer nul-associationsfelterne. Senere sender SendBuffer den ønskede tjeneste videre til SendToUDP, som opbygger SOCKS UDP-destinationsheaderen før applikationsdataene.

Hvis associationen lykkes, men trafikken fejler, skal du undersøge den returnerede relay, den kodede destination og UDP-svarstien. NAT/firewalls kan tillade TCP-udvekslingen og samtidig blokere UDP.

Hold TCP-kontrolforbindelsen åben; lukning afslutter associationen. SOCKS4/4a mangler denne handling, og SOCKS5-mærkning alene garanterer ikke, at en server understøtter UDP.

Relaterede artikler