Az Indy nulla UDP ASSOCIATE címe nem a datagram célpontja

Különítse el az ügyfél-társítási címet, a visszakapott SOCKS relayt és az egyes UDP-csomagokba kódolt célpontot.

Az 0.0.0.0:0 egy Indy UDP ASSOCIATE kérésben szándékos lehet. A kérés az ügyféloldalon várt UDP-végpontot írja le, és az RFC 1928 nullákat enged meg, ha az ismeretlen. Nem a végső szolgáltatást választja ki.

A válasz BND.ADDR/BND.PORT mezője jelöli azt a relayt, amelyre az ügyfél a beágyazott datagramokat küldi.

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

Az Indyben a TIdUDPClient.Connect meghívja az átlátszó proxy OpenUDP metódusát. A TIdSocksInfo adja a nulla társítási mezőket. Később a SendBuffer átadja a kívánt szolgáltatást a SendToUDP metódusnak, amely az alkalmazásadat előtt felépíti a SOCKS UDP célfejlécet.

Ha a társítás sikerül, de a forgalom meghiúsul, vizsgálja meg a visszakapott relayt, a kódolt célpontot és az UDP-válasz útvonalát. A NAT/tűzfalak engedhetik a TCP-cserét, miközben blokkolják az UDP-t.

Tartsa nyitva a TCP vezérlőkapcsolatot; bezárása megszünteti a társítást. A SOCKS4/4a nem ismeri ezt a műveletet, és az önmagában vett SOCKS5 jelölés nem garantálja, hogy a kiszolgáló támogatja az UDP-t.

Kapcsolódó cikkek