VPN के बिना प्रॉक्सी IP घुमाना: एग्ज़िट क्या देखता है
VPN के बिना प्रॉक्सी एग्ज़िट घुमाएँ: HTTP प्रॉक्सी क्या पढ़ सकता है, स्टिकी सत्र टूटी स्थिति को कैसे रोकते हैं और किस एग्ज़िट का बचाव आप नीति में कर सकते हैं।
प्रॉक्सी रोटेशन और VPN आपका सार्वजनिक पता अलग-अलग परतों पर बदलते हैं, और यही अंतर तय करता है कि क्या लीक होगा। VPN हर पैकेट को सुरंग में ले जाता है, इसलिए लक्ष्य जो स्रोत पता देखता है वह सुरंग का अंतिम बिंदु है। प्रॉक्सी नेटवर्क परत के ऊपर बैठता है: केवल वे अनुरोध जो आप उसके माध्यम से भेजते हैं एग्ज़िट से दिखते हैं, जबकि मशीन पर बाकी सब असली पता रखता है। इस विभाजन को सही करना रोटेशन को एक चेकबॉक्स से डिज़ाइन निर्णय में बदल देता है।
सार्वजनिक पता वास्तव में कहाँ से आता है
लक्ष्य जो पता देखता है वह वही है जहाँ से आपका ट्रैफ़िक आखिरी बार निकला था, और घरेलू कनेक्शन पर वह आपके राउटर पर प्रदाता का पता है, मशीन का कोई अपना नहीं। राउटर को फिर से शुरू करने से वही लीज़ वापस मिल सकती है, और उसका MAC पता बदलने से कभी-कभी नया बनता है, लेकिन दोनों में से कोई भी आपको देश चुनने की सुविधा नहीं देता। VPN IP परत पर स्रोत पता बदल देता है, इसलिए मशीन से निकलने वाला हर पैकेट, DNS और पृष्ठभूमि अपडेट सहित, सुरंग के अंतिम बिंदु से निकलता है। प्रॉक्सी एक परत ऊपर काम करता है: वह अनुरोध स्वीकार करता है, लक्ष्य तक अपना कनेक्शन खोलता है, और केवल वही अनुरोध एग्ज़िट से दिखता है। मशीन पर बाकी सब अब भी असली पता इस्तेमाल करता है।
यही विभाजन ज़्यादातर आश्चर्य समझाता है। प्रॉक्सी की ओर इंगित ब्राउज़र एक्सटेंशन केवल वही बदलता है जो ब्राउज़र भेजता है और कुछ नहीं, इसलिए उसी होस्ट पर दूसरा एप्लिकेशन अब भी मूल पता लीक करता है। सिस्टम-व्यापी VPN का विपरीत विफलता मोड है: वह उस ट्रैफ़िक को ढकता है जिसे आप स्थानीय रखना चाहते थे और केवल तभी बंद होकर विफल होता है जब क्लाइंट उस तरह से कॉन्फ़िगर हो। दोनों में से चुनना वास्तव में यह चुनना है कि कौन-सा ट्रैफ़िक खिसकना चाहिए।
फिर रोटेशन उसी परत पर लागू होता है जो आपने चुनी। प्रॉक्सी के साथ, रोटेशन का अर्थ है कि अगला अनुरोध दूसरा एग्ज़िट इस्तेमाल करेगा। VPN के साथ, इसका अर्थ है सुरंग को ढहाकर फिर से बनाना, जो धीमा है और दिखाई देने वाले पुनःकनेक्शन के रूप में दिखता है।
HTTP प्रॉक्सी क्या पढ़ सकता है और क्या नहीं
सादे HTTP में प्रॉक्सी अनुरोध पंक्ति में पूर्ण URI, हर हेडर और बॉडी देखता है। वह इन सबका लॉग रख सकता है और कोई भी हिस्सा फिर से लिख सकता है, इसलिए जो मुफ़्त प्रॉक्सी प्रतिक्रियाओं में स्क्रिप्ट डालता है वह ठीक वही करता है जिसकी प्रोटोकॉल अनुमति देता है। प्रमाणीकरण इस्तेमाल करता है Proxy-Authorization, और गायब या गलत क्रेडेंशियल पैदा करता है 407 Proxy Authentication Required कनेक्शन त्रुटि के बजाय।
HTTPS में क्लाइंट भेजता है CONNECT host:port और प्रॉक्सी एक कच्ची सुरंग खोलता है, जिसके बाद वह एन्क्रिप्टेड बाइट देखता है। वह अब भी CONNECT पंक्ति से और आमतौर पर TLS हैंडशेक के SNI फ़ील्ड से होस्टनाम जानता है, इसलिए होस्टनाम-स्तर की लॉगिंग बनी रहती है भले ही पेलोड न रहे। पेलोड पढ़ने के लिए क्लाइंट के भरोसेमंद प्रमाणपत्र के साथ TLS समाप्त करना पड़ता है, जो अलग जोखिम वाला दूसरा उत्पाद है। और HTTP सिमैंटिक्स विनिर्देश CONNECT को सुरंग अनुरोध के रूप में परिभाषित करता है, जो इस बात का सही मानसिक मॉडल है कि एग्ज़िट क्या देख सकता है और क्या नहीं।
curl -v -x http://proxy.example.net:8080 https://example.com 2>&1 | grep -E 'CONNECT|Proxy-'
विस्तृत आउटपुट किसी भी TLS ट्रैफ़िक से पहले CONNECT पंक्ति दिखाता है, और यही वह क्षण है जब प्रॉक्सी आपका गंतव्य जानता है। 407 के साथ उत्तर देने वाला प्रॉक्सी कभी सुरंग नहीं खोल पाया, इसलिए अलग TLS सेटिंग्स के साथ फिर से कोशिश करने से मदद नहीं मिलेगी।
रोटेशन की ग्रैन्युलैरिटी तय करती है कि क्या टूटेगा
हर अनुरोध पर रोटेशन वह सेटिंग है जो सबसे सुरक्षित दिखती है और सबसे ज़्यादा तोड़ती है। कुकीज़, CSRF टोकन और सर्वर-साइड सत्र किसी पहचान से बँधे होते हैं, और वह पहचान जो लॉगिन और अगली कॉल के बीच बदल जाती है, लक्ष्य को सत्र चोरी जैसी लगती है। कई प्रदाता स्टिकी सत्र को प्रॉक्सी उपयोगकर्ता नाम में एन्कोड करके देते हैं, इसलिए चुनी गई विंडो के लिए एग्ज़िट स्थिर रहता है।
ग्रैन्युलैरिटी कार्य से चुनें, प्रदाता के डिफ़ॉल्ट से नहीं। स्वतंत्र पृष्ठ लाने वाला क्रॉलर हर अनुरोध पर घूम सकता है, जबकि चेकआउट प्रवाह या प्रमाणित API को पूरे प्रवाह के लिए एक एग्ज़िट रखना पड़ता है। नीचे दी गई दो कॉल एक स्टिकी उपयोगकर्ता नाम और एक सादा घूमता एंडपॉइंट दिखाती हैं, और socks5h स्कीम नामों को स्थानीय रूप से नहीं बल्कि प्रॉक्सी पर हल करती है।
curl -sS -x http://user-session-a1b2:[email protected]:8080 https://ifconfig.me
curl -sS -x socks5h://127.0.0.1:1080 https://ifconfig.me
स्थानीय DNS एक ख़ामोश लीक है। अगर क्लाइंट कनेक्ट करने से पहले नाम हल करता है, तो रिज़ॉल्वर अब भी आपकी हर मुलाक़ाती होस्ट जानता है भले ही HTTP अनुरोध कहीं और से निकले। और socks5h रूप और प्रॉक्सी-साइड समाधान इससे बचते हैं, और इनका उपयोग कुछ भी खर्च नहीं करता।
लक्ष्य पते के अलावा और क्या वर्गीकृत करता है
पते की प्रतिष्ठा कई इनपुट में से एक है। लक्ष्य ASN और उसका डेटा सेंटर या आवासीय लेबल, क्लाइंट की TLS फ़िंगरप्रिंट, HTTP/2 सेटिंग्स, हेडर क्रम, अनुरोध दर और नेविगेशन का आकार जोड़ते हैं। हेडलेस ब्राउज़र द्वारा चलाया गया आवासीय एग्ज़िट वहाँ विफल हो सकता है जहाँ असली सत्र द्वारा चलाया गया डेटा सेंटर एग्ज़िट पास होता है।
एग्ज़िट का प्रकार तय करता है कि ट्रैफ़िक के बारे में आप ईमानदारी से क्या दावा कर सकते हैं, और हर एक की अलग लागत है।
| Exit type | What the target sees | Main cost |
|---|---|---|
| Datacenter proxy | Hosting ASN, cheap, often pre-blocked | Low reputation, easy to detect |
| Residential network | A consumer ISP address belonging to someone else | Consent and terms-of-service exposure |
| Mobile carrier | A carrier NAT address shared by many subscribers | Price, plus shared blame for abuse |
| Your own cloud egress | An address you are accountable for | Recognisable, but defensible |
साझा एग्ज़िट तटस्थ नहीं है। उस पते से चलने वाली बाकी हर चीज़ उसी प्रतिष्ठा की बाल्टी में गिरती है, और दूसरे किरायेदारों द्वारा पहले ही जला दिया गया पता आपका पहला अनुरोध पढ़े जाने से पहले विफल हो जाता है।
ऐसा एग्ज़िट चुनें जिसे आप नीति में बता सकें
उपयोगी सवाल यह नहीं है कि पता कैसे छिपाएँ, बल्कि यह है कि उससे निकलने वाले ट्रैफ़िक का ज़िम्मेदार कौन है। हर कार्य के लिए आपका अपना क्लाउड एग्ज़िट, डेटा-प्रोसेसिंग समझौते और प्रकाशित प्रतिधारण वाला अनुबंधित प्रदाता, और हर कार्य के लिए एक पहचान वाला स्व-होस्टेड VPN — सब एक वाक्य में बताए जा सकते हैं। मुफ़्त सूची नहीं, क्योंकि उसके ऑपरेटर का आपके प्रति कोई दायित्व नहीं है और उसे लॉग करने का हर प्रोत्साहन है।
अपनी दर-सीमाएँ लक्ष्य जो सहता है उससे नीचे रखें, और केवल वही फ़ील्ड इकट्ठा करें जिनकी कार्य को ज़रूरत है, ताकि गलती छोटी रहे। ब्लॉक से बचने के लिए तेज़ घुमाना आमतौर पर उस अनुरोध दर को बढ़ाता है जिसने उसे पैदा किया था।
लिखें चुना गया एग्ज़िट, उसकी रोटेशन विंडो और उसका मालिक पहले रन से पहले जॉब कॉन्फ़िग में। जब ब्लॉक आए, तो वही नोट आपको बताता है कि एग्ज़िट बदलें या व्यवहार बदलें।