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 मा हुनु पहुँच नीति होइन।
तैनाथी पछिको परीक्षण निरस र निर्णायक छ: अनुमति दिइएको पूर्वसर्गभित्र एउटा अनुरोध सफल हुन्छ, गेटवेमा काउन्टर बढ्छ, र पूर्वसर्गबाहिर एउटा जानाजान गरिएको प्रयास असफल हुन्छ।