Docker मा PPTP प्रमाणीकरण हुन्छ तर कुनै ट्राफिक बोक्दैन

क्लाइन्ट प्रमाणीकरण गर्छ, PPP एउटा ठेगानामा सहमत हुन्छ, र त्यसपछि केही सर्दैन। Ping असफल हुन्छ, ब्राउजर असफल हुन्छ, र कन्टेनर सधैं जोडिएको देखिन्छ। यो ढाँचा राउटिङ तालिकाको समस्या होइन, किनकि राउटिङ समस्याले सामान्यतया नियन्त्रण जडान पनि तोड्छ। यो पेलोडको बाटो हो, र PPTP मा पेलोड भर्खरै सफल भएको प्रोटोकलभन्दा फरक प्रोटोकल हो।

पाँच जाँच, सबैभन्दा बढी समय बचत गर्ने क्रममा।

जाँच 1: नियन्त्रण च्यानल पेलोडबाट अलग गर्नुहोस्

PPTP ले TCP 1723 मा प्रमाणीकरण गर्छ र त्यसपछि PPP पेलोड GRE, IP प्रोटोकल 47 भित्र बोक्छ। GRE TCP पनि होइन र UDP पनि होइन, त्यसैले नियन्त्रण पोर्ट फर्वार्ड गर्ने हरेक नियम यसबारे केही भन्दैन। 1723 पास गर्ने NAT वा फायरवालले 47 प्रोटोकल बिना उजुरी फ्याँक्न सक्छ, र सत्र सफलता जस्तो देखिने तरिकामा आधा बनेको रहन्छ।

यदि लगइन काम गर्छ र कुनै प्याकेट फर्कंदैन भने, पहिले GRE मान्नुहोस् र त्यसपछि प्रमाणित गर्नुहोस्।

जाँच 2: होस्ट कर्नेलमा सहायक सुनिश्चित गर्नुहोस्

जडान ट्र्याकिङले सहायकबिना TCP नियन्त्रण जडानलाई GRE प्रवाहसँग जोड्न सक्दैन। मोड्युल nf_conntrack_pptp हो, यो होस्ट कर्नेलमा बस्छ, र कन्टेनर इमेजभित्र यसलाई लोड गर्दा केही हुँदैन किनकि मोड्युलहरू सम्पूर्ण होस्टमा लागू हुन्छन्। Docker होस्टमा lsmod | grep nf_conntrack_pptp नै जाँच हो। यदि यो छैन भने, modprobe nf_conntrack_pptp ले चलिरहेको कर्नेलका लागि यसलाई लोड गर्छ र अर्को बुटबारे केही भन्दैन, त्यसैले यसलाई होस्ट कन्फिगरेसनमा पनि थप्नुहोस्।

रिबुटमा हराउने मोड्युल अर्को महिना त्यही टिकट बन्छ।

जाँच 3: यसलाई बन्द गर्ने कर्नेल नीति पढ्नुहोस्

मोड्युल भए पनि, 4.7 देखि कर्नेलहरूले net.netfilter.nf_conntrack_helper लाई डिफल्ट रूपमा 0 मा राख्छन्, जसले हरेक प्रोटोकलका लागि स्वचालित सहायक असाइनमेन्ट बन्द गर्छ। यही डिफल्ट कारण हो कि सही रूपमा स्थापित मोड्युलले पनि केही गर्दैन: कोड छ र नीतिले यसलाई प्रयोग नगर्न भन्छ। sysctl net.netfilter.nf_conntrack_helper ले हालको मान रिपोर्ट गर्छ, र रनटाइममा यसलाई 1 मा सेट गर्दा सहायक फेरि उपलब्ध हुन्छ। डिजाइनले अनुमति दिन्छ भने होस्टको sysctl कन्फिगरेसनमार्फत मान कायम राख्नुहोस्।

स्वचालित असाइनमेन्टले ट्राफिकलाई अन्तर्निहित रूपमा अपेक्षाहरू सिर्जना गर्न दिन्छ, र डिफल्ट परिवर्तन हुनुको कारण ठ्याक्कै त्यही हो। यसलाई विश्वसनीय होस्टमा सीमित गर्नुहोस्, वा सहायकलाई लक्ष्य गर्ने स्पष्ट नियम प्रयोग गर्नुहोस्।

जाँच 4: कन्टेनरको बाटो छुट्टै हेर्नुहोस्

लोड गरिएको सहायकले कुनै मार्ग सिर्जना गर्दैन। कन्टेनरलाई PPTP सर्भरसम्म मार्ग चाहिन्छ, र होस्ट फर्वार्डिङले दुवै दिशामा GRE अनुमति दिनुपर्छ: iptables -L FORWARD -v -n ले 47 प्रोटोकल स्वीकार हुन्छ कि हुँदैन र काउन्टर सर्छन् कि सर्दैनन् देखाउँछ। Docker का masquerade नियमहरूले TCP र UDP अनुवाद गर्छन्, 47 प्रोटोकल होइन, त्यसैले ब्रिज कन्टेनरलाई स्पष्ट forward स्वीकृति र केही होस्टमा आफ्नै अनुवाद नियम चाहिन सक्छ। कन्टेनरसँग यसको इमेजले अपेक्षा गर्ने PPP उपकरण समर्थन छ भन्ने पनि पुष्टि गर्नुहोस्।

नियमको पाठ होइन, काउन्टर पढ्नुहोस्। अस्तित्वमा भए पनि कुनै कुरासँग नमिल्ने नियम सजावट हो।

जाँच 5: GRE ट्र्याक भइरहेको प्रमाणित गर्नुहोस्, त्यसपछि PPTP बारे निर्णय गर्नुहोस्

क्लाइन्ट चलिरहेको बेला ट्र्याकिङ तालिका पढ्नुहोस्। स्थापित PPTP नियन्त्रण प्रविष्टि र सम्बन्धित GRE प्रविष्टि भन्नु सहायकले प्रवाहहरू जोडिरहेको छ र बाँकी दोष अन्तै छ। GRE प्रविष्टिबिना नियन्त्रण प्रविष्टि भन्नु पेलोड फ्याँकिँदै छ वा ट्र्याक हुँदैन, जसले तपाईंलाई जाँच 2 र 3 मा फर्काउँछ।

PPTP आफैं पुरानो छ र MS-CHAPv2 कमजोर छ। सर्भरले L2TP/IPsec, IKEv2 वा WireGuard पनि दिन्छ भने, तीमध्ये एउटामा जाँदा यो सम्पूर्ण वर्गको समस्या हट्छ।

जहाँ PPTP रहनै पर्छ, त्यहाँ कन्टेनरभित्र होइन होस्टमा क्लाइएन्ट चलाउनु ले NAT र फिल्टरिङको एउटा तह हटाउँछ, जुन प्रायः सस्तो निर्णय हो।