PPTP स्प्लिट टनलिंग काम नहीं कर रही: पहले GRE पथ ठीक करें

PPTP कनेक्शन को ऊपर आते देखें और यह मानना आसान है कि कठिन हिस्सा पूरा हो गया: क्लाइंट प्रमाणीकरण करता है, ppp0 एडाप्टर या WAN Miniport दिखाई देता है, और स्थिति विंडो हरी हो जाती है। फिर किसी आंतरिक होस्ट के लिए पहला अनुरोध समय-सीमा पार कर जाता है, और प्रोफ़ाइल को दोष दिया जाता है। व्यवहार में दो स्वतंत्र परतें साफ़ करनी होती हैं: बाहरी परिवहन जो TCP 1723 और GRE ले जाता है, और भीतरी नीति जो तय करती है कि कौन-से गंतव्य PPP इंटरफ़ेस का उपयोग करते हैं। हरी स्थिति केवल यह सिद्ध करती है कि पहली परत ने बातचीत की; दूसरी के बारे में यह कुछ नहीं कहती।

प्रोफ़ाइल से नियंत्रण सॉकेट तक क्लाइंट का पीछा करें

क्लाइंट लॉग खोलें और वह बिंदु खोजें जहाँ वह सर्वर से संपर्क करता है। PPTP पहले पोर्ट 1723 पर TCP कनेक्शन खोलता है और उसी चैनल पर टनल पैरामीटर पर बातचीत करता है। यदि यह चरण विफल हो, तो आगे कुछ भी मायने नहीं रखता, और त्रुटि सामान्यतः सर्वर पता या समय-सीमा बताती है।

किसी भी मार्ग को छूने से पहले तार पर नियंत्रण कनेक्शन की पुष्टि करें। क्लाइंट पर या मिरर पोर्ट पर, एक कनेक्शन प्रयास के लिए TCP 1723 कैप्चर करें:

sudo tcpdump -ni any 'tcp port 1723' -c 20

पूरा हुआ हैंडशेक और स्थापित सत्र का अर्थ है कि बाहरी नियंत्रण चैनल काम कर रहा है। जो SYN कभी SYN-ACK नहीं पाता वह फ़ायरवॉल, गलत सर्वर पता, या पोर्ट फ़िल्टर करने वाले प्रदाता की ओर संकेत करता है। हैंडशेक के तुरंत बाद रीसेट आना अक्सर इसका अर्थ है कि सर्वर ने क्रेडेंशियल या टनल प्रकार अस्वीकार कर दिया।

GRE दूसरा प्रोटोकॉल है, पोर्ट नहीं

PPTP, PPP पेलोड को विस्तारित GRE, IP प्रोटोकॉल 47 के भीतर ले जाता है, जिसका कोई पोर्ट नंबर नहीं है जिसे राउटर ट्रैक कर सके। इसलिए TCP 1723 की अनुमति देने वाला नियम भी टनल को डेटा पथ के बिना छोड़ सकता है। स्टेटफुल NAT उपकरणों को उत्तरों को वापस मैप करने के लिए GRE के भीतर कॉल ID समझना होता है, और बहुत से ऐसा नहीं करते। PPTP विनिर्देश नियंत्रण चैनल और GRE पेलोड को अलग भागों के रूप में रखता है, और आपकी परीक्षण योजना को भी ऐसा ही करना चाहिए।

उसी कैप्चर में प्रोटोकॉल 47 देखें, फिर जो बाहर जाता है उसकी जो वापस आता है उससे तुलना करें:

sudo tcpdump -ni any 'proto gre' -c 20

