साझा 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 से मोबाइल पर हस्तांतरण के बाद दोहराएँ, क्योंकि फिर से जुड़ना दूसरा रिकॉर्ड बना सकता है।

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