VPN मधील IPv6 ULA: खाजगी पत्ते, गोपनीयता नाही

खाजगी दिसणारे पत्ते बहुतेक लोक ज्या अर्थाने म्हणतात त्या अर्थाने खाजगी नाहीत, आणि IPv6 चे अद्वितीय-स्थानिक पत्तेपण हे त्याचे सर्वात स्पष्ट उदाहरण आहे। ULA प्रीफिक्स VPN ला त्याच्या मागील संसाधनांसाठी स्थिर अंतर्गत आराखडा देतो। तो काहीही कूटबद्ध करत नाही, कोणत्याही पीअरचे प्रमाणीकरण करत नाही आणि क्लायंट कोणत्या सेवांपर्यंत पोहोचू शकतो हे ठरवत नाही। प्रीफिक्सला सुरक्षा नियंत्रण मानणे ही अशी चूक आहे जी हा लेख दूर करू इच्छितो।

प्रीफिक्स प्रत्यक्षात काय देते

RFC 4193 स्थानिक वापरासाठी fc00::/7 वेगळे ठेवतो, आणि L बिट स्थानिकरीत्या वाटप केलेली जागा राखीव स्वरूपापासून वेगळा करतो। प्रत्यक्षात याचा अर्थ असा की तुम्ही fd00::/8 तयार करता। विनिर्देश हे देखील ठरवतो की 40-बिट जागतिक ID कसा काढावा, जेणेकरून स्वतंत्र साइट्स चुकून तोच प्रीफिक्स निवडणार नाहीत। ती जागा सार्वजनिक इंटरनेटबाहेर राहण्यासाठी रचलेली आहे, हा राउटिंगचा गुणधर्म आहे, संरक्षण नाही।

साइटच्या आत नेहमीची मांडणी सबनेटमध्ये विभागलेला /48 जागतिक ID आहे: एक टनेल क्लायंटसाठी, एक सर्व्हर बाजूसाठी आणि प्रत्येक दूरच्या LAN साठी एक। ती रचना हाच संपूर्ण फायदा आहे, आणि तो पत्तेपणाचा फायदा आहे। प्रत्येक पॅकेटला अजूनही मार्ग हवा आणि त्याला परवानगी देणारे धोरण हवे।

प्रीफिक्स टनेलशी गोंधळणे हा असा मार्ग आहे ज्यामुळे रचना fd00 पत्ते दस्तऐवजीकरण करते आणि त्यांच्यातील रहदारी संरक्षित असल्याचे गृहीत धरते। दुसरे काही संरक्षण देत नसेल तर ते संरक्षित नाही।

उदाहरणातील प्रीफिक्स कॉपी करणे का त्रासदायक आहे

प्रत्येक ट्युटोरियल स्मरणार्थ सोपा प्रीफिक्स वापरते, आणि तो कॉपी करणारा प्रत्येक वाचक तोच टक्कर जोखीम वारसाने मिळवतो। नंतर समान श्रेणींसह साइट-ते-साइट टनेलद्वारे जोडल्या जाणाऱ्या दोन साइट्स ओव्हरलॅपिंग खाजगी IPv4 जागेतून ज्ञात असलेली तीच संदिग्धता निर्माण करतात। कोणतीही बाजू स्वतः चुकीची नाही, आणि एकत्रित नेटवर्कला कोणते गंतव्य अभिप्रेत आहे हे जाणून घेण्याचा मार्ग नाही।

दस्तऐवजीकृत प्रक्रियेनुसार जागतिक ID तयार करण्यास एक मिनिट लागते आणि प्रश्न निघून जातो। पत्ता आराखड्याजवळ प्रीफिक्स, निर्मिती इनपुट आणि तारीख नोंदवा।

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

व्याप्ती आणि प्रवेश वेगवेगळे प्रश्न आहेत

ULA सामान्य जागतिक राउटेड इंटरनेट पत्तेपणासाठी नाही। त्यामुळे ते वापरणारा प्रत्येक होस्ट विश्वासार्ह होत नाही आणि त्या होस्ट्स इतर जोडलेल्या खाजगी नेटवर्कमधून अगम्य होत नाहीत। फायरवॉल आणि अनुप्रयोग परवानग्या अजूनही पीअर काय वापरू शकतो हे ठरवतात, आणि टनेल अजूनही ज्या प्रमाणीकरणासह तो संरचित होता ते देतो।

इंटरनेट निर्गमासाठी स्वतःची IPv6 निर्गम रचना हवी। क्लायंटला ULA पत्ता देणे अनियंत्रित जागतिक गंतव्यांपर्यंत प्रवेश निर्माण करत नाही, आणि असा पत्ता मिळालेल्या क्लायंटने त्यातून सार्वजनिक इंटरनेट ब्राउझ करण्याची अपेक्षा ठेवू नये।

वेगवेगळ्या प्रीफिक्स असलेल्या दोन साइट्सना अजूनही एकमेकांच्या श्रेणींसाठी परतीचे मार्ग हवेत, आणि दोन्ही फायरवॉलना जुळणारे नियम हवेत। यातील काहीही पत्ता कुटुंबातून येत नाही। जे येते ते दस्तऐवजीकरणाचे काम आहे: प्रीफिक्सचा तक्ता आणि प्रत्येकावर उत्तर देण्यास परवानगी असलेल्या प्रणाली।

दोन्ही टोकांवर आराखडा तपासा

प्रीफिक्स तुम्हाला वाटते तिथे दिसतो याची खात्री करा, नंतर गंतव्य खरोखर त्यातून पोहोचण्यायोग्य आहे याची खात्री करा।

ip -6 address show
ip -6 route show
ping -6 -c 3 fd12:3456:789a:1::1

पत्त्यांची यादी दाखवते की कोणत्या इंटरफेसकडे कोणते सबनेट आहे, आणि चुकीचे मिळालेला क्लायंट सहसा ते इथे दाखवतो। मार्गांची यादी दाखवते की दूरच्या प्रीफिक्सला टनेलमधून वाट आहे की तो टाकून दिला जातो। चाचणी एकाच महत्त्वाच्या प्रश्नाचे उत्तर देते: पॅकेट ये-जा करते का।

पुन्हा जोडल्यानंतर तपासणीची पुनरावृत्ती करा, कारण जो क्लायंट पत्ता ठेवतो पण मार्ग गमावतो तो वर दिसणारे आणि काहीही पुढे न पाठवणारे कनेक्शन तयार करतो। पत्ता सोपा भाग आहे, आणि मार्ग हा हरवणारा भाग आहे। पुढील तुलना पुराव्यापासून सुरू व्हावी म्हणून दोन्ही आउटपुट कनेक्शन प्रोफाइलच्या नावाजवळ साठवा।