PPTP कनेक्ट होता है और फिर Linux NAT के पीछे अटक जाता है: GRE हेल्पर

कोई 1723 फ़ॉरवर्ड करता है, क्लाइंट सर्वर तक पहुँचता है, प्रमाणीकरण शुरू होता है, और फिर सब कुछ बिना किसी त्रुटि के रुक जाता है। स्वाभाविक निष्कर्ष गलत पासवर्ड है, इसलिए पासवर्ड तीन बार दोबारा टाइप किया जाता है। फ़ॉरवर्ड ठीक था और क्रेडेंशियल ठीक थे। जो टूटा वह दूसरा प्रोटोकॉल है जिसे फ़ॉरवर्ड ने कभी कवर नहीं किया, और कर्नेल का एक डिफ़ॉल्ट जिसने चुपचाप उसमें मदद करना बंद कर दिया।

फ़ॉरवर्ड कभी समस्या नहीं था

पोर्ट-फ़ॉरवर्ड नियम TCP या UDP ट्रैफ़िक का वर्णन करता है। यह ऐसे पेलोड का वर्णन नहीं कर सकता जो सत्र के बीच में दूसरे IP प्रोटोकॉल पर चला जाता है, और PPTP ठीक यही करता है।

इसीलिए कनेक्शन अटकने के क्षण तक स्वस्थ दिखता है। पोर्ट नियम जिस हिस्से को नियंत्रित कर सकता है वह सफल रहा, और जिस हिस्से को नियंत्रित नहीं कर सकता वही विफल हिस्सा है।

नियंत्रण के लिए TCP, डेटा के लिए GRE

कॉल TCP 1723 पर बातचीत से तय होता है। एक बार बन जाने पर पेलोड GRE में चला जाता है, IP प्रोटोकॉल 47, जो कोई पोर्ट संख्या नहीं ले जाता। पोर्ट पर आधारित नियम के पास मिलाने के लिए कुछ नहीं है।

GRE जो ले जाता है वह उसके हेडर में कॉल पहचानकर्ता है, और NAT अनुवादक को उस फ़ील्ड को दोनों दिशाओं में लगातार फिर से लिखना होता है, वरना सत्र के दोनों आधे आपस में सहमत होना बंद कर देते हैं। एक दिशा फिर से लिखी गई और दूसरी नहीं, तो ऐसा सत्र बनता है जो प्रमाणीकरण करता है और फिर हर डेटा पैकेट फेंक देता है। लक्षण का आकार ठीक यही है: सफलता, फिर सन्नाटा।

PPTP के बिना नंगा GRE ऐसी फिर से लिखाई नहीं चाहता, इसलिए सादा GRE टनल उस राउटर से काम कर सकता है जो उसी रास्ते पर PPTP क्लाइंट के लिए विफल होता है।

चार मॉड्यूल और एक sysctl जिसने उन्हें बंद कर दिया

दो मॉड्यूल फ़्रेमिंग संभालते हैं, nf_conntrack_proto_gre और nf_nat_proto_gre। दो और कॉल पहचानकर्ता संभालते हैं, nf_conntrack_pptp और nf_nat_pptp। अंतिम को लोड करने से बाकी निर्भरताओं से आ जाते हैं, इसलिए मॉड्यूल सूची में चारों दिखने चाहिए।

पुराने निर्देश 2.6 युग का ip_ उपसर्ग इस्तेमाल करते हैं। वे कमांड कुछ लोड किए बिना चलते दिख सकते हैं, इसलिए एग्ज़िट स्थिति के बजाय लोड हुई सूची जाँचें।

उन्हें लोड किया हुआ होना अब पर्याप्त नहीं है। Linux 4.7 से net.netfilter.nf_conntrack_helper sysctl का डिफ़ॉल्ट 0 है, जो नए फ़्लो के लिए स्वचालित हेल्पर असाइनमेंट बंद कर देता है। राउटर में हर मॉड्यूल हो सकता है और फिर भी कुछ अनुवाद न हो। दोबारा मॉड्यूल सूची देखने से पहले प्रभावी मान जाँचें।

या तो स्वचालित असाइनमेंट फिर से वैश्विक रूप से चालू करें, या हेल्पर को उन फ़्लो से जोड़ें जिन्हें इसकी ज़रूरत है और बाकी सब कुछ वैसे ही रहने दें:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

दूसरा विकल्प बेहतर है। यह पूरे राउटर पर स्वचालित असाइनमेंट फिर से चालू करने के बजाय व्यवहार को PPTP ट्रैफ़िक तक सीमित करता है।

ऐसा प्रोटोकॉल खोलना जिसमें कोई पोर्ट नहीं है

1723 की अनुमति देने वाला फ़ायरवॉल नियम प्रोटोकॉल 47 के बारे में कुछ नहीं कहता। firewalld पर क्लाइंट की ओर वाले ज़ोन में प्रोटोकॉल की अनुमति दें। सादे iptables पर इनपुट चेन में gre प्रोटोकॉल स्वीकार करें।

फिर दोनों तरफ़ कैप्चर करें। क्लाइंट से जाते पैकेट का कोई जवाब न आना मतलब वापसी का रास्ता फ़िल्टर है, और यह अस्वीकृत क्रेडेंशियल से अलग खराबी है।

कनेक्ट होने के बाद आकार की सीमा

GRE हेडर जोड़ता है, और उसके अंदर का PPP और जोड़ता है, इसलिए काम करती लिंक 1500 से काफ़ी नीचे MTU बताती है। छोटे जवाब लोड होते हैं और बड़े अटक जाते हैं, जो पहली समस्या हल होते ही दिखने वाली दूसरी, असंबंधित समस्या जैसा लगता है।

क्लाइंट के PPP एडेप्टर पर MTU पढ़ें और उसे राउटर की अपनी गणना से मिलाएँ कुछ काम करने तक संख्याएँ घटाने के बजाय। पूरे आकार के पैकेट निकलकर कुछ वापस न आए तो वह अनुवाद की ओर नहीं, उस सीमा की ओर इशारा करता है।

रास्ता ठीक करने से उपयोगकर्ता काम पर लौटता है, और इससे PPTP अच्छा विकल्प नहीं बनता। MS-CHAPv2 और RC4 बहुत पहले से अप्रचलित हैं, इसलिए मॉड्यूल लोड करने को अस्थायी सुधार मानें और रखरखाव वाले प्रोटोकॉल की ओर जाने की योजना बनाएँ।