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 आणि फिल्टरिंगचा एक थर दूर करते, जे अनेकदा स्वस्त निर्णय असते।