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