ຈຸດໝາຍຕົ້ນທາງໃນການສົ່ງຕໍ່ TCP ຫາ SOCKS ແບບໂປ່ງໃສ
ອະທິບາຍວ່າເປັນຫຍັງການສົ່ງຕໍ່ TCP ຫາ SOCKS ແບບໂປ່ງໃສຕ້ອງການຕົວແປທີ່ຟື້ນຟູຈຸດໝາຍຕົ້ນທາງກ່ອນເຈລະຈາກັບພຣັອກຊີ.
ໄຟວໍສາມາດປ່ຽນບ່ອນທີ່ການເຊື່ອມຕໍ່ TCP ໄປລົງ. ແຕ່ດ້ວຍການປ່ຽນແປງນັ້ນຢ່າງດຽວ ມັນບໍ່ສາມາດສອນແອັບພລິເຄຊັນຕົ້ນທາງໃຫ້ເວົ້າ SOCKS ໄດ້.
ເຊີບເວີ SOCKS ທຳມະດາລໍຖ້າການເຈລະຈາທີ່ອະທິບາຍຈຸດໝາຍທີ່ຮ້ອງຂໍ. ແອັບພລິເຄຊັນທີ່ບໍ່ຮູ້ຈັກພຣັອກຊີກັບສົ່ງໄບຕ໌ໂປຣໂຕຄອນຂອງຕົນເອງທັນທີແທນ. ຖ້າທ່ານປ່ຽນເສັ້ນທາງໄບຕ໌ເຫຼົ່ານັ້ນໄປຫາຜູ້ຮັບຟັງ SOCKS ໂດຍກົງ ສອງຝ່າຍຈະບໍ່ເຫັນດີກັນກ່ຽວກັບຂໍ້ຄວາມທຳອິດ.
ອົງປະກອບທີ່ຂາດໄປແມ່ນຕົວແປ
ອົງປະກອບ TCP ຫາພຣັອກຊີແບບໂປ່ງໃສຢູ່ລະຫວ່າງອິນເຕີເຟສເຫຼົ່ານັ້ນ. ມັນຄົ້ນພົບຈຸດໝາຍທີ່ແອັບພລິເຄຊັນຮ້ອງຂໍໃນຕອນຕົ້ນ ສ້າງເຊສຊັນ SOCKS ຫຼື HTTP CONNECT ທີ່ເໝາະສົມ ແລ້ວສົ່ງຕໍ່ຂໍ້ມູນແອັບພລິເຄຊັນຜ່ານສາຍທີ່ເກີດຂຶ້ນ.
ໃນເສັ້ນທາງ Linux iptables ຂອງມັນ ແຫຼ່ງລະຫັດ redsocks ດຶງຈຸດໝາຍທີ່ຖືກເກັບຮັກສາໄວ້ໂດຍໃຊ້ SO_ORIGINAL_DST. ລະບົບປະຕິບັດການອື່ນ ແລະ ວິທີການປ່ຽນເສັ້ນທາງອື່ນໃຊ້ກົນໄກຕ່າງກັນ. ນີ້ເປັນຄຸນສົມບັດຂອງຕົວປ່ຽນເສັ້ນທາງ ແລະ ການຕັ້ງຄ່າເຄືອຂ່າຍ ບໍ່ແມ່ນຄຸນສົມບັດຂອງລູກຄ້າ SOCKS ທຳມະດາ.
ຂໍ້ມູນຈຸດໝາຍຕົ້ນທາງຍັງອະທິບາຍວ່າເປັນຫຍັງການຍ້າຍກົດການປ່ຽນເສັ້ນທາງຈາກໂຮສພຣັອກຊີໄປຫາປະຕູທາງທີ່ບໍ່ກ່ຽວຂ້ອງຈຶ່ງບໍ່ທຽບເທົ່າສະເໝີ. ຂະບວນການທີ່ຮັບຕ້ອງການເມຕາດາຕາທີ່ຮູບແບບການດັກຈັບຂອງມັນກຳນົດ. ທີ່ຢູ່ທີ່ຖືກຂຽນຄືນໃໝ່ບ່ອນອື່ນອາດບໍ່ໃຫ້ຂໍ້ມູນນັ້ນໃນຮູບແບບທີ່ຄາດໝາຍອີກຕໍ່ໄປ.
ຮັກສາຂອບເຂດຂອງຕົວແປໃຫ້ຊັດເຈນ. ການເຊື່ອມຕໍ່ TCP ທີ່ຖືກປ່ຽນເສັ້ນທາງແລ້ວໃຊ້ງານໄດ້ບໍ່ໄດ້ພິສູດການຮອງຮັບ UDP ໃດໆ ICMP ຫຼື ທຸກເສັ້ນທາງຂອງຕົວແກ້ໄຂຊື່. ໂປຣໂຕຄອນຂອງພຣັອກຊີທາງເທິງ ແລະ ການຈັດຕັ້ງຂອງຕົວແປຍັງກຳນົດການປະຕິບັດທີ່ຮອງຮັບ.
ເມື່ອການຕັ້ງຄ່າລົ້ມເຫຼວທັນທີຫຼັງການເຊື່ອມຕໍ່ ໃຫ້ກວດຂອບເຂດໂປຣໂຕຄອນກ່ອນຂະຫຍາຍກົດການເຂົ້າເຖິງ. ຜູ້ຮັບຟັງ SOCKS ທີ່ເຂົ້າເຖິງໄດ້ຢ່າງດີອາດປະຕິເສດໄບຕ໌ທີ່ບໍ່ເຄີຍເປັນຄຳຮ້ອງຂໍ SOCKS.