VPN ले तपाईंको पुरानो IP चुहाएन: सम्झिएको मानले त्यो गर्यो
नयाँ जडानले VPN निकास प्रयोग गर्दा पनि कुनै सेवाले तपाईंको पुरानो सार्वजनिक ठेगाना रिपोर्ट गर्न सक्छ। प्याकेटको स्रोत हेडरलाई एपले राखेको मानबाट अलग गर्नुहोस्।
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 असफल भयो भन्ने निष्कर्ष निकाल्नुअघि वास्तविक अनुरोध क्षेत्र जाँच्नुहोस्।
साँच्चै सिधा जडान छ भने, त्यसलाई सञ्जाल मार्गको खोजका रूपमा लिनुहोस्। राउटिङ, विभाजित टनेल र क्लाइन्ट नीतिको तिनका आफ्नै सर्तमा अनुसन्धान गर्नुहोस्, र त्यो नतिजालाई पुनः जडानबाट बाँचेको पेलोड मानसँग नमिसाउनुहोस्। दुवै विफलता स्क्रिनसटमा उस्तै देखिन्छन् र क्याप्चरमा पूर्ण रूपमा फरक व्यवहार गर्छन्।