घरायसी राउटरको पछाडि 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 नियम राख्छ भनी पुष्टि गर्नुहोस्। एउटा फाइल प्रतिलिपि पार गरेर अर्को फर्मवेयर अद्यावधिकपछि मर्ने टनेल कहिल्यै पूरा भएको थिएन।