वापरलेला 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 विनंतीचा मार्ग सिद्ध करते आणि कोणत्या रिझॉल्व्हरने उत्तर दिले याबद्दल काहीही सांगत नाही। एकात गळती असलेले उपकरण दुसऱ्यात पूर्णपणे निरोगी दिसू शकते।