घरच्या राउटरमागे 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 बाइट खाते। 1492 वर संपणाऱ्या PPPoE WAN वर बसणारे सर्वात मोठे 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 नियम ठेवतो याची खात्री करा। एक फाइल प्रत पार करून पुढील फर्मवेअर अद्ययावतानंतर मरणारे टनेल कधीच पूर्ण झाले नव्हते।