मेल बिना VPN के सर्वर तक पहुँचता है: नियम कहाँ लागू करें

मेल लगातार पोलिंग करता रहता है और VPN बंद है, फिर भी खाता सिंक होता रहता है। ऐप वही कर रहा है जिसके लिए उसे कॉन्फ़िगर किया गया था; किसी सामान्य मेल प्रोफ़ाइल में यह नहीं लिखा होता कि सर्वर केवल सुरंग से ही पहुँच में है। इससे दो अलग आवश्यकताएँ बचती हैं, और उन्हें मिलाना आसान है: सेवा सीधे क्लाइंट को मना करे, या Mac कोशिश ही न करे।

उत्पाद चुनने से पहले आवश्यकता चुनें। सर्वर नियम और क्लाइंट नियम अलग-अलग जगहों पर विफल होते हैं, अलग सबूत देते हैं और अलग मालिकों के होते हैं। दोनों लागू करना तब वैध है जब दोनों कथन सही हों, पर एक दूसरे का विकल्प नहीं है। दोनों आवश्यकताएँ वैध हैं; बस वे एक ही नियंत्रण नहीं हैं।

लक्षण Mac जैसा दिखता है, पर रिसाव सर्वर हो सकता है

जब मेल सुरंग के बाहर सिंक हो, तो सर्वर क्या स्वीकार करता है वहाँ से शुरू करें। अगर मेल श्रोता इंटरनेट से सीधे कनेक्शन का जवाब देता है, तो क्लाइंट पक्ष की कोई सुविधा सेटिंग उस तथ्य को नहीं बदलती। Mac उस सेवा के सामने सामान्य व्यवहार कर रहा है जो अभी भी खुली है।

मेल व्यवस्थापक से पूछें कि सेवा कौन-सा स्रोत पता देखती है। VPN गेटवे, रिवर्स प्रॉक्सी या लोड बैलेंसर क्लाइंट पता बदल सकते हैं, इसलिए VPN कॉन्फ़िगरेशन का पता-पूल मेल प्रक्रिया तक पहुँचने वाले पते से मेल नहीं खा सकता। गलत स्रोत के विरुद्ध लिखा नियम या तो सबको रोकता है या किसी को नहीं।

वही उत्तर यह भी बताता है कि सेवा VPN क्लाइंट को अलग पहचान सकती है या नहीं। अगर हर क्लाइंट एक ही प्रॉक्सी पते से आता है, तो स्रोत-आधारित प्रवेश उन्हें अलग नहीं कर सकता, और आवश्यकता को प्रमाणीकरण या क्लाइंट पक्ष की ओर ले जाना होगा।

सर्वर प्रवेश: ऐप नहीं, स्रोत को मना करें

होस्ट या नेटवर्क फ़ायरवॉल मेल श्रोता को स्वीकृत स्रोत श्रेणियों तक सीमित कर सकता है और प्रमाणीकरण तथा TLS अपरिवर्तित रख सकता है। दूरस्थ पतों, सबनेट या श्रेणियों से मेल खाने वाली नियम-शर्त सामान्य निर्माण-ब्लॉक है; सटीक सिंटैक्स सर्वर के फ़ायरवॉल उत्पाद का है, मेल ऐप का नहीं।

जब आवश्यकता «सेवा सीधे क्लाइंट को सेवा न दे» हो तो यह सबसे मज़बूत सीमा है। उपयोगकर्ता दूसरा मेल क्लाइंट स्थापित करे तब भी यह टिकता है, क्योंकि मना प्रमाणीकरण से पहले होता है। यह उस Mac पर भी टिकता है जो अपनी VPN नीति अनदेखी करता है।

इसकी सीमा भी उतनी ही महत्वपूर्ण है। अस्वीकृत कनेक्शन सिद्ध करता है कि सेवा ने सत्र मना किया; यह सिद्ध नहीं करता कि Mac ने कोई कोशिश नहीं की। DNS रिज़ॉल्यूशन, पिछले लोड बैलेंसर तक TCP SYN और विफलता के बाद पुनः प्रयास, सब सर्वर के नियम तक पहुँचने से पहले हो सकते हैं। अगर आवश्यकता पहुँच के बजाय प्रयासों के खुलासे के बारे में है, तो सर्वर प्रवेश नियंत्रण का आधा ही है।

