VPN ने आपका पुराना IP लीक नहीं किया: एक याद रखा मान ने किया

VPN के चालू होने के बाद किसी सेवा की रिपोर्ट में अपना पुराना सार्वजनिक पता देखना अपने आप में लीक का प्रमाण नहीं है। जीवित कनेक्शन टनल एग्ज़िट का उपयोग कर सकता है जबकि ऐप वह मान भेज रहा हो जो उसने टनल बनने से पहले सीखा था। ये दो अलग प्रमाण हैं, और इनमें से केवल एक वर्तमान पैकेट का वर्णन करता है। दूसरा वह मान है जो पुनः कनेक्ट से बच गया क्योंकि नेटवर्क पथ पर कोई उसका स्वामी नहीं है।

एक पते के पीछे की दो व्याख्याएँ

जो क्रम लोग कल्पना करते हैं वह भौतिक इंटरफ़ेस छोड़ता एक पैकेट है जबकि VPN कथित रूप से सक्रिय है। जो क्रम अक्सर रिपोर्ट को समझाता है वह छोटा और नीरस है: किसी ऐप ने पहले पता सीखा और अब भी उसे रखे हुए है। घटनाओं को क्रम में रखना दोनों को अलग करता है।

Address learned before the tunnel: P1
Tunnel up: the next request exits at P2
Application reuses its retained P1 in a message body
Receiver logs source P2 and submitted value P1

उस क्रम में कुछ भी पहले पते से जीवित कनेक्शन की माँग नहीं करता। याद रखा मान संदेश के भीतर यात्रा करता है, जबकि हेडर वह एग्ज़िट ले जाता है जो वर्तमान रूट ने चुना। दोनों फ़ील्ड लॉग करने वाली सेवा उन्हें साथ-साथ दिखाएगी और विरोधाभासी लगेगी।

यह एक संभावित व्याख्या है, किसी विशेष क्लाइंट पर आरोप नहीं। प्रतिष्ठा प्रमाण नहीं है: आप जो कोड पढ़ सकते हैं, जिस ब्रांड पर भरोसा करते हैं या कोई भिन्न एग्ज़िट, यह नहीं बताते कि किसी एक प्रोग्राम ने क्या रखा या भेजा।

ऐप की स्मृति पुनः कनेक्ट से अधिक टिकती है

VPN जोड़ना उस रूट को बदलता है जो नया कनेक्शन लेता है। यह ऐप की स्थिति को अछूता छोड़ता है और उस जानकारी को वापस नहीं खींच सकता जो किसी दूरस्थ सेवा ने पहले ही संग्रहीत कर ली है। कोई प्रोग्राम खाता पहचानकर्ता, सहेजा गया स्थान, डिवाइस नाम या पहले प्राप्त कोई अन्य मान भेज सकता है, और एन्क्रिप्शन उस पेलोड को रास्ते में सुरक्षित रखता है, उसमें से कुछ हटाए बिना। पुनः कनेक्ट एक नेटवर्क घटना है; रखा गया मान ऐप की घटना है।

अंतर मायने रखता है क्योंकि दोनों अलग-अलग जगहों पर रहते हैं। ऐप की स्थिति प्रोग्राम की है और पुनः आरंभ से बची रहती है, जबकि रूट ऑपरेटिंग सिस्टम का है और हर कनेक्शन पर फिर से बनता है। एक को साफ़ करने का दूसरे पर कोई असर नहीं होता।

कोई सेवा वह मान भी रख सकती है जो आपने उसे महीनों पहले दिया था, और उस स्थिति में कोई स्थानीय बदलाव उसे नहीं हटाएगा। यह प्रतिधारण है, और यह टनल से पूरी तरह बाहर है।

पहले स्रोत हेडर पढ़ें, फिर पेलोड

