ເລືອກວິທີເຂົ້າສູ່ FTP proxy ທີ່ປະຕູທາງຂອງທ່ານຄາດຫວັງ
ຈັບຄູ່ການສົນທະນາ USER, SITE ຫຼື OPEN ຂອງປະຕູ FTP ພື້ນເມືອງກັບລູກຄ້າທີ່ຮອງຮັບມັນ, ໂດຍແຍກບັນຊີປະຕູອອກຈາກບັນຊີເປົ້າໝາຍ.
“FTP proxy” ອາດໝາຍເຖິງປະຕູທີ່ເວົ້າ FTP ເອງ. ການເຊື່ອມຕໍ່ກັບມັນແຕກຕ່າງຈາກການຂໍ CONNECT ຈາກ HTTP proxy ຫຼືການຂໍ SOCKS server ເປີດປາຍທາງ TCP.
ປະຕູຕ້ອງການໂຮສ ແລະ ບັນຊີເປົ້າໝາຍ, ແລະ ອາດຕ້ອງການການເຂົ້າຂອງຕົນເອງກ່ອນ. ຜະລິດຕະພັນສະແດງການສົນທະນານັ້ນໃນຫຼາຍວິທີ:
| ການຈັດວາງ | ຮູບແບບຄຳສັ່ງທົ່ວໄປ |
|---|---|
| ເປົ້າໝາຍຖືກໃສ່ລະຫັດໃນຊື່ຜູ້ໃຊ້ | USER target-user@target-host |
| ການເຂົ້າປະຕູແຍກຕ່າງຫາກ | USER/PASS ຂອງປະຕູ, ຈາກນັ້ນການເຂົ້າເປົ້າໝາຍ |
| ຄຳສັ່ງປາຍທາງຢ່າງຊັດເຈນ | SITE target-host ຫຼື OPEN target-host, ຈາກນັ້ນການເຂົ້າທີ່ຕ້ອງການ |
ເຫຼົ່ານີ້ແມ່ນກຸ່ມຂອງຂໍ້ຕົກລົງ, ບໍ່ແມ່ນລຳດັບມາດຕະຖານດຽວທີ່ສົ່ງໄປຫາທຸກປະຕູ. ເລືອກວິທີທີ່ຜູ້ດູແລລະບົບໄດ້ບັນທຶກໄວ້ ແລະ ລູກຄ້າຮອງຮັບ.
ໃຫ້ບັນຊີທັງສອງເຫັນໄດ້ໃນການຕັ້ງຄ່າ
ລະຫັດຜ່ານ FTP ຂອງເປົ້າໝາຍ ແລະ ລະຫັດຜ່ານຂອງປະຕູອາດແຕກຕ່າງກັນ. ບາງປະຕູລວມພວກມັນເປັນຕົວແທນ USER/PASS ດຽວ; ອື່ນໆຕ້ອງການການແລກປ່ຽນແຍກຕ່າງຫາກ. ການໃສ່ຄ່າທັງໝົດໃນສາຍດຽວບໍ່ສາມາດສ້າງລູກຄ້າທີ່ຕ້ອງສົ່ງຄຳສັ່ງເພີ່ມໄດ້.
ນີ້ອະທິບາຍຂອບເຂດທີ່ເປັນປະໂຫຍດໃນໂຄດ FtpWebRequest ເກົ່າ. ການເຊື່ອມຕໍ່ FTP ປົກກະຕິໄປຫາປະຕູ, ດ້ວຍຊື່ຜູ້ໃຊ້ສະເພາະປະຕູ, ອາດເໝາະກັບການຈັດວາງ USER/PASS ບາງຢ່າງ. ປະຕູທີ່ຕ້ອງການການສົນທະນາ SITE ຫຼື OPEN ແຍກຕ່າງຫາກຕ້ອງການລູກຄ້າທີ່ຮອງຮັບການໄຫຼນັ້ນແທ້ໆ. ຄຸນສົມບັດ Proxy ໃນ WebRequest ແມ່ນອີກອິນເຕີເຟສໜຶ່ງ.
ຕົວຢ່າງ WinSCP ສະເໜີວິທີເຂົ້າ FTP proxy ແຍກຕ່າງຫາກ ແທນທີ່ຈະຖືທຸກປະຕູເປັນຊ່ອງໂຮສດຽວ. ຄ່າການຕັ້ງຄ່າດິບເປັນຕົວເລກຂອງມັນເປັນຂອງ API ທີ່ບັນທຶກໄວ້; ໃຊ້ຊື່ວິທີ ແລະ ການສົນທະນາທີ່ຕັ້ງໃຈເມື່ອທົບທວນການຕັ້ງຄ່າ.
ຫຼັງການເຂົ້າ, ການໂອນໄຟລ໌ຍັງຕ້ອງການ ການເຊື່ອມຕໍ່ຂໍ້ມູນ FTP ແລະ ໂໝດ TLS ທີ່ເລືອກ. ການເຂົ້າສຳເລັດໃນຊ່ອງຄວບຄຸມແມ່ນຈຸດເລີ່ມຕົ້ນຂອງເສັ້ນທາງນັ້ນ, ບໍ່ແມ່ນຫຼັກຖານວ່າທຸກການໂອນຂໍ້ມູນໄດ້ຮັບອະນຸຍາດແລ້ວ.