जो पैकेट उत्तर के बिना बाहर जाते हैं, जबकि TCP 1723 स्वस्थ रहता है, वे अवरुद्ध-GRE का उत्कृष्ट संकेत हैं। उपभोक्ता राउटर पर PPTP पासथ्रू उस विशिष्ट फ़र्मवेयर की विशेषता है, इसलिए काम करने वाला होटल नेटवर्क अगले के बारे में कुछ सिद्ध नहीं करता। यदि राउटर कोई पासथ्रू नहीं देता और आप उसे बदल नहीं सकते, तो समस्या रूट तालिका नहीं, प्रोटोकॉल का चयन है।

सिद्ध करें कि टनल एक पैकेट चलाती है

जैसे ही GRE बहता है, PPP बातचीत क्लाइंट इंटरफ़ेस को एक पता सौंपती है। मानने के बजाय आवंटन पढ़ें:

ip -4 addr show ppp0

पॉइंट-टू-पॉइंट लिंक के गंतव्य के रूप में दिखाए गए पीयर पते पर पिंग करें। इस चरण पर उत्तर सिद्ध करता है कि एनकैप्सुलेटेड पथ शुरू से अंत तक काम करता है और सर्वर टनल के भीतर उत्तर देता है। यदि पीयर उत्तर देता है पर आंतरिक होस्ट नहीं, तो बाहरी परिवहन ठीक है और विफलता भीतर चली गई है।

कोई भी स्प्लिट रूट जोड़ने से पहले यह करें। परिवहन टूटा होने पर किया गया रूट परिवर्तन दूसरा चर बनाता है और पहले को छिपा देता है।

स्प्लिट नीति लिखें, DNS सहित

स्प्लिट रूटिंग निर्णयों की सूची है, चेकबॉक्स नहीं। हर निजी प्रीफ़िक्स जिसे टनल पार करनी है, उसे PPP इंटरफ़ेस से होकर मार्ग चाहिए, और हर प्रीफ़िक्स जिसे स्थानीय रहना है, उसमें अनुपस्थित होना चाहिए। किसी एप्लिकेशन सबनेट के लिए उसके निजी रिज़ॉल्वर तक मेल खाते मार्ग के बिना मार्ग बनाना, टूटे ऐप जैसा दिखने वाला व्यवधान पैदा करने का आम तरीका है।

हर श्रेणी में एक पते के लिए कर्नेल जो निर्णय लेता है, उसकी जाँच करें:

ip route get 10.20.5.10
ip route get 203.0.113.25

पहले को ppp0 और दूसरे को सामान्य गेटवे बताना चाहिए। यदि दोनों एक ही इंटरफ़ेस बताते हैं, तो नीति बिल्कुल स्प्लिट नहीं है। DNS सर्वर का अपना पता टनल सूची में जोड़ें, अन्यथा आंतरिक होस्ट के लिए नाम समाधान स्थानीय रिज़ॉल्वर से बाहर जाता है और कुछ काम का नहीं लौटाता।

पाँच चरणों में दोहराने योग्य जाँच

परतों को क्रम में चलाएँ और पहली विफल परत पर रुकें: नियंत्रण चैनल, GRE दृश्यता, PPP पीयर उत्तर, एक आंतरिक पते के लिए स्प्लिट रूट, और टनल पर एक एप्लिकेशन अनुरोध। हर चरण का अपना कमांड है, इसलिए विफलता रहस्यमय नहीं बल्कि निर्धारित की जा सकती है।

Linux क्लाइंट के लिए संक्षिप्त संस्करण ऐसा दिखता है:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

Windows में वही क्रम route print और क्लाइंट में दिखाई देने वाली एडाप्टर स्थिति के साथ लागू होता है। PPTP पुराना प्रोटोकॉल है, और यदि सर्वर SSTP या IKEv2 देता है, तो हर हॉप पर प्रोटोकॉल 47 के गुजरने पर निर्भर मार्ग को ट्यून करने से बेहतर आम तौर पर स्थानांतरित होना है। पुरानी प्रोफ़ाइल को नए संस्करण में कॉपी करने के बजाय प्रतिस्थापन का प्रमाणपत्र और प्रमाणीकरण अनुबंध जाँचें।