VPN क्लायंट के लिए सार्वजनिक प्रीफ़िक्स: यह वास्तव में क्या तोड़ता है

संख्याएँ साफ़ दिखती हैं इसलिए चुना गया क्लायंट पूल एक ऐसा रूट है जो इंस्टॉल होने का इंतज़ार कर रहा है। VPN के काम करने के लिए प्रीफ़िक्स का निजी होना ज़रूरी नहीं है, और किसी और के ब्लॉक का उपयोग करना भी आपके उपयोगकर्ताओं को अपने आप इंटरनेट पर उजागर नहीं करता। यह जो करता है वह यह है कि सुरंग ऊपर रहने तक उन पतों का अर्थ कुछ और हो जाता है, और फिर सुरंग गिरने पर फिर कुछ और। नीचे दी गई पाँच जाँचें क्रम से करें और वहीं रुकें जहाँ उत्तर «कहीं और आवंटित» हो।

आवंटन घोषणा नहीं है

सुरंग इंटरफ़ेस पर पता रखना उसे इंटरनेट पर घोषित नहीं करता। सार्वजनिक पहुँच के लिए रूट, अधिकृत मार्ग और उसे ढोने को तैयार प्रदाता चाहिए, और इनमें से कोई भी इसलिए नहीं आता कि किसी क्लायंट को पूल से पता मिला है। फ़ायरवॉल नीति और होस्ट प्राधिकरण फिर से अलग निर्णय हैं।

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

पूल चुनते समय यह अंतर मायने रखता है। अगर आपकी एकमात्र चिंता इंटरनेट पर उजागर होना होती, तो सार्वजनिक ब्लॉक सुरक्षित लगता क्योंकि उसे कोई घोषित नहीं करता। चिंता उस स्थानीय रूट की है जो क्लायंट उस प्रीफ़िक्स के लिए इंस्टॉल करता है, और वह रूट इस बात की परवाह किए बिना इंस्टॉल होता है कि कोई और उसे देख सकता है या नहीं।

क्लायंट रूट वास्तव में क्या पकड़ता है

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

ip route get 198.51.100.20
ip -br addr show tun0
traceroute -n 198.51.100.20

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

इसीलिए कोई परिचित IP पता पहचान का प्रमाण नहीं है। असली गंतव्य के लिए प्रमाणपत्र और सर्वर-नाम सत्यापन रखें, क्योंकि पाँच मिनट पहले आप जिस संख्यात्मक पते पर पहुँचे थे वह अब किसी और बातचीत का हो सकता है।

पूल की तुलना हर उस नेटवर्क से करें जिसे आप जानते हैं

RFC 1918 निजी उपयोग के लिए तीन ब्लॉक अलग रखता है: 192.168.0.0/16, 172.16.0.0/12 और 10.0.0.0/8। लाखों अलग संगठन इन्हें फिर से उपयोग करते हैं, इसलिए «निजी» आवंटन के बारे में एक कथन है और कभी यह वादा नहीं कि किसी और ने वही संख्याएँ नहीं चुनीं।

उम्मीदवार पूल की तुलना कार्यालय LAN, क्लाउड VPC, अन्य VPN पूल, साझेदार लिंक और उन रेंजों से करें जो दूरस्थ कर्मचारियों के घर पर होने की संभावना है। घर का मामला अजीब प्रीफ़िक्स गढ़ने का कारण नहीं है; यह पूल को छोटा और प्रलेखित रखने का कारण है।

आवंटन को उस व्यक्ति के साथ समन्वित करें जो रूटिंग का मालिक है, और वापसी मार्ग उसी जगह दर्ज करें। जिस पूल पर कोई वापस रूट नहीं कर सकता वह ऐसा पूल है जिसे किसी व्यवधान के दौरान फिर से खोजा जाएगा। पूल को साइट रेंजों वाले उसी दस्तावेज़ में रखें, ऐसी क्लायंट कॉन्फ़िगरेशन में नहीं जिसे केवल एक व्यक्ति ने संपादित किया हो। दस्तावेज़ ही अगली टक्कर को टालने योग्य बनाता है।

सार्वजनिक एड्रेसिंग कब सही उत्तर है

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

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

पूल चुनाव की भरपाई के लिए अपने आप NAT न जोड़ें। स्पष्ट वापसी रूट वाला रूटेड निजी डिज़ाइन उस अनुवाद से साफ़ है जो इसलिए लगाया जाता है कि एड्रेसिंग की योजना कभी बनी ही नहीं, और IPv6 को IPv4 की मान्यताओं की नकल के बजाय अपनी जानबूझकर बनी योजना चाहिए।

पहुँच खोए बिना खराब पूल को सेवानिवृत्त करें

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

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

आप एक ऐसा पूल चाहते हैं जिसे नेटवर्क टीम एक सुसंगत चीज़ के रूप में आवंटित, रूट और सेवानिवृत्त कर सके। पता प्रारूप अपने आप में न सुरक्षा स्थापित करता है न कनेक्टिविटी।