PPTP त्रुटि 800 र 812 अनि एक मिनेटपछिको जडान विच्छेद

त्रुटि 800, त्रुटि 812 र एक मिनेटपछि मर्ने PPTP टनेल तीन फरक खराबी हुन्। प्रत्येक लक्षणलाई साँच्चै असफल भएको तहसँग जोड्नुहोस्।

एउटै PPTP क्लाइन्टका तीन त्रुटि सन्देशले सामान्यतया तीन फरक खराबी वर्णन गर्छन्। त्रुटि 800 भन्नाले टनेल कहिल्यै बनेन, त्रुटि 812 भन्नाले सर्भरले प्रमाणीकरण विधि अस्वीकार गर्यो, र एक मिनेटपछिको विच्छेद भनेको स्वस्थ साथी गएको ठहर गर्ने keepalive टाइमर हो। प्रत्येक चरण आफ्नै कारणले असफल हुन्छ, त्यसैले प्रत्येकलाई आफ्नै जाँच चाहिन्छ।

त्रुटि 800 भन्नाले टनेल कहिल्यै बनेन

Windows ले त्रुटि 800 तब देखाउँछ जब यो टनेल नै बनाउन सक्दैन, र पहुँच नहुने सर्भर वा अनुपयुक्त सुरक्षा प्यारामिटरबारेको पाठ निदान नभई सारांश हो। PPTP लाई कुनै पनि प्रमाण जाँच्नुअघि नेटवर्कबाट दुई छुट्टै कुरा चाहिन्छ। TCP 1723 ले नियन्त्रण च्यानल बोक्छ, र IP प्रोटोकल 47, अर्थात् GRE, ले ईन्क्याप्सुलेट गरिएको पेलोड बोक्छ।

त्यो बाह्य मार्ग आफ्नै LAN बाहिरबाट परीक्षण गर्नुहोस्, किनकि अफिसभित्र चल्ने जडानले किनारबारे केही प्रमाणित गर्दैन:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

यदि 1723 ले जवाफ दिन्छ र क्लाइन्ट जोडिन खोज्दा क्याप्चर खाली रहन्छ भने, मार्गले प्रोटोकल 47 छोड्दै छ। 1723 फर्वार्ड गरिएको तर PPTP पासथ्रु बन्द भएको राउटरले ठ्याक्कै त्यही ढाँचा दिन्छ: TCP ह्यान्डशेक पूरा हुन्छ, त्यसपछि GRE प्याकेट अदृश्य हुन्छन्, त्यसैले असफलता प्रमाणको समस्या जस्तो देखिन्छ, तर कुनै लगइन प्रयास भएको थिएन।

फर्वार्डिङ सर्भरको हालको LAN ठेगानातर्फ मोड्नुहोस्, राउटरले दिने ठाउँमा PPTP पासथ्रु सक्रिय गर्नुहोस्, र त्यही बाह्य स्थानबाट फेरि प्रयास गर्नुहोस्। GRE माथि फिल्टर हुन्छ र तपाईंले त्यो बदल्न सक्नुहुन्न भने, TCP 443 माथिको SSTP वा UDP 500 र 4500 माथिको L2TP/IPsec लाई Windows पट्टि तपाईंले गर्न सक्ने कुनै पनि परिवर्तनभन्दा राम्रो सम्भावना छ।

त्रुटि 812 भन्नाले सर्भरले तपाईंको प्रमाणीकरण विधि अस्वीकार गर्दै छ

टनेल माथि आएपछि त्रुटि 812 फर्कन्छ, त्यसैले यो पासवर्डको समस्या जस्तो लाग्छ। सर्भरले जडानका लागि तय भएको प्रमाणीकरण विधि अस्वीकार गर्छ, पासवर्ड आफैंलाई हुनैपर्ने होइन। क्लाइन्टमा VPN प्रविष्टि खोल्नुहोस्, सुरक्षा ट्याबमा जानुहोस्, प्रकार Point-to-Point Tunneling Protocol मा राख्नुहोस्, स्पष्ट प्रोटोकल सूची छान्नुहोस् र Microsoft CHAP संस्करण 2 मा टिक लगाउनुहोस्।

