Null-UDP ASSOCIATE-adressa til Indy er ikkje datagrammålet

Skil klienten si assosiasjonsadresse, SOCKS-reléet som vert returnert og målet som er koda i kvar UDP-pakke.

0.0.0.0:0 i ein Indy UDP ASSOCIATE-førespurnad kan vere medvite. Førespurnaden skildrar det venta UDP-endepunktet på klientsida, og RFC 1928 tillèt nullar når det er ukjent. Han vel ikkje den endelege tenesta.

BND.ADDR/BND.PORT i svaret peikar på reléet som klienten sender innkapsla datagram til.

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

I Indy kallar TIdUDPClient.Connect på OpenUDP til den gjennomsiktige proxyen. TIdSocksInfo leverer null-assosiasjonsfelta. Seinare sender SendBuffer den ønska tenesta vidare til SendToUDP, som byggjer SOCKS UDP-målhovudet før applikasjonsdataa.

Viss assosiasjonen lykkast, men trafikken feilar, gransk det returnerte reléet, det koda målet og UDP-svarvegen. NAT/brannmurar kan sleppe TCP-utvekslinga gjennom og samstundes blokkere UDP.

Hald TCP-kontrollsambandet ope; lukking avsluttar assosiasjonen. SOCKS4/4a manglar denne operasjonen, og namnet SOCKS5 åleine garanterer ikkje at ein tenar støttar UDP.

Relaterte artiklar