आपातकालीन एक्सेस कैसे चालू करें
अपने उपयोगकर्ताओं के लिए आपातकालीन एक्सेस (OLCRTC) सेट अप करें: Pro सब्सक्रिप्शन, एक आपातकालीन रूट और प्रति-सर्वर runtime — चरण-दर-चरण, सही क्रम में।
यह पृष्ठ आपके लिए है, सेवा के मालिक के लिए। इसमें बताया गया है कि आपातकालीन एक्सेस कैसे चालू करें ताकि आपके उपयोगकर्ता उस पर भरोसा कर सकें। स्वयं उपयोगकर्ताओं के लिए अलग पृष्ठ हैं: आपातकालीन एक्सेस — यह कैसे काम करता है और ब्लॉक के दौरान क्या करना है — और आपातकालीन क्लाइंट की इंस्टॉलेशन — ऐप कहाँ से डाउनलोड करें और कैसे इंस्टॉल करें।
आपातकालीन एक्सेस (OLCRTC) अनुमति-सूची (allow-list) वाले नेटवर्कों के लिए एक बैकअप चैनल है, जहाँ सामान्य कनेक्शन बिल्कुल भी नहीं गुज़रता। ट्रैफ़िक फिर भी आपके अपने सर्वरों से होकर जाता है, पर उसे किसी अनुमत सेवा में वीडियो कॉल के रूप में छिपाया जाता है। यह न कोई दूसरा प्रोटोकॉल है और न मुख्य का विकल्प: यह धीमा है, छोटे सेशन के लिए बना है, उपयोगकर्ता द्वारा मैन्युअल रूप से शुरू किया जाता है, और केवल तब के लिए है जब बाकी सब कुछ काम करना बंद कर दे।
यह सुविधा चरणों में शुरू की जा रही है। सारे स्विच चालू होने पर भी हो सकता है कि आपातकालीन runtime अभी आपके सर्वरों पर इंस्टॉल न हुआ हो और सेशन शुरू होना सक्रिय न हो: एक्सेस धीरे-धीरे खुलता है। अगर चालू करने के बाद कोई सर्वर लंबे समय तक «स्वस्थ» से दूर रहता है, तो सबसे अधिक संभावना यही है कि रोलआउट अभी आप तक नहीं पहुँचा है।
यह हर नेटवर्क या हर देश में भी काम नहीं करती, और यह एक बाहरी वीडियो सेवा के उपलब्ध होने पर निर्भर करती है (और email वाले रास्ते के लिए इस पर भी कि मेल पहुँचता है या नहीं)। इसे एक गारंटीशुदा क्षमता के रूप में मत बताइए — इसे कठोर ब्लॉक के विरुद्ध बीमे के रूप में प्रस्तुत कीजिए।
आपको क्या चाहिए
- एक Pro सब्सक्रिप्शन (या Max, जिसमें Pro की सारी चीज़ें शामिल हैं);
- कम से कम एक रूट, जो आपातकालीन के रूप में चिह्नित हो;
- किसी आपातकालीन रूट में कम से कम एक सर्वर, जिस पर runtime चालू हो;
- ऐसे उपयोगकर्ता जिनका email पुष्ट हो और अकाउंट सक्रिय हो (नीचे सीमाओं वाला अनुभाग देखें)।
किस क्रम में करना है
दो स्विच हैं, दो अलग-अलग जगहों पर:
| आप क्या चालू करते हैं | वह कहाँ है | उसका नाम क्या है |
|---|---|---|
| रूट | रूट की सेटिंग्स (संपादन के समय) | «आपातकालीन रूट (OLCRTC)» |
| सर्वर | सर्वर पैनल, «संपादित करें» बटन | «इस सर्वर पर OLCRTC चलाएँ» |
क्लस्टर का अपना कोई स्विच नहीं है: जब तक उसका कम से कम एक रूट आपातकालीन के रूप में चिह्नित है, तब तक क्लस्टर का आपातकालीन एक्सेस चालू रहता है।
पहली Pro सब्सक्रिप्शन के साथ सिस्टम खुद सबसे ज़्यादा चालू इनबाउंड वाले रूट को आपातकालीन चिह्नित कर देता है, और क्लस्टर का आपातकालीन एक्सेस तुरंत चालू हो जाता है। सर्वर डिफ़ॉल्ट रूप से हिस्सा लेते हैं और runtime अपने आप फैलता है। इसलिए ज़्यादातर मामलों में नीचे दिए चरण जाँच हैं, अनिवार्य क्रम नहीं: इन्हें तब देखें जब आप दूसरे रूट चुनना चाहें, क्षमता तय करना चाहें या किसी सर्वर को बाहर रखना चाहें।
Pro की सदस्यता लें। भुगतान → सब्सक्रिप्शन ब्लॉक में जाएँ। सक्रिय Pro के बिना आपातकालीन स्विच दिखते ही नहीं हैं: उनकी जगह क्लस्टर पृष्ठ पर «अपग्रेड करें» बटन के साथ «आपातकालीन एक्सेस (OLCRTC)» कार्ड दिखाया जाता है।
किसी रूट को आपातकालीन के रूप में चिह्नित करें — स्वयं उस रूट की सेटिंग्स में। रूट को संपादन के लिए खोलें और «आपातकालीन रूट (OLCRTC)» चालू करें।
यह स्विच केवल किसी मौजूदा रूट के संपादन के समय दिखता है। नया रूट बनाने के फ़ॉर्म में यह नहीं होता: पहले रूट बनाएँ, फिर उसकी सेटिंग्स खोलकर उसे आपातकालीन के रूप में चिह्नित करें।
उस रूट के सर्वर आपातकालीन पूल में शामिल हो जाते हैं। आप कई रूट चिह्नित कर सकते हैं — पूल उन सबको एक साथ जोड़ देता है, और अगर किसी एक रूट में उपयुक्त सर्वर न हो, तो कनेक्शन दूसरे रूट के सर्वर पर चला जाता है। चिह्नित रूटों को रूट सूची में आपातकालीन (OLCRTC) लेबल मिलता है।
जैसे ही पहला रूट चिह्नित होता है, क्लस्टर का आपातकालीन एक्सेस अपने आप चालू हो जाता है: अलग से कुछ और चालू करने की ज़रूरत नहीं है।
सर्वरों पर सेशन की अनुमति दें। किसी सर्वर पर क्लिक करके उसका पैनल खोलें, आपातकालीन Runtime (OLCRTC) ब्लॉक ढूँढें, «संपादित करें» दबाएँ, «इस सर्वर पर OLCRTC चलाएँ» चालू करें और «सहेजें» दबाएँ।
runtime पृष्ठभूमि में खुद इंस्टॉल और अपडेट होता रहता है — सर्वर में लॉग इन करने की ज़रूरत नहीं। जब तक वह इंस्टॉल होकर रिपोर्ट करना शुरू नहीं करता, स्थिति «अस्वस्थ» दिखेगी; यह सामान्य है, «स्वस्थ · N/M सक्रिय» की प्रतीक्षा करें।
यह ब्लॉक केवल सामान्य इंटरफ़ेस मोड में दिखता है — सरलीकृत Single मोड में यह नहीं होता।
क्षमता तय करें। उसी ब्लॉक में — अधिकतम समवर्ती सत्र। आप इसे खाली छोड़ सकते हैं, पर बेहतर है कि न छोड़ें: अगला अनुभाग देखें।
अपने उपयोगकर्ताओं को बताएँ। आपातकालीन एक्सेस बेकार है अगर लोगों को उसके बारे में तब पता चले जब वे पहले से ही ब्लॉक हो चुके हों: क्लाइंट पहले से इंस्टॉल होना चाहिए। उन्हें आपातकालीन एक्सेस और क्लाइंट की इंस्टॉलेशन पर भेजें, और उनसे कहें कि जब तक इंटरनेट सामान्य रूप से काम कर रहा है, वे पूरी प्रक्रिया एक बार करके देख लें।
एक सर्वर कितने सेशन संभाल सकता है
एक आपातकालीन सेशन «एक और VPN उपयोगकर्ता» नहीं है — वह काफ़ी अधिक महँगा है: सर्वर ट्रैफ़िक को वीडियो स्ट्रीम में पैक करता है, और इसमें CPU का समय लगता है।
एक चालू सेशन पर मापा गया (Full HD वीडियो, लगभग 5 Mbit/s): एक सेशन लगभग एक कोर का 15% और 31 MB मेमोरी लेता है। मेमोरी का महत्व नगण्य है; असली सीमा CPU है।
| सर्वर पर कोर | उचित क्षमता |
|---|---|
| 1 | 3 |
| 2 | 6–7 |
| 4 | 12–14 |
इन संख्याओं से ऊपर न जाएँ, चाहे सर्वर समर्पित ही क्यों न हो: एक ही कोर पर चार सेशन पहले ही उसका लगभग 60% ले लेते हैं, साथ में पृष्ठभूमि का भार भी। और ध्यान रखें कि माप वीडियो देखते समय (~5 Mbit/s) लिया गया था; अगर कोई उपयोगकर्ता टनल को पूरी तरह भर दे, तो एक सेशन काफ़ी अधिक महँगा पड़ सकता है।
क्षमता का खाली फ़ील्ड मतलब «कोई सीमा नहीं»। तब बची हुई एकमात्र सुरक्षा वह स्वचालन है, जो बुरी तरह अतिभारित सर्वर पर नए सेशन रखना बंद कर देता है। पर वह देरी से प्रतिक्रिया करता है, और कमज़ोर सर्वर पर तब तक आपके सामान्य उपयोगकर्ता परेशानी झेल चुके होंगे। एक-कोर वाले सर्वरों पर क्षमता स्पष्ट रूप से तय करें।
संतुलन (balancing) कुछ हद तक मदद करता है: अगर रूट «ट्रैफ़िक के अनुसार सबसे कम लोड वाला» एल्गोरिद्म उपयोग करता है (यही डिफ़ॉल्ट है), तो उच्च CPU खपत वाला सर्वर कम खाली बैंडविड्थ रिपोर्ट करता है और नए सामान्य उपयोगकर्ता कम लदे सर्वरों पर भेजे जाते हैं। लेकिन यह कुल CPU के आधार पर किया गया सुधार है, आपातकालीन सेशनों की गिनती नहीं, और यह कई मिनट की देरी से चलता है — यह स्पष्ट क्षमता का विकल्प नहीं है।
इंटरफ़ेस में क्या दिखता है
हर सर्वर के आपातकालीन Runtime (OLCRTC) ब्लॉक में:
- सुविधा — इस सर्वर पर सेशन चल सकते हैं या नहीं;
- क्षमता — एक साथ चलने वाले सेशनों पर आपकी सीमा («सेट नहीं» = कोई सीमा नहीं);
- Runtime — स्थिति: «स्वस्थ · N/M सक्रिय», «अस्वस्थ», या «अभी रिपोर्ट नहीं कर रहा»।
चालू करने के तुरंत बाद «अस्वस्थ» की अपेक्षा करें — यह सामान्य है, सर्वर अभी runtime इंस्टॉल कर रहा है और उसने रिपोर्ट नहीं की है। अगर यह लंबे समय तक ऐसा ही बना रहे, तो जाँचें कि सर्वर से संपर्क हो भी रहा है या नहीं। «अभी रिपोर्ट नहीं कर रहा» केवल पृष्ठ लोड होते समय क्षण भर के लिए दिखता है।
पहले से जान लेने योग्य सीमाएँ
एक सेशन 12 घंटे तक चलता है, फिर अपने आप रुक जाता है। उसे बढ़ाया नहीं जा सकता — उपयोगकर्ता एक नई कॉल बनाकर दोबारा कनेक्शन का अनुरोध करता है।
प्रति उपयोगकर्ता एक सेशन। दूसरा अनुरोध दूसरा सेशन नहीं बनाता: कैबिनेट में यह «सत्र पहले से चल रहा है» दिखाएगा, और दूसरे email का कोई जवाब नहीं आएगा — यह उपयोगकर्ताओं को पहले ही समझा देना बेहतर है, ताकि यह खराबी न लगे।
इंटरनेट की गति Xray से जुड़ने की तुलना में कम रहती है।
वीडियो सेवा सर्वर के देश से पहुँच में होनी चाहिए। कॉल में आपका सर्वर जुड़ता है, इसलिए मायने उसका देश रखता है, उपयोगकर्ता का नहीं। उदाहरण के लिए, लातविया में Yandex और Wildberries बंद हैं — लातवियाई सर्वर से Telemost और WB Stream शुरू नहीं होंगे। यह तय करते समय ध्यान रखें कि किन सर्वरों पर आपातकालीन एक्सेस चालू करना है।
उपयोगकर्ताओं पर लगी शर्तें दिखने से अधिक सख़्त हैं। पुष्ट email अनिवार्य है — जिन उपयोगकर्ताओं को आपने बिना email के मैन्युअल रूप से बनाया है, वे एक्सेस का अनुरोध नहीं कर सकते। अकाउंट का सक्रिय होना भी ज़रूरी है: रोके गए, समाप्त हो चुके, सीमा खत्म कर चुके और पहली भुगतान की प्रतीक्षा कर रहे (on_hold — वे सभी जिन्होंने खुद साइन अप किया और अभी तक भुगतान नहीं किया) अकाउंट अस्वीकार कर दिए जाते हैं। email को प्रेषक-प्रमाणीकरण पास करना चाहिए और उसमें केवल कॉल का लिंक होना चाहिए।
कैबिनेट में हर अस्वीकृति उसके कारण के साथ दिखाई जाती है; email पर जवाब तब जाता है जब हम प्रेषक को आपके उपयोगकर्ता के रूप में पहचान पाते हैं (अप्रमाणित या अनजान प्रेषक को कोई जवाब नहीं मिलता)। अगर कोई शिकायत करे कि «मैंने अनुरोध किया और कुछ नहीं हुआ», तो अकाउंट की स्थिति और इस्तेमाल किए गए कॉल-लिंक से शुरू करें, और email वाले रास्ते के लिए यह भी जाँचें कि email अकाउंट के पते से भेजा गया था और उसमें केवल लिंक था।
मल्टी-हॉप रूट भाग नहीं लेते। आपातकालीन सेशनों के लिए केवल सीधे रूट उपयोग किए जाते हैं।
आपातकालीन क्लाइंट Ghostlane है, iPhone के लिए भी। यह App Store और Google Play में उपलब्ध है, और Windows, macOS और Linux के लिए इसके बिल्ड भी हैं। जिन उपयोगकर्ताओं ने पुराना olcbox इंस्टॉल किया था, उन्हें Ghostlane पर जाना होगा: olcbox अब अपडेट नहीं होता, SaluteJazz और VK Calls को नहीं पहचानता, और उसके पुराने वर्शन में नया एन्क्रिप्शन नहीं है। विवरण इंस्टॉलेशन गाइड में।
इसे बंद कैसे करें
क्लस्टर के सभी आपातकालीन रूटों पर «आपातकालीन रूट (OLCRTC)» बंद करें या उन रूटों को मिटा दें — क्लस्टर का आपातकालीन एक्सेस बंद हो जाता है और नए सेशन अब शुरू नहीं होते। जो सेशन पहले से चल रहे हैं, वे अपनी अवधि पूरी करते हैं।
अगर आपका Pro सब्सक्रिप्शन समाप्त हो गया है, तो आप फिर भी चीज़ें बंद कर सकते हैं, पर उन्हें दोबारा चालू करने के लिए उसका नवीनीकरण करना होगा।