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 च्या स्थिर-गोपनीय पत्ता नियुक्तीचा विचार करा, कारण ती हार्डवेअरमधून घेतलेला ओळखकर्ता उघड न करता प्रत्येक उपसर्गासाठी ओळखकर्ता ठेवते। अनुमती यादी बदलल्यावर एक्स्टेंशन्स पुन्हा सक्षम करा।

बदल त्याला आधार देणाऱ्या नियमाच्या शेजारी नोंदवा। त्या टिपेशिवाय पुढील प्रशासकाला गोपनीयता एक्स्टेंशन्स बंद आणि कोणतेही स्पष्टीकरण नसलेला होस्ट सापडतो, आणि साफसफाई करताना ते पुन्हा सुरू करतो।