प्रत्येक अॅपसाठी VPN की split tunnel? Mac चा रूट काय ठरवू शकतो

दोन अॅप एकाच ऑफिस सर्व्हरशी कनेक्शन उघडतात, आणि त्यापैकी फक्त एकाने टनेल वापरावा। रूट ही इच्छा व्यक्त करू शकत नाही, कारण राउटिंग तक्ते गंतव्यांवर आधारित असतात आणि कोणत्या प्रक्रियेने सॉकेट उघडले याची त्यांना कल्पनाही नसते। लोक जे मागतात आणि ज्याची त्यांना गरज असते ती अनेकदा वेगळी गोष्ट असते। कोणतेही कॉन्फिगरेशन बदलण्यापूर्वी दोन्ही वेगळे करा।

निवडक गंतव्य असतो, कधीही प्रक्रिया नाही

प्रत्येक राउटिंग निर्णय गंतव्य पत्त्याने सुरू होतो आणि इंटरफेसवर संपतो। कर्नेल कधीही विचारत नाही की पॅकेट कोणत्या प्रोग्रामने पाठवले, आणि macOS वर pf सुद्धा प्रक्रियेनुसार रूट करत नाही, त्यामुळे फायरवॉल नियम एका अॅपला दुसऱ्या मार्गावर ठेवू शकत नाही। म्हणूनच तोच सर्व्हर, ब्राउझरने पोहोचलो किंवा रिपोर्टिंग साधनाने, दोघांसाठी एकच मार्ग घेतो। त्यामुळे अॅप-स्तरावरील विभाजन रूटशिवाय दुसऱ्या कशातून तरी आले पाहिजे: एक VPN प्लगइन जे सॉकेटचे मालक आहे, एक प्रॉक्सी जे अॅपच्या वतीने कनेक्शन घेते, किंवा एक वेगळा नेटवर्क स्टॅक। यापैकी काहीही राउटिंग बदल नाही।

एकाच पत्त्याशी बोलणारी दोन अॅप कोणत्याही रचनेची सर्वात स्वच्छ कसोटी आहेत। जर उत्तर त्यांच्यात वेगळे असू शकत नाही, तर रचना गंतव्य-आधारित आहे, त्याला काहीही नाव दिले तरी।

सामान्य split tunnel प्रत्यक्षात काय देतो

split tunnel खाजगी प्रीफिक्ससाठी रूट स्थापित करतो आणि बाकी सर्व भौतिक मार्गावर ठेवतो। सामान्यतः विनंतीचा अर्थ असाच असतो: टनेलमधून ऑफिस सर्व्हरपर्यंत पोहोचणे, सार्वजनिक ब्राउझिंग सरळ ठेवणे। हे सोपे आहे, प्रत्येक सामान्य क्लायंट त्याला समर्थन देतो, आणि ते इतर कोणत्याही रूटसारख्याच यंत्रणेने लागू होते। विशिष्ट गंतव्य route -n get ने तपासा, डीफॉल्ट रूट वाचण्याऐवजी, कारण split tunnel अनेकदा डीफॉल्ट रूटला अस्पर्श ठेवतो।

डीफॉल्ट रूट हाताने संपादित करणे हे कोणत्यातरी गोष्टीत रूपांतर नाही। ते क्लायंटच्या स्वतःच्या रूट पुनर्संचयनाशी लढते आणि जे क्लायंट संरक्षण धोरण स्थापित करतात त्यांच्यात मशीनला अशा स्थितीत सोडू शकते जिची तुम्हीही अपेक्षा करत नाही आणि क्लायंटही नाही। त्याऐवजी split tunnel क्लायंटच्या समर्थित सेटिंग्जमध्ये कॉन्फिगर करा।

macOS वर प्रति-अॅप VPN काय मागतो

macOS वर खरा प्रति-अॅप VPN हा Network Extension वैशिष्ट्य आहे जो कॉन्फिगरेशन प्रोफाइल चालवतो। एक व्यवस्थापन पेलोड निवडलेल्या अॅपना VPN कॉन्फिगरेशनशी जोडतो, आणि सिस्टम नंतर त्या अॅपची ट्राफिक त्यानुसार रूट करते। ही एक व्यवस्थापित तैनाती आहे, म्हणजे MDM, स्वाक्षरीकृत प्रोफाइल आणि दोन्हींचा मालक असलेला प्रशासक।

क्लायंट हाताने स्थापित केल्याने ते मॅपिंग तयार होत नाही, आणि सामान्य सेटिंग्ज पॅनेल अॅपना वेगवेगळे निवडण्यायोग्य करत नाही। एखादा विक्रेता स्वतःचे अॅप नियम देऊ शकतो, आणि ते सामान्य नियमाऐवजी त्याच्या दस्तऐवजांचे पालन करतात।

MDM शिवाय अॅप-स्तरीय विभाजनाचे तीन मार्ग

जिथे व्यवस्थापन उपलब्ध नाही, तिथे प्रॉक्सी हे व्यावहारिक उत्तर आहे। अॅपची स्वतःची प्रॉक्सी कॉन्फिगरेशन सेट करा, किंवा अशी PAC फाइल वापरा जी फक्त त्या अॅपसाठी गंतव्य आणि प्रोटोकॉलनुसार निवड करते।

स्थानिक प्रॉक्सी कनेक्शन संपवते आणि टनेलमधून ते पुन्हा तयार करते, त्यामुळे अॅपला कधीही रूटची गरज नसते। दुसरा पर्याय म्हणजे वेगळा नेटवर्क स्टॅक: स्वतःच्या डीफॉल्ट रूटसह आभासी मशीन किंवा कंटेनर, जिथे अॅप स्थानिक पत्त्याने पोहोचते। तिसरा म्हणजे गंतव्य-आधारित राउटिंग स्वीकारणे आणि अट सोडणे, जे तेव्हा प्रामाणिक असते जेव्हा दोन्ही अॅप टनेल वापरू शकतात। तिन्ही तपासता येतात, आणि यापैकी कोणतेही रूट प्रक्रिया जाणतो असे दाखवत नाही।

विनंती अशी लिहा की उत्तर स्पष्ट असेल

यंत्रणेऐवजी कार्यप्रवाह सांगा: कोणत्या अॅपला कोणती सेवा हवी, दुसरे अॅप त्याच सेवेपासून दूर ठेवायचे आहे का, आणि टनेल बंद असताना काय घडले पाहिजे। ही तीन उत्तरे रचना निवडतात। ती प्रशासकाला हेही सांगतात की विनंती राउटिंग बदल आहे की तैनाती प्रकल्प।

वगळलेल्या अॅपची बाब स्पष्टपणे समाविष्ट करा। जो क्लायंट अॅपचा संरक्षित मार्ग उपलब्ध नसताना अॅप थांबवतो, तो अॅपला भौतिक इंटरफेसवर परत पडू देणाऱ्या क्लायंटपेक्षा वेगळा वागतो, आणि वापरकर्त्यांना तो फरक लगेच जाणवतो। तिकिटात अपेक्षेचे नाव द्या। नंतर प्रत्यक्ष मशीनवर तपासा, कारण तेच उत्पादन macOS वर Windows पेक्षा अनेकदा वेगळे वागते, आणि त्याचे macOS दस्तऐवज हे त्याची सेटिंग्ज काय करतात याबद्दलच एकमेव विश्वासार्ह स्रोत आहे।