Ang zero UDP ASSOCIATE address ng Indy ay hindi target ng datagram

Paghiwalayin ang address ng asosasyon ng kliyente, ang ibinalik na SOCKS relay at ang target na naka-encode sa bawat UDP packet.

0.0.0.0:0 sa isang Indy UDP ASSOCIATE request ay maaaring sinasadya. Inilalarawan ng request na iyon ang inaasahang UDP endpoint sa panig ng kliyente, at pinapayagan ng RFC 1928 ang mga zero kapag hindi ito alam. Hindi nito pinipili ang huling serbisyo.

Ang BND.ADDR/BND.PORT ng tugon ay tumutukoy sa relay kung saan ipinapadala ng kliyente ang mga naka-encapsulate na datagram.

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

Sa Indy, tinatawag ng TIdUDPClient.Connect ang OpenUDP ng transparent na proxy. Ibinibigay ng TIdSocksInfo ang mga zero na field ng asosasyon. Maya-maya, ipinapasa ng SendBuffer ang nais na serbisyo sa SendToUDP, na bumubuo ng SOCKS UDP destination header bago ang data ng aplikasyon.

Kung nagtagumpay ang asosasyon pero nabigo ang trapiko, siyasatin ang ibinalik na relay, ang naka-encode na destinasyon at ang landas ng tugon ng UDP. Maaaring payagan ng NAT/firewall ang palitan ng TCP habang hinaharangan ang UDP.

Panatilihing bukas ang TCP control connection; ang pagsasara nito ay nagtatapos sa asosasyon. Walang ganitong operasyon ang SOCKS4/4a, at ang pangalang SOCKS5 lamang ay hindi garantiya na sinusuportahan ng server ang UDP.

Kaugnay na mga artikulo