प्रॉक्सी का कनेक्ट होना यह साबित नहीं करता कि वह उपयोग के योग्य है। यह गाइड पाँच दोहराने योग्य जाँच बताती है: स्थान और ऑपरेटर, रेजिडेंशियल या डेटा-सेंटर IP, कनेक्टिविटी और पैकेट लॉस, DNS/WebRTC लीक, और समय के साथ IP के फ्लैग होने के संकेत।
प्रॉक्सी कॉन्फ़िगर करने के बाद किसी पेज पर कनेक्शन सफल दिखना केवल पहला कदम है। वास्तव में यह तय करने वाले विवरण अक्सर नज़रअंदाज़ हो जाते हैं कि वातावरण उपयोग योग्य है या नहीं: एग्ज़िट पता किसका है, पता-रेंज रेजिडेंशियल है या डेटा सेंटर की, DNS अनुरोध कहाँ से भेजे जाते हैं, और क्या WebRTC असली पते को उजागर करता है।
नीचे दिए पाँच बिंदुओं को ठोस तरीकों के साथ एक-एक करके जाँचने में लगभग दस मिनट लगते हैं।
1. क्या स्थान और ऑपरेटर सही हैं?
कोई भी ऐसा पेज खोलें जो वर्तमान IP दिखाता हो और तीन चीज़ें जाँचें: दिखाया गया देश और शहर आपकी अपेक्षित लोकेशन से मेल खाते हैं या नहीं, ऑपरेटर का नाम खरीदे गए प्रदाता से मेल खाता है या नहीं, और ASN घोषित जानकारी के समान है या नहीं।
इससे एक सामान्य समस्या पकड़ी जा सकती है: प्रदाता कहता है कि नोड जर्मनी में है, लेकिन वास्तविक एग्ज़िट अमेरिका में है। IP डेटाबेसों में भी अंतर हो सकता है, इसलिए अलग-अलग जाँच साइटें अलग परिणाम दिखा सकती हैं। दो या तीन स्रोतों का मिलान करें और whois रिकॉर्ड में दर्ज संगठन को आधार मानें।
IPv6 भी जाँचें। कुछ वातावरणों में ब्राउज़र ट्रैफ़िक प्रॉक्सी से गुजरता है, लेकिन IPv6 स्थानीय नेटवर्क से ही बाहर जाता है। केवल IPv6 जाँचने वाले पेज पर सुनिश्चित करें कि परिणाम भी प्रॉक्सी एग्ज़िट की ओर इशारा करता है। यदि वह अभी भी आपका वास्तविक पता दिखाता है, तो वातावरण केवल आंशिक रूप से सुरक्षित है।
2. रेजिडेंशियल रेंज या डेटा-सेंटर रेंज?
IP का प्रकार स्थान से भी अधिक आसानी से छूट जाता है, लेकिन उसका प्रभाव अधिक सीधा हो सकता है। रेजिडेंशियल IP ब्रॉडबैंड ऑपरेटरों के नाम पर पंजीकृत होते हैं, जबकि डेटा-सेंटर IP क्लाउड प्रदाताओं या IDC के पता-रेंज में आते हैं। यह अंतर IP-टाइप डेटाबेस में सार्वजनिक रूप से देखा जा सकता है।
सबसे सरल तरीका ASN के पंजीकृत संगठन को देखना है। Cloud, Hosting, Data Center या VPS जैसे शब्द वाले नाम आमतौर पर डेटा-सेंटर रेंज होते हैं; Telecom, Broadband, Cable या Communications वाले नाम अक्सर रेजिडेंशियल या ISP रेंज होते हैं। Reverse DNS भी देखें: रेजिडेंशियल IP में प्रायः ऑपरेटर द्वारा दिया गया रिवर्स रिकॉर्ड होता है, जबकि डेटा-सेंटर IP का PTR अक्सर क्लाउड प्रदाता के डोमेन पैटर्न जैसा होता है।
यदि आप अपने क्लाउड सर्वर को प्रॉक्सी के रूप में इस्तेमाल करते हैं, तो एग्ज़िट अनिवार्य रूप से डेटा-सेंटर IP होगा। यह ढाँचे की प्रकृति से तय होता है और कॉन्फ़िगरेशन से नहीं बदलता। लाभ हैं स्थिरता, नियंत्रण और IP का केवल आपके द्वारा इस्तेमाल होना; नुकसान है IP का प्रकार। कौन-सा पहलू अधिक महत्वपूर्ण है, यह लक्ष्य प्लेटफ़ॉर्म के जोखिम नियंत्रण की कठोरता पर निर्भर करता है: हल्के नियंत्रण वाले मामलों में डेटा-सेंटर रेंज चल सकती है, जबकि कड़े मामलों में रेजिडेंशियल या ISP प्रॉक्सी की आवश्यकता हो सकती है।
3. कनेक्टिविटी और पैकेट लॉस
कनेक्शन होना स्थिरता के बराबर नहीं है। थोड़ी देर का ping समस्या नहीं दिखा सकता, इसलिए कुछ समय लगातार निगरानी करनी चाहिए।
किसी तय लक्ष्य पर लगातार ping करें या वही अनुरोध सैकड़ों बार भेजें और पैकेट लॉस तथा लेटेंसी में बदलाव देखें। आदर्श स्थिति शून्य पैकेट लॉस और लगभग एक ही स्तर पर स्थिर लेटेंसी है। बीच-बीच में पैकेट लॉस या बहुत ऊपर-नीचे होती लेटेंसी आमतौर पर लाइन कंजेशन या कम बैंडविड्थ का संकेत है। समस्या वाले हिस्से को ढूँढने के लिए चरणों में जाँचें: पहले स्थानीय डिवाइस से प्रॉक्सी सर्वर तक की लेटेंसी, फिर सर्वर से लक्ष्य साइट तक की लेटेंसी। जो हिस्सा स्पष्ट रूप से खराब हो, वहीं बॉटलनेक है।
प्रॉक्सी प्रकार भी मेल खाना चाहिए। SSH, SOCKS5 और HTTP को मनमाने ढंग से मिलाकर कॉन्फ़िगर नहीं किया जा सकता; क्लाइंट में चुना गया प्रोटोकॉल सर्वर पर वास्तव में खुले प्रोटोकॉल के समान होना चाहिए, अन्यथा कनेक्शन बना हुआ दिख सकता है लेकिन ट्रैफ़िक सही से नहीं चलेगा। पोर्ट के लिए भी यही बात लागू होती है। यदि SSH का डिफ़ॉल्ट पोर्ट 22 प्रदाता ने बंद किया है, तो पासवर्ड पर शक करने से पहले firewall नियम ठीक करें।
4. क्या DNS और WebRTC लीक हो रहे हैं?
ये दोनों जाँच तय करती हैं कि आपकी वास्तविक लोकेशन किसी दूसरी राह से उजागर हो सकती है या नहीं।
DNS लीक जाँचने के लिए ऐसी साइट खोलें जो DNS leak test देती हो और देखें कि रिज़ॉल्यूशन अनुरोध किस नोड से भेजे जा रहे हैं। यदि अंतिम resolver अभी भी स्थानीय है, तो केवल ट्रैफ़िक का प्रॉक्सी से गुजरना पर्याप्त नहीं है: प्लेटफ़ॉर्म DNS रिज़ॉल्यूशन की लोकेशन से आपकी वास्तविक रीजन का अनुमान लगा सकता है और उसे IP लोकेशन से मिला सकता है। समाधान है वातावरण में remote DNS resolution चालू करना या ऐसा प्रॉक्सी प्रकार चुनना जो DNS को प्रॉक्सी के माध्यम से resolve करे।
WebRTC लीक अधिक छिपे होते हैं। ब्राउज़र peer-to-peer संचार के लिए स्थानीय नेटवर्क इंटरफ़ेस की जानकारी इकट्ठी करता है और कुछ सेटिंग में प्रॉक्सी को बायपास कर निजी या सार्वजनिक पता भी उजागर कर सकता है। WebRTC टेस्ट पेज खोलें और देखें कि candidate addresses में आपका वास्तविक IP तो नहीं है। यदि है, तो ब्राउज़र या वातावरण की सेटिंग में WebRTC बंद करें या उसे केवल प्रॉक्सी के माध्यम से चलने तक सीमित करें।
5. क्या टाइम ज़ोन और भाषा आपस में सुसंगत हैं?
यदि एग्ज़िट अमेरिका दिखाता है लेकिन ब्राउज़र बीजिंग समय, चीनी भाषा और चीनी शैली की फ़ॉन्ट रेंडरिंग इस्तेमाल करता है, तो स्पष्ट असंगति बनती है। टाइम ज़ोन, भाषा और इंटरफ़ेस रीजन को IP लोकेशन के अनुरूप रखें। किसी खास शहर की हूबहू नकल करना आवश्यक नहीं है।
लंबे समय में कैसे पता करें कि IP फ्लैग हुआ है
ऊपर की जाँचें उसी दिन पूरी की जा सकती हैं, लेकिन IP प्रतिष्ठा समय के साथ ही समझ में आती है। देखें कि लक्ष्य साइट पर CAPTCHA अधिक बार आने लगे हैं या नहीं, लॉगिन पर दूसरी सत्यापन माँग बार-बार होने लगी है या नहीं, पहले सामान्य सुविधाएँ सीमित होने लगी हैं या नहीं, और नेटवर्क बदलते ही वही साइट तुरंत सामान्य हो जाती है या नहीं।
यदि कुछ ही कार्यों के बाद बार-बार सत्यापन ट्रिगर होता है, तो आमतौर पर दो कारण होते हैं: IP प्रकार उपयुक्त नहीं है, या पता-रेंज पहले बहुत से उपयोगकर्ताओं द्वारा इस्तेमाल किया गया है और उसका इतिहास बन चुका है। Anti-abuse डेटाबेस देखकर पता लगाया जा सकता है कि रेंज पहले फ्लैग हुई थी या नहीं। अपने सर्वर का लाभ यहाँ दिखाई देता है: खरीद के दिन से IP केवल आपके द्वारा इस्तेमाल होता है, इसलिए उसका इतिहास अपेक्षाकृत साफ़ शुरू होता है।
व्यावहारिक रूप से दो रास्ते हैं: रेजिडेंशियल प्रॉक्सी पर जाएँ, या कम उपयोगकर्ताओं वाला क्षेत्रीय नोड चुनें।
कॉन्फ़िगरेशन वाले दिन जाँचने का क्रम
- IP lookup पेज पर स्थान, ऑपरेटर और ASN की पुष्टि करें और फिर IPv6 लीक जाँचें
- ASN के पंजीकृत संगठन और reverse DNS से तय करें कि रेंज रेजिडेंशियल है या डेटा सेंटर की
- सैकड़ों लगातार अनुरोध भेजकर पैकेट लॉस और लेटेंसी बदलाव देखें; आवश्यक हो तो अलग-अलग हिस्सों में जाँचें
- DNS leak test और WebRTC test से पुष्टि करें कि वास्तविक एग्ज़िट उजागर नहीं हो रहा है
- टाइम ज़ोन, भाषा और इंटरफ़ेस रीजन को IP लोकेशन के साथ मिलाएँ
इसके बाद हर एक या दो सप्ताह में CAPTCHA और दूसरी सत्यापन की आवृत्ति फिर देखें और रिकॉर्ड करें। जब कोई टीम कई वातावरण एक साथ संभालती है, तो हर वातावरण को उसके एग्ज़िट और पैरामीटर के साथ स्थायी रूप से मैप करना बहुत काम बचाता है। इस चरण में PurpleMark जैसे टूल का multi-environment management इस्तेमाल किया जा सकता है।
प्रॉक्सी का चलना और उसका उपयुक्त होना दो अलग बातें हैं। पहले के लिए सही कॉन्फ़िगरेशन पर्याप्त है; दूसरे के लिए हर बिंदु की जाँच आवश्यक है। बिना जाँचे रह गए DNS लीक, WebRTC और IP प्रकार ही वे चीज़ें हैं जो अनजाने में पूरे वातावरण की विश्वसनीयता सबसे आसानी से घटा सकती हैं।