क्लाइंट पर प्रवर्तन: केवल सुरंग नहीं, कोशिश रोकें

क्लाइंट पक्ष के नियम को ट्रैफ़िक मना करना चाहिए, केवल मेल खुलने पर सुरंग शुरू करना नहीं। मेल डोमेन के लिए सक्रियण ट्रिगर सही पल में VPN ऊपर ला सकता है, पर यह तय नहीं करता कि सुरंग बंद रहने पर या विफल होने के बाद क्या होता है।

एंडपॉइंट उत्पाद की समर्थित ब्लॉकिंग नीति का उपयोग करें और उसका दायरा जानबूझकर तय करें। ऐप-स्तर का नियम उस मेल ऐप के हर खाते को कवर करता है, निजी खातों सहित। गंतव्य-स्तर के नियम में कार्य खाते के IMAP, प्रेषण और प्रमाणीकरण एंडपॉइंट के नाम होने चाहिए, और वे पते बदलने पर भी उसे काम करते रहना चाहिए।

दोनों पता-परिवार और मौजूदा सत्र कवर करें। जो नीति नए IPv4 कनेक्शन रोकती है पर IPv6 या स्थापित सॉकेट को अछूता छोड़ती है, वह रुक-रुक कर सिंक पैदा करती है जो बेतरतीब लगता है। नेटवर्क बदलाव और स्लीप चक्र उसी परीक्षण का हिस्सा हैं।

ऐप-स्तर और गंतव्य-स्तर के नियमों का प्रभाव-दायरा अलग है

ऐप-स्तर का अवरोध समझना सरल है: सुरंग के बिना मेल से कोई ट्रैफ़िक बाहर नहीं जाता। यह कठोर भी है, क्योंकि उसी ऐप में निजी खाता हो सकता है जिसका नीति से कोई संबंध नहीं। उपयोगकर्ता इसे पहले नोटिस करते हैं और टूटे मेल ऐप के रूप में रिपोर्ट करते हैं।

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

आवश्यकता के शब्दों के अनुसार चुनें। «यह कार्य खाता सीधे कनेक्ट नहीं हो सकता» गंतव्य दायरे की ओर इशारा करता है। «यह Mac VPN के बाहर मेल नहीं चला सकता» व्यापक ऐप-नियम को न्यायसंगत बनाता है, बशर्ते मालिक निजी खाते के दुष्प्रभाव को स्वीकार करे।

मना और अनुपस्थिति अलग-अलग जाँचें

समर्पित परीक्षण खाते के साथ VPN से जुड़ें और सामान्य संचालन की पुष्टि करें। फिर डिस्कनेक्ट करें और दो बार जाँचें: एक बार यह देखने के लिए कि सर्वर लॉगिन मना करता है या नहीं, और एक बार यह देखने के लिए कि Mac कोई कनेक्शन आज़माता है या नहीं। ये अलग अवलोकन हैं और अलग लॉग में जाते हैं।

डिस्कनेक्ट रहते हुए SYN या DNS क्वेरी के लिए क्लाइंट पक्ष के सबूत देखें, और अस्वीकृत या स्वीकृत सत्र के लिए सर्वर लॉग देखें। अगर सर्वर मना करता है पर क्लाइंट फिर भी कोशिश करता है, तो सर्वर नियम काम कर रहा है और क्लाइंट नियम गायब है। अगर क्लाइंट कोई कोशिश नहीं करता पर सर्वर अब भी दूसरे क्लाइंट स्वीकार करता है, तो सीमा ठीक वहीं है जहाँ आपने उसे रखा था।

प्रवर्तन का मालिक, सर्वर जो स्रोत पता वास्तव में देखता है, और उपयोग किया गया परीक्षण खाता दर्ज करें। अगला नेटवर्क या प्रॉक्सी बदलाव उस स्रोत को खिसका सकता है, और देखे गए मान का नाम बताने वाला नोट अनुमान के अगले दौर से जल्दी जाँचा जाता है।