FTP passive mode firewall पर काम क्यों नहीं करता है

FTP login तो हो जाता है लेकिन directory listing hang क्यों हो जाती है

FTP passive mode firewall पर काम नहीं करता क्योंकि FTP एक के बजाय दो TCP connections का उपयोग करता है। Port 21 पर होने वाला connection login और commands को ले जाता है, इसलिए username और password स्वीकार कर लिए जाते हैं और firewall सही दिखता है। इसके बाद पहले ls को एक अलग port पर दूसरे connection की आवश्यकता होती है। Firewall में ऐसा कुछ भी नहीं है जो उस connection को अनुमति दे, इसलिए client तब तक प्रतीक्षा करता है जब तक कि उसका समय समाप्त (timeout) न हो जाए।

इसका समाधान उन data connections के लिए ports की एक निश्चित range निर्धारित करना है, साथ ही एक firewall rule बनाना है जो उसी range को अनुमति दे। NAT (network address translation) के पीछे स्थित सर्वर को एक और setting की आवश्यकता होती है ताकि वह सही address advertise कर सके। पहले connection tracking helpers यह काम आपके लिए कर देते थे। अब वे ऐसा नहीं करते हैं, और किसी पुरानी guide को copy करने से पहले इसका कारण जानना आवश्यक है।

कंट्रोल चैनल और डेटा चैनल

FTP (file transfer protocol) को RFC 959 में निर्दिष्ट किया गया है और यह NAT तथा stateful firewall दोनों से पुराना है। एक सत्र TCP port 21 पर एक कंट्रोल कनेक्शन खोलता है और पूरे सत्र के दौरान उसे खुला रखता है। कमांड्स plain text के रूप में भेजे जाते हैं। उत्तर तीन अंकों के कोड और टेक्स्ट की एक पंक्ति के रूप में वापस आते हैं। वह कनेक्शन कभी भी फाइल कंटेंट को कैरी नहीं करता है।

डेटा के प्रत्येक हिस्से के लिए अपना अलग TCP कनेक्शन होता है: एक directory listing के लिए (LIST), एक प्रत्येक download के लिए (RETR), और एक प्रत्येक upload के लिए (STOR)। इसे खोला जाता है, एक बार उपयोग किया जाता है, और बंद कर दिया जाता है। प्रमाणीकरण पूरी तरह से कंट्रोल चैनल पर होता है, इसलिए एक टूटा हुआ डेटा पाथ हमेशा एक जैसा दिखता है: एक सफल लॉगिन, और उसके बाद हैंग होना। यदि क्लाइंट एक 230 उत्तर प्रिंट करता है और फिर लिस्टिंग पर रुक जाता है, तो आप डेटा चैनल की समस्या देख रहे हैं, न कि क्रेडेंशियल्स की।

Active mode: सर्वर क्लाइंट से वापस कनेक्ट होता है

Active mode में क्लाइंट एक पोर्ट चुनता है, उस पर listen करता है, और सर्वर को बताता है कि कहाँ संपर्क करना है:

PORT 192,168,1,50,195,80

पहले चार अंक क्लाइंट का IP address हैं। अंतिम दो अंक पोर्ट हैं, जिन्हें दो bytes के रूप में encode किया गया है: 195 * 256 + 80 = 50000। इसके बाद सर्वर अपने पोर्ट 20 से क्लाइंट के पोर्ट 50000 तक data connection खोलता है।

क्लाइंट के दृष्टिकोण से यह connection inbound और unsolicited होता है, इसलिए क्लाइंट का firewall इसे drop कर देता है। यदि क्लाइंट किसी home router के पीछे है, तो PORT command में दिया गया address एक private address होता है जिसे सर्वर बिल्कुल भी access नहीं कर सकता। Active mode के कारण ही FTP की यह प्रतिष्ठा बनी है कि यह काम नहीं करता है।

Passive mode: client दोनों connections खोलता है

Passive mode डेटा कनेक्शन की दिशा को उलट देता है। क्लाइंट PASV भेजता है और सर्वर अपने स्वयं के पते और पोर्ट के साथ उत्तर देता है:

227 Entering Passive Mode (203,0,113,10,195,80)

Encoding समान है, इसलिए क्लाइंट 203.0.113.10 पर पोर्ट 50000 से कनेक्ट होता है। क्लाइंट अब दोनों connections खोलता है, यही कारण है कि passive mode क्लाइंट-साइड NAT के साथ काम करता है और हर आधुनिक क्लाइंट पहले इसी का अनुरोध करता है।

