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 धेरै पहिले नै अप्रचलित भइसकेका छन्, त्यसैले मोड्युल लोड गर्ने कामलाई अस्थायी सुधार मान्नुहोस् र मर्मत गरिएको प्रोटोकलतर्फ जाने योजना बनाउनुहोस्।