ກົດລະບຽບການຕອບ UDP ຂອງ Dante ປ່ຽນທິດທາງ from/to
ໃຊ້ກົດລະບຽບການຕອບຂອງ Dante ໃນທິດທາງນອກ→ໃນ ແທນທີ່ຈະຄັດລອກສົມມຸດຕິຖານທີ່ຢູ່ຂອງລູກຄ້າທີ່ອອກໄປ.
ລູກຄ້າໄດ້ຮັບການພິສູດຢືນຢັນ ແລະ ການເຊື່ອມຕໍ່ UDP ໄດ້ຮັບອະນຸຍາດ. ການຕອບກໍຍັງລົ້ມເຫລວ. ໃນ Dante ໃຫ້ກວດເບິ່ງທິດທາງຂອງກົດລະບຽບທີ່ຈັດການການຈະລາຈອນກັບຄືນ.
Dante ແຍກຄຳສັ່ງເລີ່ມຕົ້ນອອກຈາກການຈັດການການຕອບ:
| ຄຳສັ່ງກົດລະບຽບ | from | to |
|---|---|---|
connect, bind, udpassociate | ລູກຄ້າພາຍໃນ | ປາຍທາງພາຍນອກ |
bindreply, udpreply | ໂຮສພາຍນອກ | ລູກຄ້າພາຍໃນ |
ການຄັດລອກຂໍ້ຈຳກັດເຄືອຂ່າຍຍ່ອຍຂອງລູກຄ້າໂດຍບໍ່ປ່ຽນແປງໄປທັງສອງທິດທາງ ອາດຈະຈັບຄູ່ຜິດຝ່າຍໃນກົດລະບຽບການຕອບ. ກວດເບິ່ງຜູ້ສົ່ງພາຍນອກ ແລະ ຜູ້ຮັບພາຍໃນທີ່ຕັ້ງໃຈໄວ້ ບໍ່ແມ່ນພຽງແຕ່ວ່າຄຳວ່າ UDP ປາກົດໃນກົດ pass ຫຼືບໍ່.
ການພິສູດຢືນຢັນມີຂອບເຂດທີ່ກ່ຽວຂ້ອງ. ບໍລິການພາຍນອກທີ່ຕອບ datagram UDP ບໍ່ແມ່ນລູກຄ້າ SOCKS ທີ່ສາມາດສຳເລັດການແລກປ່ຽນຊື່ຜູ້ໃຊ້/ລະຫັດຜ່ານຂອງທ່ານ. ເອກະສານຂອງ Dante ອະທິບາຍວ່າການດຳເນີນການຕອບເກີດຈາກການເຊື່ອມຕໍ່ BIND ຫຼື UDP ກ່ອນໜ້າຂອງລູກຄ້າ; ໃຫ້ພິສູດຢືນຢັນການດຳເນີນການເລີ່ມຕົ້ນນັ້ນ ແລະ ໃຊ້ນະໂຍບາຍການຕອບທີ່ກ່ຽວຂ້ອງຢ່າງເໝາະສົມ.
ນີ້ບໍ່ໄດ້ເຮັດໃຫ້ການຈະລາຈອນເຂົ້າທີ່ບໍ່ໄດ້ຂໍແບບບໍ່ຈຳກັດຖືກຕ້ອງ. ການເຊື່ອມຕໍ່ UDP, ນະໂຍບາຍປາຍທາງ, ທີ່ຢູ່ relay ແລະ ເສັ້ນທາງ firewall ຍັງສຳຄັນ. ການເປີດ bindreply ກໍບໍ່ໄດ້ເຮັດໃຫ້ການເຊື່ອມຕໍ່ UDP ກາຍເປັນບໍລິການສົ່ງຕໍ່ພອດສາທາລະນະທົ່ວໄປ.
ໃຫ້ເຫັນການແລກປ່ຽນ SOCKS ຝ່າຍລູກຄ້າ ແລະ ເສັ້ນທາງກັບຄືນ UDP ຕົວຈິງແຍກກັນຢ່າງຊັດເຈນ. ການເຂົ້າສູ່ລະບົບ TCP ທີ່ສຳເລັດ ບໍ່ໄດ້ກວດສອບທັງທິດທາງທີ່ຢູ່ຂອງ ACL ການຕອບ ແລະ ການເຂົ້າເຖິງ endpoint relay UDP.