La nula UDP ASSOCIATE-adreso de Indy ne estas la celo de la datagramo

Apartigu la asoci-adreson de la kliento, la redonitan SOCKS-relajon kaj la celon kodigitan en ĉiu UDP-paketo.

0.0.0.0:0 en Indy UDP ASSOCIATE-peto povas esti intenca. Tiu peto priskribas la atendatan UDP-finpunkton de la klienta flanko, kaj RFC 1928 permesas nulojn kiam ĝi ne estas konata. Ĝi ne elektas la finan servon.

La BND.ADDR/BND.PORT de la respondo indikas la relajon, al kiu la kliento sendas enkapsuligitajn datagramojn.

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

En Indy, TIdUDPClient.Connect vokas la OpenUDP de la travidebla prokurilo. TIdSocksInfo provizas la nulajn asoci-kampojn. Poste, SendBuffer transdonas la deziratan servon al SendToUDP, kiu konstruas la SOCKS UDP-celan kaplinion antaŭ la aplikaj datumoj.

Se la asociado sukcesas sed la trafiko malsukcesas, kontrolu la redonitan relajon, la kodigitan celon kaj la UDP-respondan vojon. NAT/fajroŝirmiloj povas permesi la TCP-interŝanĝon dum ili blokas UDP.

Tenu la TCP-kontrolan konekton malferma; ĝia fermo finas la asociadon. SOCKS4/4a mankas al tiu operacio, kaj la sola nomo SOCKS5 ne garantias, ke servilo subtenas UDP.

Rilataj artikoloj