FTP लॉगिन काम करता है पर फ़ोल्डर सूची अटक जाती है: क्यों
FTP लॉगिन और फ़ोल्डर सूचियाँ दो अलग कनेक्शन इस्तेमाल करती हैं। सूची अटके तो पासवर्ड नहीं, पैसिव डेटा पता और पोर्ट रेंज जाँचें।
उपयोगकर्ता नाम काम करता है, पासवर्ड काम करता है, और क्लाइंट कहता है कि वह जुड़ा हुआ है। फिर वह किसी फ़ोल्डर सूची या पहले फ़ाइल स्थानांतरण पर अनंत काल तक प्रतीक्षा करता है, और क्रेडेंशियल में कुछ भी यह नहीं समझाता। FTP हर सूची और हर फ़ाइल के लिए दूसरा कनेक्शन खोलता है, और वही दूसरा कनेक्शन विफल होता है। लॉगिन केवल यह सिद्ध करता है कि पहली बातचीत काम करती है।
जाँचें क्रम से करें। हर जाँच एक अलग परत को बाहर करती है, इसलिए पहली विसंगति पर रुकें।
पहले दोनों कनेक्शन अलग करें
नियंत्रण कनेक्शन सर्वर के सुनने वाले पोर्ट पर आदेश और उत्तर ले जाता है। डेटा कनेक्शन निर्देशिका सूची या फ़ाइल का मुख्य भाग ले जाता है, और पैसिव मोड में सर्वर अपना अंतिम बिंदु चुनता है और उसे PASV या EPSV उत्तर में घोषित करता है। पोर्ट 21 की अनुमति देना इस बारे में कुछ नहीं कहता कि डेटा पोर्ट पहुँच योग्य है या नहीं, और ठीक इसीलिए लॉगिन सफल होता है जबकि हर सूची समय-सीमा पर समाप्त हो जाती है। WinSCP की FTP मोड पर मार्गदर्शिका इस विभाजन और इसकी नेटवर्क आवश्यकताओं को समझाती है।
यदि क्लाइंट VPN के पीछे है, तो डेटा पथ उसी सुरंग से गुजरता है पर ज़रूरी नहीं कि उसी नीति से।
PASV उत्तर में पता पढ़ें
विस्तृत क्लाइंट चलाएँ और अनुमान लगाने के बजाय उत्तर पढ़ें। curl -v ftp://user@host/ सर्वर जो पता और पोर्ट चाहता है उसके साथ PASV पंक्ति छापता है, और क्लाइंट आगे उसी पते से जुड़ता है। यदि वह निजी पता है जिसका सुरंग के क्लाइंट पक्ष पर कोई अर्थ नहीं, तो नियंत्रण चैनल स्वस्थ रहते हुए डेटा कनेक्शन कहीं नहीं जाता।
उस पते की तुलना उस पते से करें जहाँ क्लाइंट वास्तव में पहुँचा। बेमेल ही उत्तर है, और वह आमतौर पर NAT से या आंतरिक पते के साथ कॉन्फ़िगर किए गए सर्वर से आता है।
पोर्ट रेंज और सुरंग नीति जाँचें
पैसिव सर्वर कॉन्फ़िगर की गई रेंज से डेटा पोर्ट आवंटित करते हैं, और उस रेंज को VPN और मार्ग के किसी भी फ़ायरवॉल से अनुमति दी जानी चाहिए। जो नीति 21 की अनुमति देती है और कुछ नहीं, वह केवल लॉगिन की नीति है। सर्वर चलाने वाले से रेंज की पुष्टि करें, फिर पूरी रेंज के एक जैसा व्यवहार करने का अनुमान लगाने के बजाय उससे एक पोर्ट जाँचें।
एन्क्रिप्टेड नियंत्रण चैनल इसे कठिन बनाते हैं, क्योंकि बीच का बॉक्स अब उड़ान के दौरान घोषित पते को फिर से नहीं लिख सकता।
जानें कब EPSV या वैकल्पिक रास्ता मदद करता है
EPSV अलग पते के बिना पोर्ट लौटाता है, जो दोनों सिरे समर्थन देने पर गलत पते की विफलता हटा देता है। कुछ क्लाइंट को घोषित पते को अनदेखा करके नियंत्रण कनेक्शन का गंतव्य दोबारा उपयोग करने के लिए भी कहा जा सकता है। दोनों विशिष्ट टोपोलॉजी के लिए वैध उपकरण हैं, सार्वभौमिक समाधान नहीं।
केवल सहायक को सत्र निरीक्षण करने देने के लिए TLS बंद न करें। यह काम करने वाले प्रोटोकॉल को टूटे हुए ख़तरा मॉडल से बदल देता है।
सूची और स्थानांतरण से पुष्टि करें
पता या पोर्ट नीति बदलने के बाद उसी VPN मार्ग पर नया सत्र खोलें और निर्देशिका की सूची लें। फिर छोटी फ़ाइल स्थानांतरित करें, क्योंकि कुछ सर्वरों पर सूची और स्थानांतरण अलग कोड पथ ले सकते हैं। क्लाइंट लॉग में अपेक्षित पते और पोर्ट तक डेटा कनेक्शन देखें और पुष्टि करें कि बाइट्स पहुँच गए.
यह करते समय FTP, FTPS और SFTP को मन में अलग रखें। पैसिव-पोर्ट परिवर्तन SFTP सेटिंग नहीं है, और सुधार प्रोटोकॉल के बीच नहीं जाता।