सर्वर और क्षेत्र चुनने से लेकर बुनियादी सुरक्षा, प्रॉक्सी इंस्टॉलेशन, प्रमाणीकरण व पोर्ट, क्लाइंट कनेक्शन, सत्यापन और कनेक्शन विफल होने पर जांच के सही क्रम तक।
सर्वर और क्षेत्र चुनें
प्रॉक्सी स्वयं बहुत कम CPU और मेमोरी उपयोग करता है, इसलिए सर्वर कॉन्फ़िगरेशन चुनते समय ये मुख्य प्राथमिकता नहीं हैं।
शुरुआत में उच्च कॉन्फ़िगरेशन वाला प्लान लेने की जरूरत नहीं है। तय बैंडविड्थ और मासिक ट्रैफ़िक को एक साथ देने वाले लाइटवेट एप्लिकेशन सर्वर जैसे पैकेज आम तौर पर एक या कुछ अकाउंट के निजी प्रॉक्सी उपयोग के लिए पर्याप्त होते हैं और सस्ते भी पड़ते हैं। कई इंस्टेंस की जरूरत होने या बैंडविड्थ की स्पष्ट मांग होने पर ही ऐसे सामान्य इंस्टेंस पर जाएं जिनमें संसाधन अलग-अलग चुने जा सकें।
हार्डवेयर से ज्यादा ध्यान क्षेत्र पर दें, क्योंकि एग्ज़िट IP उसी स्थान से संबंधित होता है जहां नोड तैनात है। नियम सीधा है: अकाउंट जिस बाजार के लिए है, नोड उसी बाजार में रखें। कई लोग केवल कनेक्शन स्पीड के आधार पर चुनते हैं। मुख्यभूमि चीन से हांगकांग नोड तेज हो सकता है, लेकिन यदि अकाउंट प्रोफ़ाइल अमेरिका दिखाती है और एग्ज़िट एशिया में है, तो यह असंगति स्पीड से अधिक महत्वपूर्ण है। स्पीड द्वितीयक है; संगति पहली प्राथमिकता है।
बैंडविड्थ का अनुमान वास्तविक उपयोग के अनुसार लगाएं। केवल डैशबोर्ड देखने और दैनिक प्रबंधन के लिए कम बैंडविड्थ पर्याप्त हो सकती है; इमेज और वीडियो से जुड़े काम में अधिक चाहिए; और जितने अधिक अकाउंट एक साथ ऑनलाइन होंगे, उतनी अधिक बैंडविड्थ की जरूरत होगी। निश्चित न हों तो सबसे छोटे प्लान से शुरू करें, एक महीने उपयोग देखें और फिर समायोजित करें।
सर्वर चालू होने के बाद पहले ये काम करें
सिस्टम इमेज के लिए Linux चुनें। ऐसे वितरण में SSH सामान्यतः पहले से उपलब्ध होता है, इसलिए अलग रिमोट सेवा सेट करने की जरूरत नहीं पड़ती। खरीदते समय की फ़ाइल के बजाय कस्टम पासवर्ड चुनना बाद में प्रॉक्सी सेटअप के दौरान एक रूपांतरण चरण कम कर सकता है।
सर्वर मिलने के बाद चार जानकारियां लिख लें: पब्लिक IP, उपयोगकर्ता नाम (Linux में सामान्यतः root), पासवर्ड और SSH पोर्ट (डिफ़ॉल्ट 22)। यही जानकारी क्लाइंट में भरनी होगी।
इसके बाद बुनियादी सुरक्षा सेट करें। डिफ़ॉल्ट पोर्ट 22 बदलने से बहुत-सी स्वचालित स्कैनिंग कोशिशें कम हो जाती हैं। यदि प्रदाता की-आधारित लॉगिन का समर्थन करता है, तो उसे सेट करके पासवर्ड लॉगिन बंद किया जा सकता है। सिक्योरिटी ग्रुप और सिस्टम फ़ायरवॉल दोनों में केवल वही पोर्ट खोलें जिनकी वास्तव में जरूरत है और बाकी बंद रखें। कुछ मिनट का यह काम लंबे समय तक स्कैनिंग और चुराए गए क्रेडेंशियल से होने वाली कोशिशों का शोर कम करता है।
प्रॉक्सी सेवा के दो तरीके
पहला तरीका सीधे SSH टनल का उपयोग करना है। सर्वर पर कुछ अतिरिक्त इंस्टॉल करने की जरूरत नहीं होती: क्लाइंट सर्वर की मौजूदा SSH सेवा से ट्रैफ़िक फॉरवर्ड करता है, और पोर्ट 22 तथा सर्वर के अकाउंट क्रेडेंशियल ही उपयोग होते हैं। कमी यह है कि प्रदर्शन सामान्य रहता है; लंबे समय तक चलाने या अधिक समवर्ती कनेक्शन पर दबाव बढ़ सकता है। यह अस्थायी उपयोग या बहुत कम अकाउंट के लिए अधिक उपयुक्त है।
दूसरा तरीका सर्वर पर एक समर्पित प्रॉक्सी सेवा इंस्टॉल करना है। आम तौर पर इसे एक इंस्टॉलेशन कमांड से लगाया जाता है और फिर प्रमाणीकरण विधि तथा पोर्ट अलग से कॉन्फ़िगर किए जाते हैं। यह बेहतर प्रदर्शन और अधिक नियंत्रण देता है और लंबे समय के उपयोग के लिए उपयुक्त है। इंस्टॉलेशन के बाद बूट पर स्वचालित स्टार्ट सक्षम करें, वरना सर्वर रीस्टार्ट होने पर प्रॉक्सी भी बंद हो जाएगा।
प्रमाणीकरण और पोर्ट
प्रमाणीकरण को सुरक्षा बढ़ने के क्रम में तीन स्तरों में देखा जा सकता है: उपयोगकर्ता नाम और पासवर्ड सबसे आसान है, लेकिन पासवर्ड लीक होने पर प्रॉक्सी का एक्सेस लगभग हाथ से निकल जाता है; पासवर्ड के साथ स्रोत IP की allowlist रोज़मर्रा के उपयोग के लिए आम तौर पर पर्याप्त है; की या सर्टिफिकेट आधारित प्रमाणीकरण सबसे मजबूत है, हालांकि इसे सेट करने में थोड़ा अधिक समय लगता है और लंबे समय तक चलने वाले अकाउंट के लिए यह मेहनत सार्थक है।
पोर्ट के मामले में केवल सेवा का listening port सेट करना पर्याप्त नहीं है। वही पोर्ट सिस्टम फ़ायरवॉल और प्रदाता के सिक्योरिटी ग्रुप दोनों में अलग-अलग खोलना होगा। ये दोनों स्वतंत्र नियंत्रण हैं और केवल एक जगह पोर्ट खोलना कनेक्शन विफल होने का आम कारण है। listening address को केवल स्थानीय loopback से भी न बांधें। यदि सर्वर के भीतर परीक्षण सफल है लेकिन बाहर से कनेक्शन नहीं बनता, तो यह संभावित कारण है।
क्लाइंट से कनेक्ट करें और सत्यापित करें
पर्यावरण प्रबंधन टूल में नया वातावरण बनाएं, नाम और नोट जोड़ें — नाम में अकाउंट का उपयोग और लक्ष्य क्षेत्र लिखने से अकाउंट बढ़ने पर प्रबंधन आसान होता है — फिर प्रॉक्सी प्रकार के अनुसार सर्वर पता, पोर्ट, उपयोगकर्ता नाम और पासवर्ड भरकर परीक्षण चलाएं। सफलता संदेश बताता है कि नेटवर्क पथ उपलब्ध है। सटीक फ़ील्ड नाम टूल के इंटरफ़ेस पर निर्भर करेंगे।
कनेक्शन टेस्ट पास होना केवल पहला चरण है। वातावरण खोलकर तीन बातें जांचें।
पहली, एग्ज़िट IP सर्वर का पब्लिक IP होना चाहिए। वर्तमान IP दिखाने वाला पेज खोलें; प्रॉक्सी सही चल रहा है तभी जब वहां सर्वर का पता दिखाई दे।
दूसरी, DNS भी प्रॉक्सी के माध्यम से जाना चाहिए। यदि DNS अभी भी स्थानीय रूप से resolve हो रहा है, तो बाहर दिखाई देने वाली भौगोलिक जानकारी एग्ज़िट IP से मेल नहीं खा सकती और अकाउंट में चुना गया क्षेत्र अर्थहीन हो जाएगा।
तीसरी, समय क्षेत्र और भाषा एग्ज़िट क्षेत्र से मेल खाने चाहिए। अमेरिकी IP के साथ चीनी समय क्षेत्र और चीनी भाषा स्पष्ट असंगति है।
तीनों जांच पास होने के बाद ही वातावरण को उपयोग के लिए तैयार मानें।
कनेक्शन न बने तो इस क्रम में जांचें
यदि प्रॉक्सी टेस्ट तुरंत विफल हो जाए, तो पहले कनेक्टिविटी देखें: सिक्योरिटी ग्रुप और सिस्टम फ़ायरवॉल दोनों में पोर्ट खुला है या नहीं। फिर देखें कि प्रॉक्सी सेवा चल रही है या नहीं, खासकर सर्वर रीस्टार्ट होने के बाद। उसके बाद उपयोगकर्ता नाम, पासवर्ड और सर्वर पता जांचें। पब्लिक IP और प्राइवेट IP को गड़बड़ करना आम गलती है।
यदि टेस्ट पास हो लेकिन पेज न खुलें, तो समस्या अक्सर वातावरण की तरफ होती है। जांचें कि सही प्रॉक्सी उससे जुड़ा है और DNS सेटिंग फिर से स्थानीय resolution पर नहीं लौट गई है।
यदि स्पीड धीमी है, तो पहले तय करें कि कारण दूरी है या बैंडविड्थ। लक्ष्य साइट को सीधे सर्वर से खोलकर देखें। यदि सर्वर स्वयं धीमा है तो समस्या नोड क्षेत्र या नेटवर्क रूट में है; यदि सर्वर तेज है लेकिन क्लाइंट धीमा है तो संभवतः बैंडविड्थ कम है या बहुत अधिक अकाउंट एक साथ ऑनलाइन हैं।
अकाउंट बढ़ने पर कैसे विस्तार करें
एक सर्वर पर कई अकाउंट चलाना सस्ता है, लेकिन सभी एक ही एग्ज़िट IP साझा करते हैं। यदि प्लेटफ़ॉर्म IP रेंज के आधार पर संबंध पहचानता है, तो अकाउंट के बीच लिंक होने की संभावना बनी रहती है। हर अकाउंट के लिए अलग सर्वर महंगा है, लेकिन वातावरण पूरी तरह अलग रहते हैं और अधिक मूल्यवान अकाउंट के लिए यह अधिक मजबूत विकल्प है।
PurpleMark जैसे पर्यावरण प्रबंधन टूल से हर अकाउंट को अलग एग्ज़िट देना, हाथ से मैपिंग तालिका संभालने से अधिक विश्वसनीय है। लाइटवेट सर्वर की सामान्य कीमतों पर हर अकाउंट के लिए अलग एग्ज़िट की लागत कई मामलों में स्वीकार्य रहती है और बाद में लिंक होने के कारण अकाउंट फिर से बनाने की परेशानी कम कर सकती है। परीक्षण के लिए एक अलग सर्वर भी रखें। सभी अकाउंट एक ही मशीन पर न रखें, क्योंकि एक single point of failure सभी को एक साथ प्रभावित कर सकता है।