समस्या गायब होने के बजाय स्थानांतरित हो गई है। अवांछित इनबाउंड कनेक्शन अब आपके सर्वर पर, एक ऐसे उच्च पोर्ट पर आता है जो प्रत्येक ट्रांसफर के साथ बदलता रहता है। वह फ़ायरवॉल आपका है, इसलिए अब समस्या भी आपकी है।

EPSV (extended passive mode, RFC 2428) एक स्पष्ट उत्तर के साथ वही विचार है:

229 Entering Extended Passive Mode (|||50000|)

इसमें कोई पता नहीं होता है। क्लाइंट उस पते का पुन: उपयोग करता है जो उसके पास कंट्रोल कनेक्शन के लिए पहले से मौजूद है, जो इसे IPv6 पर काम करने योग्य बनाता है और NAT बग की एक पूरी श्रेणी को हटा देता है। curl का मैनुअल बताता है कि curl सामान्यतः PASV से पहले EPSV का प्रयास करता है। पोर्ट अभी भी रनटाइम पर चुना जाता है, इसलिए EPSV आपके फ़ायरवॉल नियमों के बारे में कुछ नहीं बदलता है।

सामान्य firewall rule डेटा चैनल को अनुमति क्यों नहीं दे सकता

इसका कारण यह है कि जब आप rule लिखते हैं, तब port number मौजूद ही नहीं होता है। सर्वर इसे प्रत्येक transfer के लिए चुनता है। यदि इसे default पर छोड़ दिया जाए, तो vsftpd pasv_min_port और pasv_max_port को 0 के रूप में document करता है, जिसका अर्थ है "किसी भी port का उपयोग करें", इसलिए डेटा कनेक्शन 1023 से ऊपर किसी भी port पर आ सकता है। sudo ufw allow 21/tcp केवल control channel को अनुमति देता है और कुछ नहीं, और यही वह configuration है जो सफल login तो देता है लेकिन listing विफल हो जाती है। यदि एक निश्चित port पर listening करने वाली service की अवधारणा अभी भी स्पष्ट नहीं है, तो Linux पर ports और listening sockets कैसे काम करते हैं इसके लिए आधारभूत जानकारी प्रदान करता है।

एक stateful firewall कनेक्शन को ट्रैक करता है, और kernel एक नए कनेक्शन को मौजूदा कनेक्शन के RELATED के रूप में स्वीकार कर सकता है। FTP के लिए इसके लिए किसी ऐसी चीज़ की आवश्यकता होती है जो control stream को पढ़ सके और 227 या PORT लाइन से port को निकाल सके। default रूप से ऐसा कोई नहीं करता है।

FTP connection tracking helper अब समाधान क्यों नहीं है

पुराने गाइड्स आपको nf_conntrack_ftp kernel module का उपयोग करने का सुझाव देते हैं। यह plaintext control channel को पढ़ता है, घोषित port को ढूँढता है, और एक expectation रजिस्टर करता है, जिससे data connection बिना किसी विशिष्ट port rule के स्वीकार कर लिया जाता है। उन गाइड्स के लिखे जाने के बाद से चार चीजें बदल गई हैं।

Automatic helper assignment अब बंद है। Kernel nf_conntrack_helper sysctl को "0 - disabled (default)" के रूप में document करता है और जोड़ता है: "यदि यह disabled है, तो connections को helpers असाइन करने के लिए iptables rules सेट करना आवश्यक है।" केवल module लोड करने से कुछ नहीं होता।

वर्तमान kernels में यह switch हटा दिया गया है। sysctl net.netfilter.nf_conntrack_helper चलाएँ। sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_helper: No such file or directory का उत्तर मिलने का अर्थ है कि kernel में automatic helper assignment का विकल्प अब उपलब्ध नहीं है। यदि आपको कोई संख्या प्राप्त होती है, तो switch अभी भी मौजूद है और उसका default मान 0 है।

Firewall front ends ने भी इसे deprecated कर दिया है। Ubuntu 24.04 पर man ufw-framework, /etc/default/ufw में मौजूद IPT_MODULES लाइन के बारे में कहता है: "इस तरह से connection tracking modules (nf_conntrack_*) को बिना शर्त लोड करना deprecated है", और यह भी जोड़ता है कि helper rules को "RULES FILES के माध्यम से प्रबंधित किया जाना चाहिए।" Firewalld, firewalld.conf में AutomaticHelpers को "Deprecated. यह विकल्प ignored है और अब उपयोग में नहीं है" के रूप में document करता है। अब helper अटैच करने का अर्थ है मैन्युअल रूप से CT target के साथ एक स्पष्ट rule लिखना, जो नीचे दिए गए समाधान की तुलना में अधिक मेहनत वाला है और TLS enable करते ही काम करना बंद कर देता है। Ubuntu पर iptables और nftables में बताया गया है कि वे rules वास्तव में कहाँ स्थित होते हैं।

