NAT करणाऱ्या VPN गेटवेमागे FTP याद्या का अडकतात
लॉगिन आणि PWD यशस्वी होतात, पण NAT फक्त हेडर पुन्हा लिहिते तेव्हा LIST आणि RETR थांबतात. FTP सहाय्यक कुठे असावा आणि पॅसिव्ह मोड कसा दुरुस्त करावा ते पहा.
लॉगिन चालते, PWD चालते, आणि मग LIST अडकते जोपर्यंत क्लायंट हार मानत नाही किंवा दुसऱ्या डेटा मोडमध्ये जात नाही। हा फरकच ओळख आहे: पोर्ट 21 वरचे नियंत्रण कनेक्शन निरोगी आहे, पण डेटा कनेक्शन अशा पत्त्या किंवा पोर्टवरून बांधले जाते जिथपर्यंत पलीकडचा टोक पोहोचू शकत नाही। NAT देखील करणाऱ्या VPN गेटवेमागे नेहमीचा दोषी म्हणजे अशी 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 पेलोडमधला पत्ता पकडा, आणि कोणते उपकरण तो पत्ता भाषांतरित करते ते विचारा। तिथे सहाय्यक जोडा, एका हस्तांतरणादरम्यान अपेक्षांची यादी पहा, नंतर सर्व्हरवर पॅसिव्ह मोड दुरुस्त करा आणि गेटवे नियमात श्रेणी प्रतिबिंबित करा।
डेटा-मार्गातील अपयश व मोठ्या हस्तांतरणातील अपयश वेगळे ठेवा, कारण ते तुम्हाला वेगवेगळ्या सेटिंग्जकडे नेतात।