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

Skill klientens assosiasjonsadresse, den returnerte SOCKS-reléen og målet som kodes i hver UDP-pakke.

0.0.0.0:0 i en Indy UDP ASSOCIATE-forespørsel kan være tilsiktet. Forespørselen beskriver det forventede UDP-endepunktet på klientsiden, og RFC 1928 tillater nuller når det er ukjent. Den velger ikke den endelige tjenesten.

Svaret BND.ADDR/BND.PORT angir reléen som klienten sender innkapslede datagrammer til.

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

I Indy kaller TIdUDPClient.Connect den gjennomsiktige proxyens OpenUDP. TIdSocksInfo leverer null-assosiasjonsfeltene. Senere sender SendBuffer den ønskede tjenesten videre til SendToUDP, som bygger SOCKS UDP-destinasjonsheaderen før applikasjonsdataene.

Hvis assosiasjonen lykkes, men trafikken feiler, undersøk den returnerte reléen, den kodede destinasjonen og UDP-svarveien. NAT/brannmurer kan slippe TCP-utvekslingen gjennom og samtidig blokkere UDP.

Hold TCP-kontrollforbindelsen åpen; lukking avslutter assosiasjonen. SOCKS4/4a mangler denne operasjonen, og SOCKS5-navnet alene garanterer ikke at en server støtter UDP.

Relaterte artikler