एउटै राउटरको पछाडि किन एउटा मात्र VPN ग्राहक जोडिन्छ

दुई ल्यापटप एउटै घरायसी सञ्जालमा छन्, र कार्यालयको VPN ले तिनीहरूमध्ये ठ्याक्कै एउटा मात्र स्वीकार गर्छ। दोस्रोले या त समय सकिन्छ या पहिलो विच्छेद नभएसम्म पर्खन्छ, र दुई प्रयासबीच कसैले ग्राहकको सेटिङ छोएन। लगइन विवरण एक मिनेट अघि काम गरेकै हुन्, र यही प्रमाणीकरण विफलताको कारण होइन भन्ने सङ्केत हो। तीन संयन्त्रले यो ढाँचा बनाउँछन्, र तपाईं कुनसँग जुध्दै हुनुहुन्छ भनेर सर्भरको आफ्नै लगले बताउँछ।

ग्राहक छुनु अघि गेटवेको लग पढ्नुहोस्

दुई प्रयासको सर्भर अभिलेखले पहिलो प्रश्नको उत्तर दिन्छ, र तीनमध्ये एउटा तरिकाले उत्तर दिन्छ। दोस्रो प्रयास त्यो लगमा कहिल्यै नदेखिएमा प्याकेट स्रोतासम्म पुगेन, र समस्या घरायसी राउटर वा प्रदायकको मार्गको हो। लगले प्रयास अभिलेख गरेर अस्वीकार गरेमा सुरुङ पुगिसक्यो, अर्थात् कुरा पहिचान, इजाजतपत्र वा सत्र सीमाको हो, तारमा भएको कुनै कुराको होइन। लगले सफल सत्र अभिलेख गर्दा ग्राहकले अझै विफलता जनाइरहेको छ भने फर्कने मार्ग वा दुई ग्राहकलाई एउटै सुरुङ ठेगाना दिइएको छ कि छैन हेर्नुहोस्।

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

केही बदल्नु अघि नतिजा लेख्नुहोस्, किनकि लगका तीन नतिजा तीन असम्बन्धित मर्मतमा पुर्याउँछन्। तीनमध्ये कुन देख्नुभयो भनी लेखिएको टिप्पणी ग्राहक त्रुटिको स्क्रिनसटभन्दा बढी मूल्यवान् हुन्छ।

राउटरले GRE र NAT-T सँग के गर्छ

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

L2TP IPsec माथि डिजाइनअनुसार फरक व्यवहार गर्छ: IKE ले UDP 500 प्रयोग गर्छ, NAT पार गर्दा सुरक्षित पेलोड UDP 4500 मा सर्छ, र इन्क्याप्सुलेसन एउटै ठेगाना पछाडिका धेरै ग्राहकले एउटै गेटवेसम्म पुग्नकै लागि छ। त्यो डिजाइनले गेटवे वा बीचको बाकसले प्रत्येक ठेगानाका लागि सत्र सीमा लगाउनबाट रोक्दैन, र सोफाबाट दुवै विफलता उस्तै देखिन्छन्। SoftEther को आफ्नै प्रोटोकलमा पनि यही वर्गको समस्या छ: काम गर्ने पास-थ्रु नभएको राउटरले स्थानीय सञ्जालबाट पहिलो ग्राहक भित्र लिन्छ र दोस्रोलाई छोडिदिन्छ। राउटरको ALG वा पास-थ्रु स्विच दुवै अवस्थामा जाँच्नुहोस्, किनकि पुरानो ग्राहकका लागि लेखिएको सहायकले आजको ग्राहकले पठाउने प्याकेट बिगार्न सक्छ।

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

ढुवानी सीमाजस्तै देखिने पहिचान सीमा

राउटर मात्र शङ्कास्पद होइन, र लगले यसलाई विकल्पबाट छुट्याउँछ। OpenVPN सर्भरले साझा नाम एउटा सुरुङ ठेगानामा पिन गर्दा दुवै उपकरणले त्यो ठेगाना पाउँछन्, र duplicate-cn बिना नयाँ सत्रले पुरानोलाई बाहिर धकेल्छ। त्यो विकल्प सक्रिय गर्दा दुवै जोडिएका रहन्छन् तर एउटै पहिचान, एउटै प्रमाणपत्र र एउटै रद्द गर्ने निर्णयमा रहन्छन्, जो देखिनेभन्दा नराम्रो हो। त्यसपछि दोस्रो उपकरण एक्लै कहिल्यै रद्द गर्न सकिँदैन, त्यसैले सुविधाको स्विचले पछि आवश्यक पर्न सक्ने नियन्त्रण चुपचाप हटाउँछ।

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

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

मर्मतलाई लग प्रविष्टिसँग मिलाउनुहोस्

लगमा अस्वीकार भएमा प्रत्येक उपकरणका लागि छुट्टै लगइन विवरण, सेवा चलाउनेबाट बढी सीमा, वा एउटा मेसिनका लागि दोस्रो गेटवे अन्त्यबिन्दु आवश्यक पर्छ। कुनै दोस्रो प्रयास कहिल्यै सर्भरसम्म नपुगेमा दिगो मर्मत प्रोटोकल फर्वार्ड गर्ने र एकभन्दा बढी सत्र राख्ने राउटर, वा राउटरले राम्ररी सम्हाल्ने ढुवानी, जस्तै एउटै TCP वा UDP प्रवाह हो। तीमध्ये छान्नु हार्डवेयरको आयुको निर्णय हो, ग्राहक सेटिङको होइन।

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

दुई जीवित सत्रको प्रमाणीकरण

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

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