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 मध्ये असणे ही प्रवेश धोरण नाही।
उपयोजनानंतरची चाचणी कंटाळवाणी आणि निर्णायक आहे: परवानगी दिलेल्या उपसर्गातील एक विनंती यशस्वी होते, गेटवेवर काउंटर वाढतो, आणि उपसर्गाबाहेर एक जाणीवपूर्वक प्रयत्न अयशस्वी होतो।