Null-UDP ASSOCIATE adressin hjá Indy er ikki málið fyri datagrammið

Aðskil klientasamgonguadressina, aftursenda SOCKS-relay og málið, sum verður kodað í hvørjum UDP-pakka.

0.0.0.0:0 í eini Indy UDP ASSOCIATE-fyrispurning kann vera viljandi. Fyrispurningurin lýsir væntaða UDP-endapunkt á klientasíðuni, og RFC 1928 loyvir nullum, tá hann er ókendur. Hann velur ikki tann endaliga tænastuna.

BND.ADDR/BND.PORT í svarinum vísir á relayið, sum klienturin sendir innpakkaðar datagrammar til.

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

Í Indy kallar TIdUDPClient.Connect á OpenUDP hjá gjøgnumskygda proxyinum. TIdSocksInfo veitir null-samgongufeltini. Seinni letur SendBuffer tær ynskta tænastuna til SendToUDP, sum byggir SOCKS UDP-máls-høvdið framman fyri applikašjónsdátuna.

Um samgongan eydnast, men ferðslan miseydnast, kanna tá aftursenda relayið, kodaða málið og UDP-svarvegin. NAT/eldveggir kunnu loyva TCP-umskiftinum og samtíðis steingja fyri UDP.

Halt TCP-stýrisambandið opið; at lata tað aftur endar samgonguna. SOCKS4/4a hava ikki hesa handling, og SOCKS5-navnið einsamalt tryggjar ikki, at ein ambætari stuðlar UDP.

Skyldar greinar