TLS इस बहस को समाप्त करता है। एक helper control channel को text के रूप में पढ़कर काम करता है। यदि आप उस channel को encrypt कर देते हैं, तो helper को केवल ciphertext दिखाई देगा, इसलिए वह port नहीं ढूँढ पाएगा। इसका कोई समाधान नहीं है, और न ही होना चाहिए: एक middlebox जो आपके control channel को पढ़ सकता है, वह ऐसा middlebox है जो आपका password भी पढ़ सकता है।

सर्वर पर passive port range घोषित करें

हर FTP सर्वर को यह निर्देश दिया जा सकता है कि वह आपके द्वारा चुनी गई range से ही अपने passive ports का चयन करे। विकल्प के नाम अलग-अलग होते हैं, इसलिए आप जो सर्वर चला रहे हैं उसके documentation की जाँच करें।

vsftpd के लिए, /etc/vsftpd.conf में:

pasv_enable=YES
pasv_min_port=30000
pasv_max_port=30099

pasv_enable में पहले से ही YES का default सेट होता है। दोनों port विकल्पों का default मान 0 होता है, जो ऊपर वर्णित "use any port" व्यवहार है। इसे sudo systemctl restart vsftpd के साथ लागू करें, फिर systemctl status vsftpd के साथ पुष्टि करें कि service वापस चल पड़ी है। vsftpd किसी ऐसी configuration line को ignore करने के बजाय start होने से मना कर देता है जिसे वह parse नहीं कर सकता, इसलिए यदि restart विफल हो जाए, तो 500 OOPS: लाइन के लिए journalctl -u vsftpd -n 20 पढ़ें, जहाँ आपने विकल्प टाइप किया है।

ProFTPD के लिए, proftpd.conf में:

PassivePorts 30000 30099

ProFTPD यहाँ कोई default मान नहीं बताता: directive के बिना kernel port चुनता है। इसके documentation में यह भी कहा गया है कि जब आपकी range में कोई port खाली नहीं होता, तो सर्वर kernel द्वारा assigned port पर वापस आ जाता है और एक message log करता है। इसलिए, बहुत छोटी range कभी-कभी विफल होती है बजाय इसके कि वह स्पष्ट रूप से विफल हो, जिसे diagnose करना बहुत कठिन होता है। non-privileged ports का उपयोग करें, 1024 और उससे ऊपर।

Pure-FTPd एक flag लेता है, -p first:last, जिसे man pure-ftpd में "passive-mode downloads के लिए केवल first से last तक की range में ports का उपयोग करें" के रूप में document किया गया है, जो "pure-ftpd को packet filters के साथ अधिक compatible बनाता है"। Packaged builds आमतौर पर उस flag को एक config file में लपेटते हैं, इसलिए अनुमान लगाने के बजाय file के नाम के लिए अपने distribution के docs देखें।

आपको कितने ports की आवश्यकता है? एक समय में चल रहे प्रत्येक data connection के लिए एक। एक बंद TCP port पुन: उपयोग किए जाने से पहले कुछ मिनटों के लिए TIME_WAIT में रहता है, इसलिए अपनी अपेक्षित peak से कई गुना अधिक की अनुमति दें। कुछ users के लिए सौ ports पर्याप्त हैं, और एक व्यस्त public server को बहुत अधिक की आवश्यकता होती है।

range कहाँ होनी चाहिए? पहले sysctl net.ipv4.ip_local_port_range चलाएँ। एक stock Ubuntu box पर यह 32768 60999 दिखाता है, जो वे ports हैं जिन्हें kernel outgoing connections के लिए देता है। उस window के भीतर एक passive range किसी ऐसे outbound connection के साथ टकरा सकती है जिसके पास पहले से ही वह port है, इसलिए range को उससे नीचे रखें। default box पर 30000 से 30099 सुरक्षित है। उस संख्या पर भरोसा करने के बजाय अपने स्वयं के box की जाँच करें।

Firewall में उसी range को खोलें

ufw एक range को colon के साथ लिखता है, और इसके manual में कहा गया है कि एक range या list का उपयोग "multiple ports को निर्दिष्ट करने के लिए भी किया जा सकता है, जिस स्थिति में protocol की आवश्यकता होती है":

