VPN के पीछे IoT सेंसर लगाने से पहले तीन पता निर्णय
तीन पते तीन काम करते हैं: सार्वजनिक हब, प्रमाणित साइट पीयर और सेंसर का निजी पता। कुछ भी सार्वजनिक आवंटित करने से पहले हर एक की योजना बनाएँ।
हर IoT-से-VPN योजना में तीन पते उलझ जाते हैं, और वे एक ही तरह का निर्णय नहीं हैं। एक यह है कि दूरस्थ ऑपरेटर टनल का अंतिम बिंदु कैसे ढूँढता है, एक यह है कि साइट कैसे साबित करती है कि वही साइट है, और एक यह है कि सेंसर की सेवा वास्तव में कहाँ सुनती है। उन्हें उसी क्रम में उत्तर दें और डिज़ाइन लगभग अपने आप निकल आता है। उन्हें एक ही प्रश्न के रूप में उत्तर दें और आप ऐसे उपकरणों को सार्वजनिक पते आवंटित करने तक पहुँच जाएँगे जिन्हें कभी इसकी आवश्यकता नहीं थी। आउटबाउंड साइट टनल के पीछे का सेंसर अधिकृत ऑपरेटर के लिए सेंसर की ओर इशारा करने वाले किसी भी इनबाउंड नियम के बिना पहुँच योग्य है।
शुरुआत इससे करें कि कौन शुरू करता है
कौन डायल करता है यह लगभग सब कुछ तय करता है। जब साइट हब की ओर डायल करती है, तो साइट को किसी इनबाउंड पहुँच की आवश्यकता नहीं होती, और हब को ऐसा नाम या पता चाहिए जिसे साइट हल कर सके। यह एक चुनाव स्थिर सार्वजनिक पता-निर्धारण की अधिकांश बहस को शुरू होने से पहले ही हटा देता है।
फिर तीन भूमिकाएँ स्पष्ट रूप से अलग हो जाती हैं, और नीचे दी गई तालिका निर्णय का सबसे छोटा रूप है।
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
हर पंक्ति का अलग स्वामी है, और यही असली बात है। हब उसका है जो VPN सेवा चलाता है, साइट पीयर नेटवर्क टीम का, और सेंसर का पता उसका जो उपकरण रखता है।
हब का पता बूटस्ट्रैप है, गंतव्य नहीं
ऐसा नाम जो बनाए रखे गए सार्वजनिक पते पर हल हो, हब के लिए पर्याप्त है। DNS रिकॉर्ड अंतिम बिंदु के स्थानांतरित होने पर उसका अनुसरण कर सकता है, बिना हर साइट कॉन्फ़िगरेशन को हाथ से संपादित किए। DNS जो नहीं करता है वह है पहुँच बनाना या पुराने उत्तर को कैश करने वाले क्लाइंट को ताज़ा करना, और ये अलग समस्याएँ हैं अलग समाधानों के साथ।
यदि आप बिना हब के साइट-से-साइट टनल चलाते हैं, तो वही तर्क दूसरे रूप में लागू होता है: एक पक्ष को पहुँच योग्य अंतिम बिंदु चाहिए, या दोनों पक्ष किसी तीसरे पक्ष को डायल करते हैं। किसी को फिर भी उस पते और उसके नवीनीकरण का स्वामी होना पड़ता है।
साइट पीयर एक पहचान है जिसके साथ प्रीफ़िक्स जुड़ा है
पीयर पहले पहचान है और दूसरे प्रीफ़िक्स। WireGuard की शर्तों में पीयर एक कुंजी-युग्म रखता है और हब की AllowedIPs प्रविष्टि उस कुंजी को साइट के प्रीफ़िक्स से बाँधती है। IKEv2 की शर्तों में प्रमाणपत्र या पहले से साझा कुंजी साइट की पहचान करती है और उसके ट्रैफ़िक चयनकर्ता बताते हैं कि वह क्या वहन कर सकती है। केवल एक आधा बदलने से व्यवस्था टूट जाती है, इसलिए पता परिवर्तन को कभी पहचान परिवर्तन नहीं माना जाना चाहिए।
कुंजी या प्रमाणपत्र का स्वामित्व साइट के पास रखें, हब ऑपरेटर के पास नहीं, ताकि प्रदाता बदलना पहचान बदलना न बन जाए।
प्रीफ़िक्स वह हिस्सा है जिसकी योजना बनाना लोग भूल जाते हैं। हब को सेंसर सबनेट को सही पीयर से जोड़ना होता है, और ऑपरेटर के क्लाइंट को उसके लिए मार्ग चाहिए; जो मार्ग केवल क्लाइंट पर है वह ट्रैफ़िक को ऐसी टनल में भेजता है जो उसे चुपचाप गिरा देती है। कुंजी फ़िंगरप्रिंट के बगल में साइट रिकॉर्ड में प्रीफ़िक्स लिखें, ताकि बदला गया गेटवे बिना किसी के ध्यान दिए अलग कवरेज के साथ न आ सके।
सेंसर का पता एप्लिकेशन का है
साइट की योजना से एक निजी पता पर्याप्त है, और उसे सार्वजनिक पहुँच नहीं बल्कि स्थिरता चाहिए: DHCP आरक्षण, स्थिर आवंटन, या साइट के अपने ज़ोन में नाम। यदि उपकरण को फिर से क्रमांकित नहीं किया जा सकता, तो साइट गेटवे पर अनुवाद वैध उत्तर है, जब तक अनुवाद दस्तावेज़ीकृत हो और वापसी ट्रैफ़िक उसका अनुसरण करे।
एक और आदत जो रखने योग्य है: सेंसर के होस्ट पर अगले-हॉप फ़ील्ड में कभी सार्वजनिक हब पता न चिपकाएँ। VPN अपना रास्ता स्थापित करता है, और किसी सार्वजनिक अंतिम बिंदु से साधारण ईथरनेट सामीप्य एक कल्पना है जो विश्वसनीय दिखने वाला कॉन्फ़िगरेशन बनाती है।
उत्तर वह आधा हिस्सा हैं जो छूट जाता है। उपकरण को अपना उत्तर टनल की ओर वापस भेजना होता है, या तो ऑपरेटर के क्लाइंट तक मार्ग से या उसी गेटवे से जिसने अनुरोध का अनुवाद किया। गलत डिफ़ॉल्ट गेटवे वाला सेंसर अनुरोध स्वीकार करता है और खाली में उत्तर देता है, और फ़ॉरवर्डिंग नोट्स बताते हैं कि आगमन और उत्तर रूटिंग एक नहीं बल्कि दो आवश्यकताएँ क्यों हैं।
निर्णय लें, फिर सीमा लिखें
किसी के जुड़ने से पहले पहुँच सीमा लिखें। गेटवे को IoT खंड और ऑपरेटर को आवश्यक विशिष्ट सेवाओं तक सीमित रखें, क्योंकि काम करने वाला मार्ग संयोग से सामान्य पहुँच बन जाता है। केवल-पढ़ने की निगरानी और कॉन्फ़िगरेशन अधिकार को अलग-अलग पहचान वाली अलग भूमिकाओं के रूप में रखें, और अनुबंध समाप्त होने पर पहुँच हटाने वाले व्यक्ति का नाम लिखें।
स्वीकृति नेटवर्क स्वामी की है, और DMZ में होना पहुँच नीति नहीं है।
तैनाती के बाद का परीक्षण उबाऊ और निर्णायक है: अनुमत प्रीफ़िक्स के भीतर एक अनुरोध जो सफल होता है, गेटवे पर बढ़ता एक काउंटर, और प्रीफ़िक्स के बाहर एक जानबूझकर किया गया प्रयास जो विफल होता है।