तपाईंको गेटवेले अपेक्षा गर्ने FTP प्रोक्सी लगइन विधि छान्नुहोस्
मूल FTP गेटवेको USER, SITE वा OPEN कुराकानीलाई यसलाई समर्थन गर्ने क्लाइन्टसँग मिलाउनुहोस्, गेटवे खातालाई लक्ष्य खाताबाट अलग राख्दै।
“FTP प्रोक्सी” ले आफै FTP बोल्ने गेटवे जनाउन सक्छ। त्यसमा जोडिनु HTTP प्रोक्सीलाई CONNECT माग्नु वा SOCKS सर्भरलाई TCP गन्तव्य खोल्न भन्नुभन्दा फरक हुन्छ।
गेटवेलाई लक्ष्य होस्ट र खाता चाहिन्छ, र पहिले आफ्नै लगइन पनि चाहिन सक्छ। उत्पादनहरूले त्यो कुराकानीलाई विभिन्न तरिकाले व्यक्त गर्छन्:
| व्यवस्था | सामान्य आदेशको रूप |
|---|---|
| प्रयोगकर्ता नाममा लक्ष्य इन्कोड गरिएको | USER target-user@target-host |
| छुट्टै गेटवे लगइन | गेटवे USER/PASS, त्यसपछि लक्ष्यको लगइन |
| स्पष्ट गन्तव्य आदेश | SITE target-host वा OPEN target-host, त्यसपछि आवश्यक लगइन |
यी परम्पराका परिवार हुन्, प्रत्येक गेटवेमा पठाउने एउटै मानक क्रम होइन। प्रशासकले कागजात गरेको र क्लाइन्टले समर्थन गर्ने विधि छान्नुहोस्।
सेटअपमा दुवै खाता देखिने गरी राख्नुहोस्
लक्ष्यको FTP पासवर्ड र गेटवेको पासवर्ड फरक हुन सक्छन्। केही गेटवेले तिनलाई एउटै USER/PASS निरूपणमा जोड्छन्; अरूले छुट्टै आदानप्रदान चाहन्छन्। सबै मान एउटै स्ट्रिङमा राख्नाले थप आदेश पठाउनुपर्ने क्लाइन्ट पुनःउत्पादन गर्न सकिँदैन।
यसले पुरानो FtpWebRequest कोडमा उपयोगी सीमा बुझाउँछ। गेटवेसँगको सामान्य FTP जडान, गेटवे-विशेष प्रयोगकर्ता नामसहित, केही USER/PASS व्यवस्थामा मिल्न सक्छ। छुट्टै SITE वा OPEN कुराकानी चाहिने गेटवेलाई त्यो प्रवाह साँच्चै समर्थन गर्ने क्लाइन्ट चाहिन्छ। WebRequest को Proxy गुण फेरि अर्को इन्टरफेस हो।
उदाहरणका लागि WinSCP सबै गेटवेलाई एउटै होस्ट फिल्ड मान्नुको सट्टा छुट्टाछुट्टै FTP प्रोक्सी लगइन विधि दिन्छ। त्यसका सङ्ख्यात्मक कच्चा सेटिङ मान त्यसको कागजात गरिएको API का हुन्; कन्फिगरेसन समीक्षा गर्दा विधिको नाम र अभिप्रेत कुराकानी प्रयोग गर्नुहोस्।
लगइनपछि पनि फाइल स्थानान्तरणलाई FTP डेटा जडान र छानिएको TLS मोड चाहिन्छ। नियन्त्रण च्यानलमा सफल लगइन त्यो मार्गको सुरुवात हो, हरेक डेटा स्थानान्तरण पहिले नै अनुमति छ भन्ने प्रमाण होइन।