घरेलू राउटर के पीछे PPTP सर्वर: पहले 1723 और GRE ठीक करें
घरेलू राउटर के पीछे PPTP चलाएँ: TCP 1723, IP प्रोटोकॉल 47, पासथ्रू चेकबॉक्स और MTU का गणित, और कब L2TP या OpenVPN बेहतर सौदा है।
घरेलू राउटर के पीछे PPTP दो असंबंधित तरीकों से विफल होता है, और इन्हें मिलाना पूरी शाम बर्बाद कर देता है। एक विफलता फ़ॉरवर्डिंग का अंतराल है: राउटर TCP 1723 पार करता है और IP प्रोटोकॉल 47 गिरा देता है, इसलिए क्लाइंट त्रुटि 619 पर अटक जाता है। दूसरी आकार की समस्या है: टनल ऊपर आता है, प्रमाणित होता है, और फिर पूरे आकार का पैकेट पार होते समय जम जाता है। यह पता लगाना कि आपके पास इनमें से कौन है, पहला असली कदम है; बाकी इस बात की तुलना करता है कि आपका राउटर क्या व्यक्त कर सकता है, यह नहीं कि कौन सा ब्रांड बेहतर है।
दो वाहक, और उनमें से केवल एक के पास पोर्ट है
PPTP दो वाहकों में बँटता है: TCP 1723 पर एक नियंत्रण कनेक्शन, और बढ़े हुए GRE में लिपटे PPP फ़्रेम, जो IP प्रोटोकॉल 47 है। GRE के पास पोर्ट नंबर नहीं है, इसलिए पोर्ट 1723 फ़ॉरवर्ड के रूप में लिखा गया नियम उसे कवर नहीं कर सकता, चाहे वेब इंटरफ़ेस उस फ़ील्ड को कुछ भी कहे। उपभोक्ता राउटर आमतौर पर प्रोटोकॉल नियम के बजाय PPTP पासथ्रू नाम का चेकबॉक्स देता है, और वह चेकबॉक्स दो काम करता है: यह प्रोटोकॉल 47 को फ़ायरवॉल से पार जाने देता है और NAT को GRE प्रवाह ट्रैक करना सिखाता है। लिनक्स राउटर पर वे काम अलग मॉड्यूल और अलग नियम हैं, इसलिए आधा कॉन्फ़िगर किया गया पासथ्रू फिर भी काम करने वाला नियंत्रण चैनल देता है। कुछ भी बदलने से पहले पता करें कि कौन सा आधा मौजूद है।
सर्वर के अपने फ़ायरवॉल को भी राउटर के पते से प्रोटोकॉल 47 की अनुमति देनी चाहिए। जो होस्ट फ़ायरवॉल केवल 1723/tcp स्वीकार करता है वह LAN के भीतर से त्रुटि 619 फिर से पैदा करता है, जिससे टूटी फ़ॉरवर्डिंग और टूटा होस्ट नियम एक जैसे दिखते हैं।
sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'अगर मॉड्यूल नहीं हैं, तो उन्हें sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre से लोड करें और लोडिंग को स्थायी बनाएँ, क्योंकि सहायक को भूलने वाला रीबूट काम करने वाले टनल को फिर त्रुटि 619 में बदल देता है। फ़ॉरवर्डिंग नियम को केवल सर्वर के पते की ओर प्रोटोकॉल 47 स्वीकार करना चाहिए, पूरा LAN नहीं। RFC 2637 की परिभाषा नियंत्रण और डेटा पथ को अलग करती है, इसलिए कोई भी एकल पोर्ट फ़ॉरवर्ड स्क्रीन PPTP का पूरा वर्णन नहीं करती।
पासथ्रू चेकबॉक्स या स्पष्ट प्रोटोकॉल नियम
केवल फ़ायरवॉल खोलने वाला पासथ्रू चेकबॉक्स कॉल पहचानकर्ता फिर से लिखने वाले ALG की तुलना में सही के अधिक निकट है। फ़ायरवॉल वाला आधा हिस्सा अनुमानित है, क्योंकि प्रोटोकॉल 47 या तो स्वीकार होता है या गिरा दिया जाता है, और काउंटर बताते हैं कौन सा। फिर से लिखने वाला आधा वह जगह है जहाँ निर्माता अलग होते हैं, क्योंकि PPTP के कॉल पहचानकर्ता प्रति टनल होते हैं और उन्हें संपादित करने वाले NAT को अपने छुए हर कॉल का पीछा करना पड़ता है। जब एक क्लाइंट जुड़ता है और दो नहीं, तो ALG पहला संदिग्ध है।
1723 के लिए गंतव्य NAT नियम में भी स्वामित्व की समस्या है। अगर पुराना नियम अभी भी 1723 उस होस्ट पर भेजता है जिसने सर्वर चलाना बंद कर दिया है, तो पैकेट बंद पोर्ट पर गिरते हैं और राउटर की अपनी PPTP सेवा जवाब देना बंद कर देती है, जो फ़ायरवॉल विफलता जैसा पढ़ा जाता है पर वास्तव में पुराना लक्ष्य है। दूसरा जोड़ने से पहले नियम और उसका गंतव्य पढ़ें। जो राउटर स्वयं PPTP समाप्त करते हैं, वहाँ WAN नियम अंतर्निहित सेवा से प्रतिस्पर्धा करता है, इसलिए 1723 और प्रोटोकॉल 47 के लिए एक ही स्वामी चुनें।
एक ही NAT के पीछे दो क्लाइंट वह मामला है जो साधारण फ़ॉरवर्डिंग को चतुर फ़ॉरवर्डिंग से अलग करता है। कॉल पहचानकर्ता फिर से लिखे बिना प्रोटोकॉल 47 फ़ॉरवर्ड करना आमतौर पर उन्हें ठीक करने की कोशिश करने वाले सहायक से बेहतर व्यवहार करता है।
राउटर को दोष देने से पहले टनल नापें
PPTP उपयोगी पेलोड घटाता है, और यह कमी गणित है, कोई रहस्य नहीं। हर टनल पैकेट एक बाहरी IP हेडर, बढ़ा हुआ GRE हेडर, PPP हेडर और एन्क्रिप्शन के साथ MPPE हेडर ले जाता है। जब पथ परिणामी फ़्रेम नहीं ले जा सकता, छोटे पैकेट पार हो जाते हैं, लॉगिन पूरा होता है, और सत्र पहली बार तब रुकता है जब फ़ाइल स्थानांतरण या TLS हैंडशेक पूरे आकार का पैकेट भेजता है।
अनुमान लगाने के बजाय संख्या निकालें। बढ़े हुए GRE का 8 बाइट खर्च है, PPP का 4, MPPE का 4, और बाहरी IP हेडर का 20, इसलिए टनल किसी भी पेलोड से पहले 36 बाइट खा जाता है। जो PPPoE WAN 1492 पर समाप्त होता है, उस पर सबसे बड़ा PPP MTU जो बैठता है वह 1492 घटा 36 है, यानी 1456। PPP विकल्पों में mtu और mru को उस मान पर सेट करें और विखंडन रहित पिंग से फिर परीक्षण करें।
ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpdपिंग पथ नापता है, टनल नहीं: 1464 बाइट पेलोड और 28 बाइट IP तथा ICMP हेडर मिलकर 1492 बाइट का फ़्रेम ठीक से भरते हैं। अगर वह पिंग विफल हो, तो संख्या तब तक घटाएँ जब तक वह पार न हो जाए, फिर परिणाम से 36 घटाएँ। पथ की सीमा से ऊपर सेट किया गया टनल MTU आकार का उल्लेख करने वाली किसी भी लॉग पंक्ति के बिना जमना पैदा करता है।
एक ही राउटर पर PPTP, L2TP/IPsec या OpenVPN
एक ही राउटर तीन सामान्य टनलों में से कोई भी ले जा सकता है, और अंतर यह है कि उसे क्या व्यक्त करना है। PPTP को दो अलग परतों में दो नियम चाहिए। IPsec के ऊपर L2TP को कुंजी अदला-बदली के लिए UDP 500 और 4500 चाहिए और अगर NAT-T उसे नहीं ले जाता तो पेलोड के लिए प्रोटोकॉल 50। OpenVPN को एक UDP पोर्ट चाहिए और कोई सहायक नहीं।
| Tunnel | What the router must allow | Practical note |
|---|---|---|
| PPTP | TCP 1723 and IP protocol 47 | Two transports, two rules |
| L2TP/IPsec | UDP 500, UDP 4500, protocol 50 without NAT-T | ESP has no port either |
| OpenVPN | UDP 1194 or a chosen TCP port | Single rule, no helper |
L2TP का स्तंभ स्वतः GRE से अधिक मैत्रीपूर्ण नहीं है। ESP IP प्रोटोकॉल 50 है और उसका भी पोर्ट नहीं है, इसलिए जो राउटर प्रोटोकॉल 47 से जूझता है वह उसी कारण प्रोटोकॉल 50 से भी जूझ सकता है। NAT-T ESP को UDP 4500 के भीतर लपेटने के लिए है, और जब दोनों सिरे इसका समर्थन करते हैं तो प्रोटोकॉल 50 का नियम अनावश्यक हो जाता है। यह सिरों का गुण है, राउटर के PPTP चेकबॉक्स का नहीं। दोनों के लिए नियम लिखने से पहले पुष्टि करें कि क्लाइंट ने वास्तव में कौन सा एनकैप्सुलेशन तय किया है।
OpenVPN राउटर की ओर सबसे कम चलते भागों वाला विकल्प है। एक UDP पोर्ट, एक फ़ॉरवर्डिंग, कोई कनेक्शन-ट्रैकिंग सहायक नहीं और कॉल पहचानकर्ता का कोई पुनर्लेखन नहीं। सौदा यह है कि अंतर्निहित डायलर के बजाय इंस्टॉल करने योग्य क्लाइंट चाहिए, और अक्सर यही एकमात्र कारण है कि PPTP बातचीत में बना रहता है।
क्या मरम्मत करें और क्या बदलें
फ़ॉरवर्डिंग और MTU ठीक करने से आपको काम करने वाला टनल मिलता है, रखने योग्य नहीं। PPTP का MSCHAPv2 प्रमाणीकरण वर्षों से हमले योग्य है, और काम करने वाला टनल ऐसे क्रेडेंशियल ले जाता है जिन्हें ऑफ़लाइन वापस पाया जा सकता है। अगर दूर का उपकरण L2TP/IPsec या OpenVPN चला सकता है, तो मरम्मत को तारीख वाला अस्थायी उपाय मानें।
निर्णय इस पर आता है कि दूर का सिरा क्या समर्थन करता है और व्यवस्था को कितने समय टिकना है। जो पुराना उपकरण केवल PPTP बोलता है उसे मरम्मत मिलती है; जिस पर क्लाइंट इंस्टॉल हो सकता है वह स्थानांतरित होता है।
टिकट बंद करने से पहले पुष्टि करें कि क्लाइंट लॉगिन नहीं बल्कि बड़ा स्थानांतरण सह लेता है, और रीबूट के बाद भी राउटर अपना प्रोटोकॉल 47 नियम रखता है। जो टनल एक फ़ाइल कॉपी पार करता है और अगले फ़र्मवेयर अपडेट के बाद मर जाता है, वह कभी पूरा नहीं हुआ था।