ເປັນຫຍັງ DNAT ໄປ 127.0.0.1 ຈຶ່ງຕ້ອງການການດູແລພິເສດ
ເຂົ້າໃຈ route_localnet ເມື່ອປ່ຽນເສັ້ນທາງທຣາຟຟິກພາຍນອກໄປຫາ proxy ທີ່ຜູກກັບ loopback.
ບໍລິການໜຶ່ງກຳລັງຟັງຢູ່ 127.0.0.1:1080. ກົດ DNAT ສົ່ງທຣາຟຟິກທີ່ເຂົ້າມາໄປຫາທີ່ຢູ່ນັ້ນ ແຕ່ການເຊື່ອມຕໍ່ຍັງລົ້ມເຫຼວ. ບໍລິການອາດຈະປົກກະຕິ ແລະ ກົດ NAT ອາດຈະກົງກັນ: ທີ່ຢູ່ loopback ຂອງ IPv4 ໄດ້ຮັບການຈັດການເສັ້ນທາງແບບພິເສດ.
route_localnet ຂອງ Linux ຄວບຄຸມວ່າທີ່ຢູ່ 127/8 ຖືກຖືວ່າເປັນທີ່ຢູ່ Mars ເມື່ອຈັດເສັ້ນທາງ ຫຼື ບໍ່. ຄ່າເລີ່ມຕົ້ນຂອງມັນຮັກສາຂອບເຂດ loopback ປົກກະຕິ. ຂໍ້ຍົກເວັ້ນສະເພາະອິນເຕີເຟສອາດກ່ຽວຂ້ອງກັບການອອກແບບປ່ຽນເສັ້ນທາງພາຍໃນທີ່ເຈດຕະນາ.
ນັ້ນອະທິບາຍວ່າເປັນຫຍັງກົດທີ່ເຮັດວຽກຢູ່ເຄື່ອງອື່ນອາດຂຶ້ນກັບ sysctl ທີ່ທ່ານບໍ່ໄດ້ຄັດລອກ. ແຕ່ມັນບໍ່ໄດ້ໃຫ້ເຫດຜົນໃນການເປີດຕົວເລືອກນີ້ທຸກບ່ອນ.
ຂໍ້ສົມມຸດດ້ານຄວາມປອດໄພປ່ຽນໄປຕາມເສັ້ນທາງ
ການຜູກກັບ loopback ມັກຖືກໃຊ້ເພາະຕົວຊ່ວຍບໍ່ມີການພິສູດຢືນຢັນລູກຄ້າແບບເອກະລາດ. ຖ້າທຣາຟຟິກຈາກອິນເຕີເຟສອື່ນສາມາດຖືກຈັດເສັ້ນທາງໄປທີ່ນັ້ນໄດ້, ທີ່ຢູ່ຜູກຢ່າງດຽວບໍ່ໄດ້ອະທິບາຍຜູ້ຮັບທີ່ເຂົ້າເຖິງໄດ້ອີກຕໍ່ໄປ. ຈຳກັດແຫຼ່ງເຂົ້າ, ປາຍທາງ ແລະ ພອດໃນຊຸດກົດຕົວຈິງ, ລວມທັງທຣາຟຟິກທີ່ອ້າງວ່າເປັນທີ່ຢູ່ແຫຼ່ງ ຫຼື ປາຍທາງ loopback ເມື່ອກ່ຽວຂ້ອງ.
ທົບທວນ namespace ເຄືອຂ່າຍທີ່ມີບໍລິການນີ້. loopback ຂອງຄອນເທນເນີບໍ່ແມ່ນ loopback ຂອງໂຮສ, ແລະ ການປ່ຽນການຕັ້ງຄ່າອິນເຕີເຟສຂອງໂຮສບໍ່ໄດ້ສ້າງຕົວຟັງໃນຄອນເທນເນີໂດຍອັດຕະໂນມັດ.
rp_filter ຕອບຄຳຖາມອື່ນກ່ຽວກັບການກວດສອບເສັ້ນທາງແຫຼ່ງ. ການປິດມັນທົ່ວໂລກບໍ່ແມ່ນການທົດແທນທົ່ວໄປສຳລັບການເຂົ້າໃຈການຈັດເສັ້ນທາງ loopback. ເຊັ່ນດຽວກັນ ip_nonlocal_bind ກ່ຽວຂ້ອງກັບການຜູກ socket ກັບທີ່ຢູ່ທີ່ບໍ່ແມ່ນພາຍໃນ, ບໍ່ແມ່ນການເຮັດໃຫ້ເສັ້ນທາງ DNAT ນີ້ຖືກຕ້ອງ.
ສຸດທ້າຍ, ໂປໂຕຄອນທີ່ຖືກປ່ຽນເສັ້ນທາງຕ້ອງເໝາະກັບຕົວຟັງ. ການສົ່ງທຣາຟຟິກ HTTP ຫຼື TLS ດິບໄປຫາພອດ SOCKS ຍັງຕ້ອງການ ຕົວແປ; ຂໍ້ຍົກເວັ້ນເສັ້ນທາງບໍ່ສາມາດໃຫ້ການເຈລະຈາທີ່ຂາດຫາຍໄປໄດ້.