NAT करने वाले VPN गेटवे के पीछे FTP सूचियाँ क्यों अटक जाती हैं
लॉगिन और PWD सफल होते हैं, जबकि NAT केवल हेडर फिर से लिखता है तो LIST और RETR रुक जाते हैं। देखें कि FTP सहायक कहाँ बैठना चाहिए और पैसिव मोड कैसे ठीक करें।
लॉगिन काम करता है, PWD काम करता है, और फिर LIST अटक जाता है जब तक क्लाइंट हार न माने या किसी दूसरे डेटा मोड में न चला जाए। यही विभाजन हस्ताक्षर है: पोर्ट 21 तक नियंत्रण कनेक्शन स्वस्थ है, जबकि डेटा कनेक्शन ऐसे पते या पोर्ट से बन रहा है जहाँ दूसरा सिरा पहुँच नहीं सकता। जो VPN गेटवे खुद भी NAT करता है, उसके पीछे आम दोषी वह FTP कमांड है जिसका पेलोड 10.8.0.6 जैसा टनल पता बताता है। हेडर अनुवाद उस मान को कभी नहीं छूता।
आगे यह है कि वह मान कहाँ से आता है और कौन-सा बॉक्स उसे बदल सकता है।
टूटता पेलोड है, टनल नहीं
FTP डेटा के अंतिम बिंदु को नियंत्रण स्ट्रीम के अंदर रखता है। सक्रिय मोड में क्लाइंट अपने पते और पोर्ट के साथ PORT भेजता है, और सर्वर उसी जोड़ी पर वापस कॉल करता है। पैसिव मोड में सर्वर एक जोड़ी के साथ 227 का उत्तर देता है, और क्लाइंट उसके बजाय उसी को कॉल करता है।
दोनों रूप एक ही तरह का वाक्य ले जाते हैं: इस पते पर, इस पोर्ट पर जुड़ो। जो उपकरण केवल IP और TCP हेडर फिर से लिखता है वह वाक्य को अछूता छोड़ देता है, इसलिए एक सिरा ऐसे पते तक पहुँचने की कोशिश करता रहता है जो केवल टनल के दूसरी ओर मौजूद है। नियंत्रण कनेक्शन को पहले ही स्वस्थ घोषित किए जाने के बाद डेटा कनेक्शन रुक जाता है।
तीन मोड, तीन पेलोड
नीचे की तालिका दिखाती है कि किस पक्ष को कॉल करने को कहा जा रहा है, और केवल हेडर बदलने वाला NAT उस बारे में क्या कर सकता है।
अंतिम स्तंभ को पहले असफल होने वाली चीज़ के रूप में पढ़ें। सक्रिय मोड में निजी पते पर कॉल सर्वर करता है; पैसिव मोड में क्लाइंट करता है; FTPS में पेलोड साइफरटेक्स्ट है और बीच के बॉक्स के पास काम करने के लिए और भी कम है।
| Mode | Value in the control stream | Who dials whom | Header-only NAT leaves |
|---|---|---|---|
| Active (PORT) | client address and port | server dials the client | a server dialing an unreachable tunnel address |
| Passive (227) | server address and port | client dials the server | a client dialing an address it cannot route to |
| FTPS | the same values, inside TLS | as above | ciphertext, so no rewrite happens at all |
सहायक को वहाँ रखें जहाँ अनुवाद होता है
लिनक्स पर पेलोड फिर से लिखने का काम nf_conntrack_ftp सहायक करता है। यह नियंत्रण कनेक्शन पर नज़र रखता है, जिस पोर्ट पर बात हुई उसे सीखता है, डेटा प्रवाह के लिए अपेक्षा बनाता है, और NAT बॉक्स पर पेलोड के अंदर का पता और पोर्ट फिर से लिखता है। यह केवल उसी उपकरण पर मदद करता है जो क्लाइंट का पता अनुवादित करता है। इसे क्लाइंट पर, या केवल प्रवाह आगे भेजने वाले राउटर पर लोड करने से सत्र में कुछ नहीं बदलता।
ये तीन कमांड दिखाते हैं कि मॉड्यूल मौजूद है या नहीं, जुड़ा है या नहीं, और सत्र खुला रहने के दौरान अपेक्षा है या नहीं:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpमॉड्यूल लोड करना उसे जोड़ने के बराबर नहीं है। 4.7 से करनल net.netfilter.nf_conntrack_helper=0 के साथ आते हैं, इसलिए सहायक स्पष्ट नियम की प्रतीक्षा करता है, जैसे iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp। अगर ट्रांसफर का प्रयास करते समय अपेक्षा सूची खाली रहे, तो जोड़ना जाँचना है, मॉड्यूल नहीं।
पैसिव मोड: सर्वर को बताएँ कि क्या घोषित करना है
पैसिव मोड को नियतात्मक बनाना आसान है क्योंकि सर्वर को बताया जा सकता है कि 227 उत्तर में क्या रखना है। vsftpd में वह pasv_address है, साथ में pasv_min_port और pasv_max_port; ProFTPD MasqueradeAddress और PassivePorts इस्तेमाल करता है। इन्हें पहले सेट करें, क्योंकि सही घोषित पता उस ओर कुछ भी फिर से लिखने की ज़रूरत हटा देता है।
फिर ठीक उसी पोर्ट श्रेणी को गेटवे से गुज़रने दें, जैसे -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, ताकि नियम सर्वर की घोषणा से मेल खाए।
दोनों सेटिंग्स को सहमत होना चाहिए। ऐसे सर्वर को 30000-30100 घोषित करने को कहा जाए जबकि गेटवे 40000-40100 की अनुमति दे, तो वह सबसे कम उपयोगी तरीके से असफल होता है: नियंत्रण बातचीत स्वस्थ दिखती है और हर डेटा कनेक्शन मर जाता है। कुछ और डिबग करने से पहले संख्याएँ तुलना करें।
असफलता के दो हस्ताक्षर, और FTPS क्या हटाता है
LIST पर अटकना सत्र के पहले डेटा कनेक्शन की ओर इशारा करता है, जहाँ पते का फिर से लिखा जाना और अपेक्षा दोनों को काम करना है। काम करने वाले LIST के बाद RETR पर अटकना स्वयं ट्रांसफर की ओर इशारा करता है, यानी पैसिव श्रेणी या टनल का MTU। वह दूसरा हस्ताक्षर पेलोड की समस्या नहीं है, और सहायक की सेटिंग्स उसे ठीक नहीं करेंगी।
TLS के ऊपर FTP उस पेलोड को हटा देता है जो सहायक पढ़ता है। बीच का बॉक्स ऐसा PORT या PASV मान फिर से नहीं लिख सकता जिसे वह डिक्रिप्ट नहीं कर सकता, इसलिए बचे हुए विकल्प हैं TLS समाप्त करने वाला प्रॉक्सी, सीमित श्रेणी में पहुँचने योग्य पता घोषित करने वाला सर्वर, या अलग ट्रांसफर प्रोटोकॉल।
जाँचों का छोटा क्रम
लक्षण से बाहर की ओर काम करें। पुष्टि करें कि PWD सफल होते समय LIST असफल होता है, PORT या 227 पेलोड के अंदर का पता पकड़ें, और पूछें कि कौन-सा उपकरण वह पता अनुवादित करता है। वहाँ सहायक जोड़ें, एक ट्रांसफर के दौरान अपेक्षा सूची देखें, फिर सर्वर पर पैसिव मोड ठीक करें और गेटवे नियम में श्रेणी दोहराएँ।
डेटा-पथ की विफलता को थोक-ट्रांसफर विफलता से अलग रखें, क्योंकि वे आपको अलग सेटिंग्स तक ले जाती हैं।