साझा VPN खाताको सत्र सीमा: एउटा यन्त्र किन खस्छ

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

सञ्जाल छुनुअघि ग्राहकको सन्देश पढ्नुहोस्

तीन विफलता उस्तै देखिन्छन् र हुँदैनन्। समयसीमा भन्नाले तपाईंका प्याकेट कतै पुगेनन्। TLS वा प्रमाणपत्र त्रुटि भन्नाले अन्त्य बिन्दुले जवाफ दियो तर हात मिलाउन असफल भयो। प्रमाणीकरण वा नीति अस्वीकृति भन्नाले गेटवेले तपाईंको विवरण पढ्यो र त्यसपछि अस्वीकार गर्‍यो। तेस्रो मात्र सत्र-सीमाको कथासँग सम्बन्धित छ, त्यसैले पहिले त्यही निश्चित गर्नुहोस्।

OpenVPN ग्राहकहरू महत्त्वपूर्ण लाइनहरू आफ्नो लग प्यानलमा राख्छन्। त्यसपछि आउने पुनः प्रयास चक्रमा नभई अन्तिम जडान प्रयासमा स्क्रोल गर्नुहोस्, र AUTH_FAILED वा पठाइएको कारण-स्ट्रिङ खोज्नुहोस्। ग्राहकले प्रायः व्याख्याविना सामान्य अस्वीकृति जनाउँछ, त्यसैले अर्को कदम सर्भर हो, ग्राहकको सेटिङ होइन। प्रदायकका एपहरू अझ नराम्रा छन्: यन्त्र-सीमाको सन्देश उपयोगी छ, तर दुई सेकेन्डपछि भत्किने जडान नीति-निर्णय हो, खराब पासवर्ड होइन। जे भए पनि यन्त्रको नाम र ठ्याक्कै समय लेख्नुहोस्; अपरेटरले त्यो जोडीलाई सेकेन्डमै पहुँच-रेकर्डसँग मिलाउन सक्छ।

सत्रहरू त्यहाँ गन्नुहोस् जहाँ सर्भरले गन्छ

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

cat /var/log/openvpn-status.log
# or query the management socket directly
echo "status 2" | socat - UNIX-CONNECT:/run/openvpn/server.sock

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

WireGuardसँग जाँच्ने सत्र तालिका छैन। wg show wg0 साथीहरू र तिनीहरूको पछिल्लो हात मिलाउने छाप्छ, र प्रत्येक दर्ता भएको यन्त्र आफ्नै कुञ्जीसहितको साथी हो। त्यहाँको साझा खाता धेरै मेसिनमा प्रतिलिपि गरिएको कन्फिग फाइल हो, र सीमा ती कन्फिग बाँड्नेबाट आउँछ: प्रदायकको पोर्टल, सिट संख्या, वा तपाईंको सार्वजनिक ठेगानासँग बाँधिएको नियम। तपाईं आफैं गेटवे चलाउनुहुन्छ भने OpenVPN 2.6 म्यानुअल ले सर्भर-पक्षका विकल्पहरू अभिलेख गर्छ।

एउटा सन्देशपछि लुकेका चार सीमा छुट्याउनुहोस्

अधिकांश साझा-खाता टिकटहरू चार प्रवेश-निर्णयमध्ये एक हुन्। ग्राहकले तिनलाई छुट्याउन सक्दैन, तर कुन यन्त्र विफल हुन्छ भन्ने ढाँचाले सक्छ।

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

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

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

सम्पूर्ण सर्भरको अधिकतम। गेटवेका सबै उही व्यस्त घण्टामा विफल हुन्छन्, हिजो ठीक भएका खाताहरू पनि। OpenVPNको --max-clients यसै गरी व्यवहार गर्छ, र यसको तपाईंका दर्ता भएका यन्त्रसँग कुनै सम्बन्ध छैन।

थप सिट किन्नुअघि पुराना सत्र सफा गर्नुहोस्

नराम्ररी टुंगिएको सत्रले अझै ठाउँ ओगट्न सक्छ। सत्र सुरु हुँदा RADIUS लेखाले रेकर्ड लेख्छ र सत्र रोकिँदा त्यो बन्द गर्छ; ग्राहक हराएपछि रोकिने कुरा कहिल्यै आउँदैन र सर्भर अन्तरिम अद्यावधिक वा समयसीमा सकिएसम्म सत्र राख्छ। FreeRADIUS गेटवेमा तपाईं खुला रेकर्डहरू देख्न सक्नुहुन्छ:

SELECT username, acctsessionid, acctstarttime
FROM radacct WHERE acctstoptime IS NULL;

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

सँगै चल्ने यन्त्रहरूबीच एउटै पहिचान साझा गर्न रोक्नुहोस्

दिगो समाधान संरचनागत हो। प्रत्येक यन्त्रलाई अद्वितीय साझा नामसहित आफ्नै प्रमाणपत्र, वा आफ्नै खाता दिनुहोस्, र कुन व्यक्ति र कुन मेसिनले राख्छ लेख्नुहोस्। OpenVPNमा यसको अर्थ प्रति यन्त्र एक ग्राहक प्रमाणपत्र, र कब्जा-व्यवहार नचाहेसम्म --duplicate-cn बन्द; WireGuardमा प्रति यन्त्र एक कुञ्जी-जोडी, त्यहीँ सिर्जना हुन्छ र कहिल्यै प्रतिलिपि हुँदैन।

यन्त्र-सीमा छल्न प्रोफाइल क्लोन गर्दा रद्दीकरण भाँचिन्छ: एउटा प्रतिलिपि रद्द गर्दा त्यो साझा गर्ने हरेक यन्त्र काटिन्छ, र लगले कुन मेसिनले के गर्‍यो भन्न सक्दैन। सीमा व्यावसायिक भए इमानदार समाधान थप सिट हो; आन्तरिक नीति भए उही पहुँच अधिकारसहित दोस्रो पहिचान माग्नुहोस्।

निश्चित क्रममा प्रमाणित गर्नुहोस्

प्रत्येक पटक उही तरिकाले मर्मत जाँच्नुहोस्, ताकि नतिजाको अर्थ हुन्छ।

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

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