Indys noll-UDP ASSOCIATE-adress är inte datagrammets mål

Separera klientens associationsadress, den returnerade SOCKS-reläen och målet som kodas i varje UDP-paket.

0.0.0.0:0 i en Indy UDP ASSOCIATE-begäran kan vara avsiktligt. Begäran beskriver den förväntade UDP-slutpunkten på klientsidan, och RFC 1928 tillåter nollor när den är okänd. Den väljer inte den slutliga tjänsten.

Svaret BND.ADDR/BND.PORT anger den relä som klienten skickar inkapslade datagram till.

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

I Indy anropar TIdUDPClient.Connect den transparenta proxyns OpenUDP. TIdSocksInfo tillhandahåller nollassociationsfälten. Senare skickar SendBuffer den önskade tjänsten vidare till SendToUDP, som bygger SOCKS UDP-destinationsheadern före applikationsdata.

Om associationen lyckas men trafiken misslyckas, undersök den returnerade reläen, det kodade målet och UDP-svarsvägen. NAT/brandväggar kan släppa igenom TCP-utbytet men blockera UDP.

Håll TCP-kontrollanslutningen öppen; stängning avslutar associationen. SOCKS4/4a saknar denna operation, och SOCKS5-namnet ensamt garanterar inte att en server stöder UDP.

Relaterade artiklar