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 और फ़िल्टरिंग की एक परत हटा देता है, जो अक्सर सस्ता निर्णय है।