sudo ufw allow 21/tcp
sudo ufw allow 30000:30099/tcp
sudo ufw status verbose

ufw status verbose को अब दोनों entries दिखानी चाहिए। /tcp के बिना वही command एक error के साथ reject कर दी जाती है जो आपको tcp या udp का नाम बताने के लिए कहती है, क्योंकि ufw अनुमान नहीं लगाएगा। VPS पर ufw rule syntax बाकी जानकारी कवर करता है।

firewalld range को hyphen के साथ लिखता है और इसे reload करने की आवश्यकता होती है:

sudo firewall-cmd --permanent --add-service=ftp
sudo firewall-cmd --permanent --add-port=30000-30099/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

--add-service=ftp 21/tcp को खोलता है और ftp helper का अनुरोध करता है, जिसे shipped service definition में नाम दिया गया है। यह आपकी passive range को नहीं खोलता है, इसलिए यह आपको ठीक उसी स्थिति में छोड़ देता है जहाँ से आपने शुरुआत की थी। VPS पर firewalld zones और services में विस्तृत जानकारी दी गई है।

सीधे nftables, आपकी input chain के अंदर:

tcp dport { 21, 30000-30099 } accept

एक और firewall जिसे याद रखना है: अधिकांश providers operating system के बाहर, control panel में एक network firewall चलाते हैं। यदि box पर rules सही दिखते हैं और packets अभी भी नहीं पहुँच रहे हैं, तो वहाँ भी उसी range को खोलें।

जब सर्वर NAT के पीछे हो तो उसे अपना public address बताएं

सर्वर पर ip -4 addr show चलाएं। यदि interface पर मौजूद address वही है जिससे clients connect करते हैं, तो इस section को छोड़ दें। यदि interface पर एक private address (10.x, 172.16 से 172.31.x, 192.168.x) है और platform उस पर एक public address map करता है, तो सर्वर को अपना public address पता नहीं होता है। vsftpd, pasv_address के लिए default को "address is taken from the incoming connected socket" के रूप में document करता है, इसलिए 227 reply में private address होता है और client को ऐसी जगह भेजा जाता है जहाँ वह पहुँच नहीं सकता।

FileZilla इसे बिल्कुल सही नाम देता है:

Server sent passive reply with unroutable address. Using server address instead.

FileZilla इसे ठीक कर लेता है और आगे बढ़ जाता है। कई अन्य clients ऐसा नहीं करते हैं। वे 10.0.0.5 पर dial करते हैं और hang हो जाते हैं।

curl भी इस समस्या को छिपा देता है, जो तब मायने रखता है जब आप test के लिए curl का उपयोग कर रहे हों। इसका manual कहता है कि --ftp-skip-pasv-ip "is enabled by default (added in 7.74.0)", इसलिए curl 227 reply में दिए गए address को ignore कर देता है और control connection के address का ही पुनः उपयोग करता है। जो transfer curl के साथ काम करता है, वह भी इसी एक कारण से graphical client में fail हो सकता है।

Address को स्पष्ट रूप से set करें। vsftpd pasv_address=203.0.113.10 लेता है, साथ ही pasv_addr_resolve=YES (default NO) यदि आप hostname लिखना पसंद करते हैं। ProFTPD MasqueradeAddress लेता है, जो एक address, DNS name, या interface name स्वीकार करता है। Pure-FTPd -P लेता है, जिसे उस स्थिति के लिए document किया गया है जहाँ "the server is behind a masquerading (NAT) box" हो। EPSV पूरी समस्या से बचाता है क्योंकि इसके reply में कोई address field नहीं होता है, लेकिन आप उस पर निर्भर नहीं रह सकते, क्योंकि client यह तय करता है कि कौन सा command भेजना है।

TLS में क्या बदलाव होते हैं

FTPS का अर्थ है TLS (transport layer security) के माध्यम से FTP। क्लाइंट सामान्य रूप से port 21 से कनेक्ट होता है, control channel को सुरक्षित करने के लिए AUTH TLS भेजता है, और फिर data channel को भी encrypt करने के लिए PROT P भेजता है। Plain FTP पासवर्ड को readable text के रूप में नेटवर्क पर भेजता है, इसलिए यदि आपको FTP का उपयोग करना ही है, तो FTPS चलाएं। vsftpd, ssl_enable के साथ आता है जो डिफ़ॉल्ट रूप से NO पर सेट होता है।

