मेल VPN शिवाय सर्व्हरपर्यंत पोहोचतो: नियम कुठे लागू करावा

मेल सतत पोलिंग करत आहे आणि VPN बंद आहे, तरीही खाते सिंक होत आहे। अ‍ॅप ज्यासाठी कॉन्फिगर केले आहे तेच करत आहे; सामान्य मेल प्रोफाइलमध्ये सर्व्हर फक्त टनेलमधूनच उपलब्ध आहे असे कुठेही म्हटलेले नाही। यामुळे दोन वेगळ्या आवश्यकता राहतात, आणि त्या एकत्र करणे सोपे आहे: सेवेने थेट क्लायंटना नकार द्यावा, किंवा Mac ने प्रयत्नच करू नये।

उत्पादन निवडण्यापूर्वी आवश्यकता निवडा। सर्व्हर नियम आणि क्लायंट नियम वेगवेगळ्या ठिकाणी अपयशी ठरतात, वेगळे पुरावे देतात आणि वेगळ्या मालकांचे असतात। दोन्ही लागू करणे दोन्ही विधाने खरी असताना वैध आहे, पण एक दुसऱ्याची जागा घेत नाही। दोन्ही आवश्यकता कायदेशीर आहेत; फक्त ते एकच नियंत्रण नाही।

लक्षण Mac सारखे दिसते, पण गळती सर्व्हरवर असू शकते

मेल टनेलबाहेर सिंक झाल्यास, सर्व्हर काय स्वीकारतो यापासून सुरुवात करा। मेल श्रोता इंटरनेटवरून थेट कनेक्शनला उत्तर देत असल्यास, क्लायंट बाजूचे कोणतेही सोयीचे सेटिंग ती वस्तुस्थिती बदलत नाही। Mac अजूनही खुल्या सेवेसमोर सामान्य वागत आहे।

सेवा कोणता स्रोत पत्ता पाहते ते मेल प्रशासकाला विचारा। VPN गेटवे, रिव्हर्स प्रॉक्सी किंवा लोड बॅलन्सर क्लायंटचा पत्ता बदलू शकतात, त्यामुळे VPN कॉन्फिगरेशनमधील पत्त्यांचा संच मेल प्रक्रियेपर्यंत पोहोचणाऱ्याशी जुळणार नाही। चुकीच्या स्रोताविरुद्ध लिहिलेला नियम एकतर सर्वांना अडवतो किंवा कोणालाच अडवत नाही।

त्या उत्तरावरून सेवा VPN क्लायंटना अजिबात वेगळे ओळखू शकते का हेही कळते। प्रत्येक क्लायंट एकाच प्रॉक्सी पत्त्यावरून आला तर स्रोताधारित प्रवेश त्यांना वेगळे करू शकत नाही, आणि आवश्यकता प्रमाणीकरणाकडे किंवा क्लायंट बाजूकडे हलवावी लागेल।

सर्व्हरवरील प्रवेश: अ‍ॅप नाही, स्रोत नाकारा

होस्ट किंवा नेटवर्क फायरवॉल प्रमाणीकरण आणि TLS अपरिवर्तित ठेवून मेल श्रोत्याला मंजूर स्रोत श्रेणींपर्यंत मर्यादित करू शकतो। दूरचे पत्ते, सबनेट किंवा श्रेणी जुळणारी नियम-अट हा नेहमीचा बांधकाम-घटक आहे; नेमका सिंटॅक्स सर्व्हरच्या फायरवॉल उत्पादनाचा आहे, मेल अ‍ॅपचा नाही।

आवश्यकता «सेवेने थेट क्लायंटना सेवा देऊ नये» अशी असेल तेव्हा ही सर्वात मजबूत सीमा आहे। वापरकर्त्याने दुसरे मेल क्लायंट स्थापित केले तरी ती टिकते, कारण नकार प्रमाणीकरणापूर्वी होतो। स्वतःचे VPN धोरण दुर्लक्षित करणाऱ्या Mac वरही ती टिकते।

तिची मर्यादाही तितकीच महत्त्वाची आहे। नाकारलेले कनेक्शन सेवेने सत्र नाकारले हे सिद्ध करते; Mac ने प्रयत्न केला नाही हे सिद्ध करत नाही। DNS निराकरण, पूर्वीच्या लोड बॅलन्सरकडे TCP SYN आणि अपयशानंतर पुन्हा प्रयत्न — सर्व सर्व्हरच्या नियमापर्यंत पोहोचण्यापूर्वी घडू शकतात। आवश्यकता प्रवेशाऐवजी प्रयत्नांच्या उघडकीसाठी असेल, तर सर्व्हरवरील प्रवेश नियंत्रणाचा फक्त अर्धा भाग आहे।