संवादमा क्लिक नगरी हालको सेटिङ पढ्न सक्नुहुन्छ:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

MS-CHAP v2 चाहिने सर्भरले PAP मा वा कमजोर कुरामा वार्ता गर्ने स्वचालित प्रकारमा छोडिएको क्लाइन्टलाई अस्वीकार गर्छ, र कुनै पनि प्रयोगकर्ता पासवर्ड मूल्याङ्कन हुनुअघि त्रुटि आउँछ। खाता ढाँचा त्यही अस्वीकारको अर्को आधा हो। एउटा घटनामा Windows ले MicrosoftAccount\[email protected] आकारको Microsoft खाता पहिचान पठायो, तर सर्भर स्थानीय वा डोमेन खाता चाहन्थ्यो। SERVERNAME\username टाइप गर्दा Windows लाई कुन खाता भण्डारसँग सल्लाह लिने भनियो र त्रुटि हट्यो। नाम हातैले हाल्नुहोस्, सुरक्षित प्रमाणलाई अघिल्लो ढाँचा दोहोर्याउन नदिनुहोस्।

एक मिनेटपछिको विच्छेद keepalive निर्णय हो

टनेल जोडिएपछि अलिअलि ट्राफिक जान दिन्छ र त्यसपछि विच्छेद हुन्छ, क्लाइन्ट छुनुअघि सर्भरको LCP प्रतिध्वनि व्यवहार हेर्नुहोस्। डिमनले साथीलाई अझै छ कि भनी पुष्टि गर्न आवधिक रूपमा भन्छ। तोकिएको बजेटभित्र धेरै कम जवाफ आए, प्रयोगकर्तासँग अझै चल्ने लिङ्क भए पनि सत्र भत्काइन्छ।

Linux pptpd सर्भरमा ती मान /etc/ppp/options.pptpd मा रहन्छन्, र सामान्य मर्मत अन्तराल छोट्याउनु नभई बजेट फराकिलो बनाउनु हो:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

पाँच सेकेन्डको अन्तरालमा तीस चुकले छोटो रोकावटलाई माफ गर्छ, साथीलाई गयो भनी घोषणा गर्नुभन्दा। संख्या एक वा दुई बनाउँदा अनुवादित मार्गको सामान्य जिटर लगभग हरेक मिनेटमा विच्छेद बन्छ। यदि तपाईंको सर्भर pptpd होइन Windows RRAS हो भने, यसको सट्टा PPP सत्रको समयसीमा र निष्क्रियतामा विच्छेद नीति हेर्नुहोस्। ती अर्कै ठाउँमा रहन्छन्, र नभएको pppd फाइल सम्पादन गर्दा केही बदलिँदैन।

ओभरल्यापिङ सबनेटले डेटा मार्ग तोड्छन्

PPTP टनेल सफा रूपमा प्रमाणीकरण भएर पनि कतै नपुग्न सक्छ, जब दुवै साइटले एउटै निजी दायरा प्रयोग गर्छन्, उदाहरणका लागि अफिस र घरमा 192.168.1.0/24. क्लाइन्टले दिइएको ठेगानाले कुन होस्टलाई जनाउँछ भन्न सक्दैन, र केही स्ट्याकले एउटा छान्नुभन्दा मार्ग स्थापना गर्नै अस्वीकार गर्छन्।

यसलाई डिजाइन दोष मान्नुहोस् र एउटा पट्टि पुनः क्रमांकन गर्नुहोस्, वा क्लाइन्टलाई जानाजान अनुवादित पहुँच दायरा दिनुहोस्। PPTP क्लाइन्ट डिबग गर्दा दुई पटक अस्तित्वमा रहेको ठेगाना ठाउँ सुधार्न सकिँदैन, र लक्षण अनियमित विच्छेद जस्तै देखिइरहनेछ।

असफल भएको चरणबाट सुरु गर्नुहोस्: 800 का लागि GRE, 812 का लागि विधि र खाता स्ट्रिङ, तालिकाअनुसार मर्ने टनेलका लागि प्रतिध्वनि सेटिङ।

सम्बन्धित लेखहरू