इस्तेमाल किए गए VPN एग्ज़िट पते को कैसे रिकॉर्ड और सत्यापित करें
क्लाइंट ऐप्स जगह का नाम दिखाते हैं, वह पता नहीं जहाँ से आपका ट्रैफ़िक बाहर निकला। कनेक्ट होते समय एग्ज़िट IP कैप्चर करें और उसकी तुलना सीधे आधार-रेखा से करें।
किसी डेस्कटॉप VPN क्लाइंट से पूछें कि आपने कौन से सर्वर इस्तेमाल किए, और ईमानदार जवाब आम तौर पर किसी जगह का नाम होता है। वह नाम आपके चुने हुए प्रवेश-बिंदु का है, और जिस पते से आपका ट्रैफ़िक बाहर निकला वह बिल्कुल अलग मशीन हो सकती है। ऐप में दूसरे नंबर को रखने के लिए कुछ भी नहीं बनाया गया है, इसलिए रिकॉर्ड इस्तेमाल के क्षण में ही बनाना पड़ता है। दो तरीके हैं, और इनमें से सिर्फ़ एक ही सपोर्ट केस के सामने टिकता है।
दो रिकॉर्ड, और इनमें से सिर्फ़ एक मौजूद है
क्लाइंट का अपना दृश्य बेहतरीन हालत में टाइमस्टैम्प के साथ चुनी गई जगहों की सूची है। यह डिज़ाइन का फ़ैसला है, चूक नहीं: पते परिचालन की बारीकी हैं, वे असाइनमेंट के बीच बदलते रहते हैं, और मैपिंग सार्वजनिक करने से सपोर्ट और दुरुपयोग की कार्रवाई दोनों मुश्किल होती हैं। प्रदाता अपने नेटवर्क के आगे क्लाउड इंस्टेंस इसीलिए रखते हैं ताकि एंडपॉइंट किसी को बताए बिना ही जगह बदल सके। ऐप आपको आपका चुना हुआ विकल्प दिखाता है, वह रास्ता नहीं जो ट्रैफ़िक ने लिया।
जो रिकॉर्ड आप खुद बना सकते हैं वह एक लोकल फ़ाइल है जिसमें हर पंक्ति पर एक सार्वजनिक पता और एक UTC टाइमस्टैम्प होता है। यह छोटा, बदसूरत और कहीं ज़्यादा उपयोगी है, क्योंकि यह ठीक वही बताता है जो बाहर का देखने वाला भी देख सकता है।
विकल्प क: एग्ज़िट पता खुद कैप्चर करें
एक इको सेवा वही स्रोत पता लौटाती है जहाँ से अनुरोध आया था, जो परिभाषा से एग्ज़िट पता है। कैप्चर तब चलाएँ जब टनल कनेक्टेड बताए, क्योंकि जो क्लाइंट रूट और DNS के स्थिर होने से पहले कनेक्टेड कहता है वह टनल से पहले का पता दर्ज करेगा और पहली पंक्ति से ही लॉग को दूषित कर देगा।
#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"
दो बारीकियाँ उस अंश को सजावटी नहीं, काम का बनाती हैं। टाइमस्टैम्प और पता एक ही पंक्ति में हैं, इसलिए बाद के विश्लेषण को रिकॉर्ड जोड़ने की ज़रूरत नहीं पड़ती, और umask 077 फ़ाइल को बनने के क्षण से ही निजी रखता है। इसे हर कनेक्शन पर एक बार चलाएँ, हर बूट पर एक बार नहीं, और हर डिवाइस के लिए एक फ़ाइल रखें।
लॉग दर्ज करता है कि आपने टनल कब इस्तेमाल किया और किस नेटवर्क से नज़र आए, जो गिनती से ज़्यादा ब्राउज़िंग इतिहास के करीब है। ऐसी अवधि चुनें जिसका आप बचाव कर सकें, फ़ाइल को साझा सिंक फ़ोल्डरों से बाहर रखें और उसे जान-बूझकर साफ़ करें।
विकल्प ख: प्रदाता से इतिहास माँगें
कुछ प्रदाता कनेक्शन लॉग रखते हैं और सपोर्ट के सवाल का जवाब टाइमस्टैम्प और सर्वर नाम से देते हैं। वह रिकॉर्ड उनके इंफ़्रास्ट्रक्चर का बयान है, आपके ट्रैफ़िक का नहीं, और उतना ही क़ीमती है जितनी उनकी रिटेंशन विंडो और देखने की इच्छा। यह एक सत्र का भी बयान है, अनुरोध का नहीं। विंडो आम तौर पर छोटी होती है, और टनल के प्रदाता की तरफ़ से नापी जाती है।
जो प्रदाता लॉग न रखने का दावा करते हैं वे माँगने पर यह नहीं दे सकते, और क्लाइंट की तरफ़ की हाल की जगहों की सूची अलग चीज़ है। बिना लॉग वाले प्रदाता से एग्ज़िट पता माँगना आम तौर पर इस समझाइश पर खत्म होता है कि यह डेटा क्यों मौजूद नहीं है।
सपोर्ट केस में हर रिकॉर्ड क्या साबित कर सकता है
दोनों रिकॉर्ड अलग सवालों का जवाब देते हैं, और तालिका में ही तुलना शैक्षणिक रहना छोड़ देती है।
| Question | Your local log | Provider record |
|---|---|---|
| Which address did the traffic leave from? | Yes, for the moment it was captured | Usually not disclosed |
| Was the tunnel in use at 14:20? | Yes, if the capture ran | Yes, within the retention window |
| Why did a location get slower? | Yes, by comparing addresses over time | Sometimes, as an infrastructure note |
| Who sent this specific request? | No | No |
सिर्फ़ पहला कॉलम आपके नियंत्रण में है। प्रदाता का रिकॉर्ड पुष्टि कर सकता है कि कोई खाता किसी समय जुड़ा था, लेकिन यह नहीं बता सकता कि किन अनुरोधों ने टनल इस्तेमाल किया, और ऐसा पता नहीं बताएगा जिसे प्रदाता परिचालन बारीकी मानता हो। कोई भी रिकॉर्ड किसी व्यक्ति की पहचान नहीं करता, क्योंकि साझा एग्ज़िट पता एक ही मिनट में कई ग्राहक उठा सकता है।
किसी एक पर भरोसा करने से पहले दोनों की तुलना आधार-रेखा से करें
अकेला पता कुछ साबित नहीं करता। कनेक्ट होने से पहले सीधा पता, और बाद में टनल वाला पता कैप्चर करें, और उनकी तुलना करें। एक जैसे मान का मतलब है कि टनल वह अनुरोध नहीं ले जा रहा, चाहे विभाजित टनल हो, हावी प्रॉक्सी हो या ऐसा क्लाइंट जो सीधे रास्ते पर लौट गया हो।
curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1
DNS और IPv6 के लिए तुलना दोहराएँ, क्योंकि पते की गूँज एक HTTP अनुरोध का रास्ता साबित करती है और इस बारे में कुछ नहीं कि किस रिज़ॉल्वर ने जवाब दिया। एक में लीक होने वाला डिवाइस दूसरे में पूरी तरह स्वस्थ दिख सकता है।