ຮຽກຮ້ອງການເຂົ້າສູ່ລະບົບທັງບໍລິການ HTTP ແລະ SOCKS ຂອງ 3proxy

ການກຳນົດຜູ້ໃຊ້ບໍ່ແມ່ນການຕັ້ງຄ່າການເຂົ້າສູ່ລະບົບທັງໝົດຂອງ 3proxy. ບໍລິການຍັງຕ້ອງການວິທີການພິສູດຢືນຢັນ ແລະ ກົດລະບຽບການເຂົ້າເຖິງທີ່ໃຊ້ມັນ. ລຳດັບມີຄວາມສຳຄັນ ເພາະການຕັ້ງຄ່າບໍລິການຖືກນຳໃຊ້ໃນຂະນະທີ່ປະມວນຜົນການຕັ້ງຄ່າ.

ຕົວຢ່າງສະເພາະທ້ອງຖິ່ນສຳລັບສອງບໍລິການ:

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

ເອກະສານອ້າງອີງການຕັ້ງຄ່າ ອະທິບາຍ users, auth strong ແລະ ຄຳສັ່ງຂອງບໍລິການ. CL ເກັບລະຫັດຜ່ານຕົວຢ່າງນີ້ເປັນຂໍ້ຄວາມທຳມະດາ. ປົກປ້ອງໄຟລ໌ ແລະ ເລືອກຮູບແບບການເກັບຂໍ້ມູນຢືນຢັນຕົວຕົນທີ່ຮອງຮັບ ແລະ ເໝາະສົມກັບການຕິດຕັ້ງ.

ລູກຄ້າຕ້ອງການການແລກປ່ຽນການເຂົ້າສູ່ລະບົບທີ່ຖືກຕ້ອງ

ບໍລິການ HTTP ຄາດຫວັງການພິສູດຢືນຢັນພຣັອກຊີ HTTP. ບໍລິການ SOCKS ຕ້ອງການລູກຄ້າທີ່ຮອງຮັບການພິສູດຢືນຢັນ SOCKS5 ດ້ວຍຊື່ຜູ້ໃຊ້ ແລະ ລະຫັດຜ່ານ. ລູກຄ້າ SOCKS4 ບໍ່ສາມາດໃຫ້ການແລກປ່ຽນນັ້ນໄດ້ພຽງເພາະມັນໄປຮອດພອດຮັບຟັງດຽວກັນ.

ຄຳວ່າ strong ແມ່ນຊື່ຂອງຮູບແບບການພິສູດຢືນຢັນ ບໍ່ແມ່ນການຮັບປະກັນການຂົນສົ່ງທີ່ເຂົ້າລະຫັດ. ປົກປ້ອງ ຊ່ວງຈາກລູກຄ້າໄປຫາພຣັອກຊີ ເມື່ອຈຳເປັນ. HTTPS ໄປຫາປາຍທາງ ແລະ ການເຂົ້າລະຫັດໄປຫາພຣັອກຊີ ຍັງຄົງເປັນການຕັດສິນໃຈແຍກຕ່າງຫາກ.

ການຜູກມັດ loopback ຈຳກັດຕົວຢ່າງນີ້ໃຫ້ເປັນການເຂົ້າເຖິງພາຍໃນເຄືອຂ່າຍທ້ອງຖິ່ນເທົ່ານັ້ນ. ສຳລັບລູກຄ້າທາງໄກ ໃຫ້ເລືອກຕົວຮັບຟັງ ແລະ ນະໂຍບາຍເຄືອຂ່າຍທີ່ຕັ້ງໃຈໄວ້ຢ່າງຊັດເຈນ. ຕົວຮັບຟັງແບບ wildcard ສາທາລະນະບໍ່ແມ່ນສິ່ງທົດແທນການກວດສອບພຶດຕິກຳການເຂົ້າສູ່ລະບົບ.

ຖ້າບໍລິການໜຶ່ງຂໍຂໍ້ມູນຢືນຢັນຕົວຕົນ ແລະ ອີກອັນໜຶ່ງບໍ່ຂໍ ໃຫ້ກວດເບິ່ງການຕັ້ງຄ່າກ່ອນຄຳສັ່ງບໍລິການແຕ່ລະອັນ ກົດລະບຽບຫຼັງ flush ໃດໜຶ່ງ ແລະ ແຄຊການພິສູດຢືນຢັນ. ການປ່ຽນລະຫັດຜ່ານບໍ່ສາມາດແກ້ໄຂບໍລິການທີ່ເລີ່ມພາຍໃຕ້ນະໂຍບາຍຜິດໄດ້. ເຊັ່ນດຽວກັນ ການປ່ຽນບັນຊີລະບົບປະຕິບັດການຂອງ daemon ບໍ່ໄດ້ສ້າງຜູ້ໃຊ້ພຣັອກຊີ.