iptables --uid-owner ກົງກັບຊອກເກັດພາຍໃນຂອງ Squid ບໍ່ແມ່ນຜູ້ໃຊ້ LAN
ໃຊ້ຄວາມໝາຍ --uid-owner ໃນຖານະຜູ້ສ້າງຊອກເກັດພາຍໃນ ເມື່ອວິເຄາະການອອກຂອງ Squid ແລະ ແຍກແພັກເກັດ LAN ທີ່ສົ່ງຕໍ່ໄວ້ຕ່າງຫາກ.
ການຈັບຄູ່ owner ຂອງ iptables ສາມາດລະບຸແພັກເກັດທີ່ສ້າງຂຶ້ນໂດຍຊອກເກັດຂອງຂະບວນການພາຍໃນໄດ້. ຕົວຢ່າງ, -m owner --uid-owner 1234 ໝາຍເຖິງຊອກເກັດພາຍໃນທີ່ UID 1234 ເປັນເຈົ້າຂອງ; ມັນບໍ່ໄດ້ລະບຸຊື່ຜູ້ໃຊ້ proxy HTTP.
ເທິງເຄື່ອງທີ່ແລ່ນ Squid, ແຍກເສັ້ນທາງເຫຼົ່ານີ້:
| ການຈະລາຈອນ | ຄວາມແຕກຕ່າງທີ່ກ່ຽວຂ້ອງ |
|---|---|
| ລູກຄ້າເຊື່ອມຕໍ່ກັບ Squid ເທິງເຄື່ອງນີ້ | ການເຊື່ອມຕໍ່ເຂົ້າຫາຕົວຮັບຟັງຂອງ proxy |
| Squid ເປີດການເຊື່ອມຕໍ່ໄປຫາປາຍທາງ | ຊອກເກັດຂາອອກທີ່ສ້າງພາຍໃນ |
| ລູກຄ້າ LAN ເສັ້ນທາງໂດຍກົງຜ່ານເຄື່ອງນີ້ | ການຈະລາຈອນທີ່ສົ່ງຕໍ່ໂດຍບໍ່ມີຊອກເກັດຜູ້ສ້າງພາຍໃນ |
ສ່ວນຂະຫຍາຍນີ້ໃຊ້ໄດ້ໃນ OUTPUT ແລະ POSTROUTING. ແພັກເກັດທີ່ສົ່ງຕໍ່ບໍ່ມີຊອກເກັດພາຍໃນທີ່ກ່ຽວຂ້ອງສຳລັບການຈັບຄູ່ນີ້, ດັ່ງນັ້ນກົດ FORWARD ບໍ່ສາມາດຄົ້ນພົບຜູ້ໃຊ້ຂອງຄອມພິວເຕີທາງໄກໂດຍການຖາມ UID ຂອງ Squid.
ດັ່ງນັ້ນນະໂຍບາຍທີ່ອະນຸຍາດຊອກເກັດຂາອອກຂອງ Squid ເອງນັ້ນແກ້ໄຂພຽງສ່ວນໜຶ່ງຂອງການອອກແບບເຄືອຂ່າຍທີ່ອີງໃສ່ proxy ຢ່າງດຽວ. ການສົ່ງຕໍ່ຜ່ານ gateway, ການເຂົ້າເຖິງຕົວຮັບຟັງ, ບໍລິການອື່ນທີ່ໄດ້ຮັບອະນຸຍາດ ແລະ ບັນຊີບໍລິການ proxy ຕົວຈິງ ຕ້ອງໄດ້ຮັບການຈັດການໃນຂອບເຂດທີ່ເໝາະສົມ.
ໃຊ້ຕົວຕົນຂອງເວລາແລ່ນທີ່ຕັ້ງໄວ້ ແທນການສົມມຸດວ່າ Squid ແລ່ນເປັນ nobody. ຫຼາຍຂະບວນການສາມາດແບ່ງປັນ UID ດຽວໄດ້, ດັ່ງນັ້ນການອະນຸຍາດຕາມ UID ເປັນຂອບເຂດບັນຊີ ບໍ່ແມ່ນຫຼັກຖານວ່າໄຟລ໌ປະຕິບັດການສະເພາະໜຶ່ງໄດ້ສ້າງທຸກການເຊື່ອມຕໍ່ທີ່ໄດ້ຮັບອະນຸຍາດ.