ທີ່ຢູ່ສູນ UDP ASSOCIATE ຂອງ Indy ບໍ່ແມ່ນເປົ້າໝາຍຂອງ datagram

ແຍກທີ່ຢູ່ສະມາຄົມຂອງລູກຄ້າ, ຣີເລ SOCKS ທີ່ສົ່ງຄືນ ແລະ ເປົ້າໝາຍທີ່ເຂົ້າລະຫັດໃນແຕ່ລະແພັກເກັດ UDP.

0.0.0.0:0 ໃນຄຳຮ້ອງ UDP ASSOCIATE ຂອງ Indy ອາດເປັນເຈດຕະນາ. ຄຳຮ້ອງນັ້ນອະທິບາຍຈຸດປາຍທາງ UDP ທີ່ຄາດຫວັງຢູ່ຝັ່ງລູກຄ້າ, ແລະ RFC 1928 ອະນຸຍາດໃຫ້ໃຊ້ສູນເມື່ອບໍ່ຮູ້. ມັນບໍ່ໄດ້ເລືອກບໍລິການສຸດທ້າຍ.

BND.ADDR/BND.PORT ໃນຄຳຕອບຊີ້ບອກຣີເລທີ່ລູກຄ້າສົ່ງ datagram ທີ່ຫໍ່ຫຸ້ມໄປ.

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

ໃນ Indy, TIdUDPClient.Connect ເອີ້ນ OpenUDP ຂອງພຣັອກຊີໂປ່ງໃສ. TIdSocksInfo ສະໜອງຊ່ອງສະມາຄົມສູນ. ຕໍ່ມາ SendBuffer ສົ່ງບໍລິການທີ່ຕ້ອງການໄປຫາ SendToUDP, ເຊິ່ງສ້າງຫົວຂໍ້ປາຍທາງ SOCKS UDP ກ່ອນຂໍ້ມູນແອັບພລິເຄຊັນ.

ຖ້າສະມາຄົມສຳເລັດແຕ່ການຮັບສົ່ງລົ້ມເຫລວ, ໃຫ້ກວດເບິ່ງຣີເລທີ່ສົ່ງຄືນ, ປາຍທາງທີ່ເຂົ້າລະຫັດ ແລະ ເສັ້ນທາງຕອບ UDP. NAT/ໄຟວໍສາມາດອະນຸຍາດການແລກປ່ຽນ TCP ໃນຂະນະທີ່ບລັອກ UDP.

ຮັກສາການເຊື່ອມຕໍ່ຄວບຄຸມ TCP ໃຫ້ເປີດຢູ່; ການປິດມັນຈະຢຸດສະມາຄົມ. SOCKS4/4a ບໍ່ມີການດຳເນີນການນີ້, ແລະ ຊື່ SOCKS5 ຢ່າງດຽວບໍ່ຮັບປະກັນວ່າເຊີບເວີຮອງຮັບ UDP.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