इसके परिणामस्वरूप दो बातें होती हैं। कोई भी connection tracking helper काम नहीं कर सकता, जो कि ऊपर बताया गया बिंदु है जिसे दूसरी तरफ से देखा गया है। और sudo tcpdump -nAi any 'tcp port 21' अब आपको 227 रिप्लाई नहीं दिखाएगा, इसलिए जब आपको यह जानने की आवश्यकता हो कि सर्वर ने किस एड्रेस और पोर्ट का विज्ञापन (advertise) किया है, तो नेटवर्क ट्रैफ़िक के बजाय सर्वर के स्वयं के लॉग को पढ़ें।

बाहर से बदलाव का परीक्षण

इन्हें किसी अन्य मशीन से चलाएं। सर्वर से ही परीक्षण करने पर वह फायरवॉल छूट जाता है जिसे आप ठीक करने का प्रयास कर रहे हैं।

sudo ss -ltnp | grep :21
curl -v --disable-epsv --user ftpuser:secret ftp://example.com/
nc -vz example.com 30000

ss को पोर्ट 21 पर FTP डेमन के लिसन (listen) करने की स्थिति दिखानी चाहिए। जब सर्वर निष्क्रिय (idle) होता है, तो पैसिव रेंज पर कुछ भी लिसन नहीं करता है, क्योंकि वे सॉकेट केवल ट्रांसफर के लिए बनाए जाते हैं और उसके बाद बंद कर दिए जाते हैं।

--disable-epsv, curl को PASV पाथ पर जाने के लिए मजबूर करता है, जो कि वह पाथ है जहाँ एड्रेस की समस्या सामने आती है। ट्रेस सर्वर का उत्तर प्रिंट करता है, और फिर वह एड्रेस और पोर्ट दिखाता है जिस पर curl डायल करता है:

< 227 Entering Passive Mode (203,0,113,10,117,52)

117 * 256 + 52 = 30004, जो घोषित रेंज के भीतर है। उस लाइन पर प्राइवेट एड्रेस का मतलब है कि pasv_address सेट नहीं है। आपकी रेंज के बाहर का पोर्ट यह दर्शाता है कि सर्वर ने कॉन्फ़िगरेशन बदलाव को कभी पढ़ा ही नहीं, इसलिए जांचें कि क्या आपने वही फाइल एडिट की है जिसका उपयोग रनिंग सर्विस कर रही है।

nc अपने आप में फायरवॉल के प्रश्न का उत्तर देता है। तत्काल Connection refused का मतलब है कि पैकेट सर्वर तक पहुंच गया और उसे लिसन करने वाला कोई नहीं मिला, जो कि एक निष्क्रिय पैसिव पोर्ट के लिए सही परिणाम है: आपका नियम काम कर रहा है। nc तक हैंग होने का मतलब है कि किसी चीज़ ने पैकेट को चुपचाप ड्रॉप कर दिया है, जो कि एक फायरवॉल है, या तो बॉक्स पर या आपके प्रोवाइडर के पैनल में। यह अंतर वही है जो SSH के लिए रिफ्यूज्ड बनाम टाइमड आउट में वर्णित है, और यह हर पोर्ट पर लागू होता है।

क्या आपको अभी भी FTP का उपयोग करना चाहिए?

नए कार्यों के लिए, नहीं। SFTP (SSH file transfer protocol) पोर्ट 22 पर एक ही SSH कनेक्शन के भीतर चलता है। इसमें कोई दूसरा चैनल, कोई passive range, कोई NAT सेटिंग और सुरक्षित करने के लिए कोई अतिरिक्त daemon नहीं होता है, क्योंकि OpenSSH इसे पहले से ही प्रदान करता है। sftp user@example.com उस सर्वर पर काम करता है जहाँ आपने कभी कोई file transfer service कॉन्फ़िगर नहीं की है। किसी को केवल फाइलें देने के लिए, sshd_config में ForceCommand internal-sftp के साथ ChrootDirectory का उपयोग किया जाता है। उस डायरेक्टरी का मालिक root होना चाहिए और वह user द्वारा writable नहीं होनी चाहिए, अन्यथा sshd सेशन को अस्वीकार कर देता है और एक bad ownership or modes for chroot directory लाइन लॉग करता है।