क्लायंटवर अंमलबजावणी: फक्त टनेल नाही, प्रयत्न अडवा

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

एंडपॉइंट उत्पादनाचे समर्थित ब्लॉकिंग धोरण वापरा आणि त्याची व्याप्ती जाणीवपूर्वक ठरवा। अ‍ॅप-स्तरीय नियम त्या मेल अ‍ॅपमधील प्रत्येक खाते व्यापतो, वैयक्तिक खात्यांसह। गंतव्य-स्तरीय नियमाने कामाच्या खात्याचे IMAP, पाठवणी आणि प्रमाणीकरण एंडपॉइंट नावाने सांगावेत, आणि ते पत्ते बदलल्यावरही काम चालू ठेवावे।

दोन्ही पत्ता-कुटुंबे आणि विद्यमान सत्रे व्यापा। नवीन IPv4 कनेक्शन अडवणारे पण IPv6 किंवा प्रस्थापित सॉकेटला स्पर्श न करणारे धोरण अनियमित वाटणारे अधूनमधून सिंक निर्माण करते। नेटवर्क बदल आणि झोपेची चक्रे त्याच चाचणीचा भाग आहेत।

अ‍ॅप-स्तरीय आणि गंतव्य-स्तरीय नियमांचा प्रभाव वेगळा असतो

अ‍ॅप-स्तरीय ब्लॉक समजण्यास सोपा आहे: टनेलशिवाय मेलमधून कोणतीही रहदारी बाहेर पडत नाही। तो कठोरही आहे, कारण त्याच अ‍ॅपमध्ये धोरणाशी काहीही संबंध नसलेले वैयक्तिक खाते असू शकते। वापरकर्ते ते प्रथम लक्षात घेतात आणि तुटलेले मेल अ‍ॅप म्हणून नोंदवतात।

गंतव्य-स्तरीय ब्लॉक अधिक अरुंद आणि सांभाळण्यास कठीण आहे। त्याला खाते वापरत असलेल्या एंडपॉइंटचा संपूर्ण संच हवा, शोध आणि प्रमाणीकरण सेवांसह, आणि त्या अद्ययावत करण्याची प्रक्रिया हवी। एक चुकला तर खाते अर्धवट चालते; जास्त समाविष्ट केले तर असंबंधित मेल थांबते।

आवश्यकतेच्या शब्दांनुसार निवडा। «हे कामाचे खाते थेट जोडले जाऊ नये» गंतव्य व्याप्तीकडे निर्देश करते। «या Mac ने VPN बाहेर मेल चालवू नये» व्यापक अ‍ॅप-नियमाला न्याय देतो, बशर्ते मालक वैयक्तिक खात्यावरील दुष्परिणाम स्वीकारेल।

नकार आणि अनुपस्थिती स्वतंत्रपणे तपासा

समर्पित चाचणी खात्यासह VPN मधून जोडा आणि सामान्य कार्याची खात्री करा। मग डिस्कनेक्ट करा आणि दोनदा तपासा: एकदा सर्व्हर लॉगिन नाकारतो का हे पाहण्यासाठी, आणि एकदा Mac कोणताही कनेक्शनचा प्रयत्न करतो का हे पाहण्यासाठी। ही वेगळी निरीक्षणे आहेत आणि ती वेगळ्या लॉगमध्ये जातात।

डिस्कनेक्ट असताना SYN किंवा DNS प्रश्नासाठी क्लायंट बाजूचे पुरावे पाहा, आणि नाकारलेल्या किंवा स्वीकारलेल्या सत्रासाठी सर्व्हर लॉग पाहा। सर्व्हर नाकारतो पण क्लायंट तरीही प्रयत्न करतो, तर सर्व्हर नियम काम करत आहे आणि क्लायंट नियम गायब आहे। क्लायंट कोणताही प्रयत्न करत नाही पण सर्व्हर अजूनही इतर क्लायंट स्वीकारतो, तर सीमा तुम्ही ठेवलेल्या जागीच आहे।

अंमलबजावणीचा मालक, सर्व्हर प्रत्यक्षात पाहत असलेला स्रोत पत्ता आणि वापरलेले चाचणी खाते नोंदवा। पुढील नेटवर्क किंवा प्रॉक्सी बदल तो स्रोत हलवू शकतो, आणि निरीक्षित मूल्याचे नाव देणारी नोंद अजून एका अंदाजाच्या फेरीपेक्षा लवकर तपासली जाते।