Apple MDM साठी VPN आवश्यक आहे का? तीन प्रवेश गरजा, एक उत्तर
Apple MDM APNs आणि डिव्हाइसने सुरू केलेल्या HTTPS वर चालते, LAN टनेलवर नाही. VPN जोडण्यापूर्वी व्यवस्थापन, स्क्रीन शेअरिंग आणि खाजगी अ‍ॅप प्रवेश वेगळे करा.
Apple उपकरण व्यवस्थापनाला एन्क्रिप्शन आवश्यक आहे का हा प्रश्न क्वचितच विचारला जातो, कारण ते आवश्यक आहे। खरा प्रश्न असा आहे की Mac किंवा iPad व्यवस्थापित करण्यापूर्वी तुमच्या ताफ्याला सामान्य उद्देशाचे VPN आवश्यक आहे का, आणि इंटरनेटद्वारे व्यवस्थापित बहुतेक उपयोजनांसाठी उत्तर नाही आहे। Apple उपकरणाला त्याच्या स्वतःच्या वेळापत्रकानुसार व्यवस्थापन सेवेपर्यंत पोहोचू देतो, आणि महत्त्वाची रहदारी स्वाक्षरी केलेला आदेश मार्ग आहे, डेस्कटॉप सत्र नाही। हे तुमच्यासाठी चालेल का हे तीन अटींवर अवलंबून आहे, आणि बाहेरून सर्व दूरस्थ प्रवेशासारखे दिसत असल्याने त्या गोंधळवणे सोपे आहे।
वाहतूक निवडण्यापूर्वी गरजेला नाव द्या
व्यवस्थापन आदेश आणि कॉन्फिगरेशन प्रोफाइल एक गरज आहे, परस्परसंवादी स्क्रीन शेअरिंग दुसरी आहे, आणि खाजगी अंतर्गत अ‍ॅपपर्यंत पोहोचणे तिसरी आहे। त्यांचे मालक वेगळे, प्रमाणीकरण वेगळे, आणि बऱ्याचदा स्वीकार्य उघडपणा खूप वेगळा असतो। त्यांना एकत्र करणे म्हणजे ताफा अशा सार्वजनिक पोर्ट यादीपर्यंत पोहोचतो जी कोणीही रक्षू शकत नाही।
तिन्ही गरजा एकच वाहतूक वाटून घेत नाहीत:
| Need | What actually carries it |
|---|---|
| Management commands and profiles | The enrolled device pulls from a service it can reach; APNs only wakes it |
| Interactive screen sharing | A remote-support tool or private desktop path with its own authentication |
| Private application access | That application's permitted network path, which may well be a VPN |
गोंधळ सहसा जुन्या सर्व्हर तपासणी यादीपासून सुरू होतो। OS X Server बद्दलचा ऐतिहासिक दस्तऐवज लांब पोर्ट संच देतो, आणि व्यवस्थापन सेवा कुठेतरी त्याच्या आत असल्याने कोणीतरी ते सर्व कडेवर पुढे पाठवतो। ती व्यवस्थापन स्थापत्य नाही, आणि ती तुम्ही प्रकाशित करू पाहत असलेल्या नियंत्रण पातळीच्या खूप पुढे उघड पृष्ठभाग वाढवते।
पुश सूचना प्रत्यक्षात काय करते
Apple च्या दस्तऐवजीकृत प्रवाहात, व्यवस्थापन सर्व्हर APNs सूचना पाठवतो आणि उपकरणाला कळवतो की काम प्रतीक्षेत आहे। नंतर उपकरण व्यवस्थापन सर्व्हरशी कनेक्शन उघडते आणि आपल्या आदेशांची मागणी करते। पुश ही दाराची घंटी आहे, टनेल नाही: ती कोणतेही अनियंत्रित पेलोड, दूरस्थ डेस्कटॉप सत्र, किंवा दुसऱ्या अ‍ॅपची रहदारी वाहत नाही।
म्हणून उपकरण अभिप्रेत सेवेत नोंदणीकृत असले पाहिजे, अपेक्षित टोकांवर विश्वास ठेवला पाहिजे, आणि व्यवस्थापन सेवा तसेच प्रवाह अवलंबून असलेल्या Apple सेवांपर्यंत पोहोचले पाहिजे। Apple चे नेटवर्क तयारी मार्गदर्शन ती अवलंबित्वे सूचीबद्ध करते, आणि ती प्रवाहाचे वाटाघाटीयोग्य भाग नाहीत। केवळ तुमच्या नेटवर्कच्या आत असलेल्या व्यवस्थापन सर्व्हरलाही उपकरण प्रत्यक्षात वापरू शकेल अशा समर्थित मार्गाची गरज असते। त्याला MDM म्हणणे अगम्य टोकाला गम्य करत नाही।
परवानगी दिलेले मार्ग स्पष्ट ठेवा, मध्यभागी असलेल्या कोणत्याही प्रॉक्सी आणि TLS तपासणी धोरणासह। अपेक्षित प्रमाणपत्र साखळी तोडणारे तपासणी उपकरण अगदी तुटलेल्या नोंदणीसारखे दिसेल।
VPN चुकीचे उत्तर असताना
तुमची व्यवस्थापन सेवा योग्य प्रमाणपत्रासह इंटरनेटवर प्रकाशित असेल आणि प्रत्येक कनेक्शन उपकरण सुरू करत असेल, तर VPN कोणतेही नियंत्रण न जोडता एक उडी जोडते। उपकरण आधीच आपल्या नोंदणी ओळखीने प्रमाणीकरण करते, आणि सर्व्हर आधीच ठरवतो की कोणते आदेश स्वीकारेल। त्याच्या पुढे टनेल नेटवर्क मार्ग बदलते, विश्वासाचा निर्णय नाही।
तेच नियंत्रण पातळ VPN प्रोफाइलही पोहोचवू शकते। तो क्रम महत्त्वाचा आहे: व्यवस्थापित VPN कॉन्फिगरेशन फक्त आणखी एक पेलोड म्हणून येते, त्यामुळे ते तयार करणारे प्रोफाइल मिळण्यापूर्वी टनेल अस्तित्वात असण्याची गरज उपकरणाला नाही।
VPN योग्य उत्तर असताना
असे ताफे आहेत जिथे व्यवस्थापन टोक इंटरनेटवरून कधीही गम्य नसावे, आणि ती धैर्याची कमतरता नाही तर वैध रचना आहे। नियंत्रित वातावरणे, लहान अंतर्गत IT संघ, आणि इतर प्रशासकीय इंटरफेसही होस्ट करणारे सर्व्हर बऱ्याचदा तिथे पोहोचतात। अशा वेळी व्यवस्थापन सेवेसमोर संरक्षित प्रवेश मार्ग ही हेतुपूर्वक रचना आहे, पर्यायी मार्ग नाही।
स्क्रीन शेअरिंग आणि खाजगी अ‍ॅप प्रवेशही सहसा रेषेच्या त्याच बाजूला असतात। दोन्ही आदेश मार्गापेक्षा खूप जास्त उघड करतात, आणि दोन्ही नोंदणी ओळखीवर स्वार होण्याऐवजी स्वतःच्या प्रमाणीकरणास पात्र आहेत।
रिकव्हरी तोडणारा बूटस्ट्रॅप सापळा
मी ज्याच्या विरुद्ध रचना करेन ती अशी बिघाड: व्यवस्थापन सेवेकडे जाणारा एकमेव मार्ग VPN मधून जातो, आणि उपकरणावरील VPN प्रोफाइल किंवा क्रेडेन्शियल कालबाह्य झाले आहे। उपकरण बदली आदेश घेण्यासाठी सर्व्हरपर्यंत पोहोचू शकत नाही, आणि सर्व्हर न उठणाऱ्या टनेलमधून काहीही ढकलू शकत नाही। रिकव्हरी आता शेकडो मैल दूर असू शकणाऱ्या वापरकर्त्यावर अवलंबून आहे।
रिकव्हरीसाठी दुसरा, स्वतंत्र मार्ग ठेवा, तो बँडबाहेरील व्यवस्थापन मार्ग असो, स्थानिक प्रशासक असो, किंवा टनेलशिवाय गम्य राहणारी व्यवस्थापन सेवा असो। सर्व काही चालू असतानाच त्याची चाचणी करा, कारण घटनेच्या वेळी तुम्हाला स्वच्छ चाचणी मिळणार नाही।
नंतर प्रत्येक मार्ग तिन्ही गरजांपैकी कशासाठी सेवा देतो ते लिहा, आणि कोणतीही सेवा न देणारे पोर्ट फॉरवर्डिंग काढून टाका। सामान्य टनेलशिवाय व्यवस्थापित करता येणारा, आणि टनेलच तुटला असतानाही दुरुस्त करता येणारा ताफा हाच रचना करण्यासारखा निकाल आहे।