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-ACK नपाउने SYN ले फायरवाल, गलत सर्भर ठेगाना वा पोर्ट फिल्टर गर्ने प्रदायकतर्फ संकेत गर्छ। ह्यान्डसेकपछि तुरुन्तै रिसेट आउनुको अर्थ प्रायः सर्भरले प्रमाणहरू वा टनेल प्रकार अस्वीकार गरेको हो।

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 जाने आधारमा निर्भर मार्ग ट्युन गर्नुभन्दा स्थानान्तरण गर्नु सामान्यतः समयको राम्रो उपयोग हो। पुरानो प्रोफाइल नयाँ संस्करणमा प्रतिलिपि गर्नुको सट्टा विकल्पको प्रमाणपत्र र प्रमाणीकरण सम्झौता जाँच्नुहोस्।