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 जाण्यावर अवलंबून असलेला मार्ग ट्यून करण्यापेक्षा स्थलांतर करणे सामान्यतः वेळेचा चांगला वापर आहे। जुनी प्रोफाइल नव्या आवृत्तीत कॉपी करण्याऐवजी पर्यायाचे प्रमाणपत्र आणि प्रमाणीकरण करार तपासा।