शुरुआत यह तय करने से करें कि पता कहाँ दिखा। सर्वर का कनेक्शन लॉग जीवित स्रोत का वर्णन करता है, जबकि कोई संदेश फ़ील्ड, खाता प्रोफ़ाइल या स्थानीय निदान स्क्रीन बहुत पहले भेजे या सहेजे गए मान का वर्णन कर सकती है। वे अवलोकन अलग-अलग प्रश्नों का उत्तर देते हैं।

समयों की भी तुलना करें। यदि पुराना पता VPN कनेक्शन से पहले के किसी फ़ील्ड में दिखता है, तो पेलोड वाली व्याख्या अधिक मज़बूत है। यदि सर्वर टनल चालू रहते हुए पुराने पते से सीधा कनेक्शन दर्ज करता है, तो यह रूटिंग का प्रश्न है और इसके लिए अलग जाँच चाहिए। पहले अवलोकन के प्रकारों को क्रमबद्ध करना एक पते को तीन घटनाओं के प्रमाण तक खींचे जाने से रोकता है।

उन्हें अपने नोट्स में अलग रखें: कनेक्शन स्रोत, संदेश फ़ील्ड, खाता प्रदर्शन, स्थानीय निदान। चार जगह लिखा एक पता अब भी एक पता है।

प्रतिधारण परिवहन से भिन्न चरण है

RFC 6973 में गोपनीयता मार्गदर्शन संग्रह, उपयोग, प्रकटीकरण और प्रतिधारण को अलग चरण मानता है और चेतावनी देता है कि पुनः उपयोग किए गए पहचानकर्ता सहसंबंध आसान बनाते हैं। नया नेटवर्क पथ परिवहन चरण बदलता है और कुछ नहीं। प्राप्तकर्ता के पास पहले से मौजूद रिकॉर्ड अछूते रहते हैं, और वह प्रोफ़ाइल भी जिसने प्रवेश पर मान सहेजा था। इसलिए परिवहन के सही ढंग से काम करते हुए भी पुनः कनेक्ट विफल महसूस हो सकता है।

कोई पैकेट फ़िल्टर प्राप्तकर्ता के रिकॉर्ड से मान नहीं मिटा सकता, और दोबारा कनेक्ट करने से हर प्रोग्राम का सहेजा इतिहास साफ़ नहीं होगा। ये टनल की नहीं, डेटा-स्वामी की समस्याएँ हैं, और इनके लिए अलग तरह का समाधान चाहिए। नेटवर्क से इसे छिपाने को कहने से पहले सेवा से पूछें कि वह क्या और कितने समय तक रखती है।

टनल को दोष देने से पहले क्या जाँचें

ऐप के प्रलेखित संग्रह और खाता नियंत्रणों की समीक्षा करें, और तय करें कि वह कौन-से फ़ील्ड भेज सकता है, सेवा उन्हें कितने समय तक रखती है, और क्या खाता उन्हें साफ़ या सुधार सकता है। फिर वह परीक्षण चलाएँ जो व्याख्याओं को अलग करता है: नया खाता या साफ़ ऐप प्रोफ़ाइल। यदि पुराना मान गायब हो जाए, तो प्रतिधारण या कैश की गई स्थिति शामिल थी। यदि वह साफ़ प्रोफ़ाइल में बना रहे, तो यह निष्कर्ष निकालने से पहले कि VPN विफल हुआ, वास्तविक अनुरोध फ़ील्ड की जाँच करें।

यदि वास्तव में सीधा कनेक्शन मौजूद है, तो उसे नेटवर्क पथ का निष्कर्ष मानें। रूटिंग, विभाजित टनल और क्लाइंट नीति की उनकी अपनी शर्तों पर जाँच करें, और उस परिणाम को उस पेलोड मान से न मिलाएँ जो बस पुनः कनेक्ट से बच गया। दोनों विफलताएँ स्क्रीनशॉट में एक जैसी दिखती हैं और कैप्चर में बिल्कुल अलग व्यवहार करती हैं।