FTP तब भी अपनी जगह बनाए रखता है जब दूसरा पक्ष बदलाव नहीं कर सकता। स्कैनर और मल्टीफ़ंक्शन प्रिंटर में ऐसा फर्मवेयर होता है जो केवल FTP का समर्थन करता है। लैब और औद्योगिक उपकरण अक्सर एक फिक्स्ड इमेज पर चलते हैं जिसे कोई भी दोबारा प्रमाणित (recertify) नहीं करेगा। व्यावसायिक भागीदार FTPS ड्रॉप प्रकाशित करते हैं और एक आपूर्तिकर्ता के लिए कोई नया प्रोटोकॉल नहीं जोड़ेंगे। इन सभी मामलों में, passive range और उससे मेल खाने वाला firewall rule ही पूरा काम है, और सादे FTP के बजाय FTPS ही वह संस्करण है जिसे चलाना चाहिए। दो-चैनल वाला डिज़ाइन 1985 का एक निर्णय है जो अब ऐसी दुनिया में चल रहा है जिसकी उसने कभी कल्पना नहीं की थी, यह कहानी फाइल ट्रांसफर प्रोटोकॉल के इतिहास में कवर की गई है।

FAQ

FTP login तो हो जाता है लेकिन directory listing क्यों अटक जाती है?

Login केवल port 21 पर control connection का उपयोग करता है, जिसे आपका firewall अनुमति देता है। Directory listing के लिए एक अलग port पर दूसरे TCP connection की आवश्यकता होती है, और वह connection block हो जाता है। FTP server पर एक passive port range घोषित करें, firewall में वही range खोलें, और listing पूरी हो जाएगी। Listing का अटकना एक data channel की समस्या है, न कि password की।

FTP passive mode के लिए मुझे कौन से ports खोलने होंगे?

Control channel के लिए port 21, और passive data connections के लिए वह range जो आपने configure की है। इसकी कोई मानक range नहीं है, क्योंकि इसे आप चुनते हैं। 30000 से 30099 जैसी range काम करती है: इसे अपने simultaneous transfers की अधिकतम संख्या के अनुसार रखें, और इसे kernel की outgoing port range से अलग रखें, जिसे आप sysctl net.ipv4.ip_local_port_range के साथ देख सकते हैं। यदि आपका provider अपने control panel में network firewall चलाता है, तो वहां भी वही range खोलें।

क्या मुझे अभी भी nf_conntrack_ftp की आवश्यकता है?

नहीं, और वर्तमान kernel पर आप इस पर निर्भर नहीं रह सकते। Automatic helper assignment डिफ़ॉल्ट रूप से अक्षम है, और हाल के kernels पर net.netfilter.nf_conntrack_helper switch को हटा दिया गया है, इसलिए sysctl रिपोर्ट करता है कि फ़ाइल मौजूद नहीं है। ufw के manual में इन modules को बिना शर्त लोड करना deprecated माना गया है, और firewalld AutomaticHelpers को पूरी तरह से अनदेखा कर देता है। एक helper को control channel को plain text के रूप में पढ़ना पड़ता है, इसलिए जैसे ही आप FTPS सक्षम करते हैं, यह काम करना बंद कर देता है। इसके बजाय एक passive port range घोषित करें।

मेरा FTP client क्यों कहता है कि passive reply में एक unroutable address है?

Server ने PASV के साथ उस address का उत्तर दिया जिसे वह अपने स्वयं के interface पर देखता है, और वह address private है। यह तब होता है जब platform एक public address को private address पर map करता है। Public address को स्पष्ट रूप से सेट करें: vsftpd में pasv_address, ProFTPD में MasqueradeAddress, या Pure-FTPd में -P। FileZilla उस address का पुन: उपयोग करके इसे ठीक कर लेता है जिससे वह पहले ही connect हो चुका है, और "Using server address instead" log करता है, यही कारण है कि कुछ clients इस गलत configuration के बावजूद चल जाते हैं और अन्य अटक जाते हैं।

क्या मुझे FTPS या SFTP का उपयोग करना चाहिए?

SFTP का उपयोग उन सभी कार्यों के लिए करें जिन्हें आप दोनों छोरों पर नियंत्रित करते हैं: port 22 पर SSH के माध्यम से एक connection, कोई data channel खोलने की आवश्यकता नहीं, और यह पहले से ही चल रहा होता है। FTPS, TLS के ऊपर FTP है, इसलिए यह दो-channel वाले डिज़ाइन और उससे जुड़ी हर firewall समस्या को बरकरार रखता है। इसे तब चुनें जब दूसरी तरफ कोई अन्य विकल्प न हो। इंटरनेट पर plain FTP का उपयोग न करें, क्योंकि password नेटवर्क पर readable text के रूप में जाता है।