IPv6 गोपनीयता ठेगानाहरू वा RDP अनुमति सूची: सम्झौता छान्नुहोस्

टाढाको डेस्कटप पहुँच एक महिना चल्यो, त्यसपछि अनुमति सूची कसैले देख्न सक्ने कारण बिना मिल्न छोड्यो। होस्ट सरेको थिएन र फायरवालमा केही पनि सम्पादन गरिएको थिएन। Windows अनियमित इन्टरफेस पहिचानकर्ताहरूसँग IPv6 अस्थायी ठेगानाहरू बनाउँदै र तिनलाई फिर्ता लिँदै गर्छ, त्यसैले सर्भरले कुनै पनि दिन देख्ने स्रोत ठेगाना कसैले नियममा नलेखेको हुन सक्छ। त्यो व्यवहार बन्द गर्दा मिलान सुधारिन्छ र एकैसाथ होस्ट दीर्घकालीन पहिचानकर्ता बन्छ। दोस्रो आधा स्वीकार गर्नु अघि विकल्पहरू तौल्नुहोस्।

नियम किन मिल्न छोड्यो

RFC 4941 अस्थायी ठेगानाहरू वर्णन गर्छ: होस्टले अनियमित पहिचानकर्तासहित थप ठेगानाहरू बनाउँछ र तिनलाई फिर्ता लिन्छ, जसले पर्यवेक्षकलाई एउटै होस्टलाई भ्रमणहरूबीच सम्बन्धित गर्नबाट रोक्छ। Windows त्यो व्यवहार लागू गर्छ, त्यसैले हिजोको स्रोत ठेगाना आजको हुनैपर्छ भन्ने छैन। अनुमान गर्न सकिने ठेगाना इन्टरफेसमा अझै छ; बाहिर जाने जडानले प्राथमिकता दिने त्यो होइन।

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

विकल्प एक: एउटा स्थिर ठेगाना, कम गोपनीयता

सामान्य मर्मतले होस्टमा दुवै घुमाउने संयन्त्र बन्द गर्छ: netsh interface ipv6 set privacy state=disabled store=persistent र netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent। पुनः सुरु हुने पर्खाइ बिना परिवर्तन लागू होस् भन्ने चाहनुहुन्छ भने store=active थप्नुहोस्, र पहिचानकर्तालाई अब सञ्जालहरूबीच अनुमान गर्न सकिने बनाउनुभएको स्वीकार गर्नुहोस्।

त्यही अनुमानयोग्यता नै विस्तारहरूले रोक्न बनाइएका थिए। होस्टलाई क्याफेबाट कार्यालय र घरसम्म पछ्याउने ठेगाना सुविधाजनक फिल्टर कुञ्जी हो र त्यत्तिकै सुविधाजनक ट्र्याकिङ कुञ्जी, र दोस्रो गुण पहिलो माग्ने टिकटभन्दा लामो बाँच्छ।

विकल्प दुई: प्रिफिक्स वा नामलाई अनुमति दिनुहोस्

पूरा ठेगानाको सट्टा /64 लाई अनुमति दिँदा घुमाइ अक्षुण्ण रहन्छ र कमजोर तर प्रायः इमानदार दाबीसँग मेल खान्छ: यो मेसिन मेरो घरको सञ्जालमा छ। त्यो प्रिफिक्समा तपाईंले स्वीकार नगर्ने होस्टहरू भएको क्षणदेखि यो पर्याप्त हुन छोड्छ, र उपभोक्ता जडानमा यो सामान्यतया मानिसहरूले सोचेभन्दा सानो समूह हुन्छ। गतिशील DNS मार्फत प्रकाशित नाम चलाउन सजिलो हुन्छ, किनकि रेकर्डले होस्टलाई पछ्याउँछ र नीति पहिचानको रूपमा पढिन्छ, प्रत्येक उपकरण थप्दा बढ्ने दायराको रूपमा होइन।

दुवै विकल्पलाई सर्भरले विश्वास गर्न सक्ने रिजोल्भर र सजिलै नक्कली बनाउन नसकिने नाम चाहिन्छ, त्यसैले तिनलाई नियमको सौन्दर्यपरक परिवर्तन होइन, पहिचानबारे नीतिगत निर्णय मान्नुहोस्। त्यो नामलाई कुन रिजोल्भरले जवाफ दिन्छ लेख्नुहोस्, किनकि नियम त्यसपछाडिको रेकर्डजत्तिकै विश्वसनीय हुन्छ।

विकल्प तीन: सुरुङले ठेगाना तोक्न दिनुहोस्

यदि जडान तपाईंले नियन्त्रण गर्ने VPN मार्फत जान्छ भने, सर्भरले आफ्नै पूलबाट ठेगाना दिन सक्छ, र अनुमति सूचीले त्यसपछि ग्राहकले रुचाउने नभई सर्भरले छान्ने मानलाई सन्दर्भ गर्छ। यो व्यवस्थापित ग्राहकहरूका लागि राम्रो काम गर्छ र ग्राहकले अतिक्रमण गर्न सक्ने जुनसुकै कुराका लागि नराम्रो, त्यसैले तपाईंको तैनाथीमा कुन पक्षले साँच्चै जित्छ जाँच्नुहोस्।

निर्णयलाई ठेगानाबाट पूर्ण रूपमा टाढा सार्ने, ग्राहक प्रमाणपत्र वा प्रमाणित गेटवेतर्फ, त्यो विकल्प हो जुन स्केल हुन्छ, किनकि यो अपरेटिङ सिस्टमसँग परिवर्तन गर्ने अधिकार भएको मानमा निर्भर रहन छोड्छ।

ट्र्याकिङ खर्चलाई ध्यानमा राखेर छान्नुहोस्

चारै विकल्पलाई वास्तविक आवश्यकतासामु लेख्नुहोस्, र तिनलाई जोड्नुको सट्टा एउटा छान्नुहोस्। यदि तपाईंले जेसुकै भए पनि गोपनीयता बन्द गर्नुहुन्छ भने, यसलाई आवश्यक पर्ने होस्टमा सीमित गर्नुहोस्, कारण नियमको छेउमा अभिलेख गर्नुहोस्, र प्लेटफर्मले समर्थन गर्ने ठाउँमा RFC 7217 को स्थिर-गोपनीय ठेगाना निर्धारण विचार गर्नुहोस्, किनकि यसले हार्डवेयरबाट व्युत्पन्न पहिचानकर्ता नखुलाई प्रत्येक प्रिफिक्सका लागि पहिचानकर्ता राख्छ। अनुमति सूची परिवर्तन भएपछि विस्तारहरू फेरि सक्षम गर्नुहोस्।

परिवर्तनलाई यसले समर्थन गर्ने नियमको छेउमा अभिलेख गर्नुहोस्। त्यो टिप्पणी बिना अर्को प्रशासकले गोपनीयता विस्तार बन्द र कुनै व्याख्या नभएको होस्ट भेट्छ, र सफाइका क्रममा तिनलाई फेरि खोल्छ।