किसी दूसरे देश में कोई व्यक्ति कनेक्ट नहीं कर पाता, और पहली प्रवृत्ति उस नियम को देखने की होती है जो आंतरिक संसाधनों तक पहुँच देता है। वह नियम प्रवेश के बाद चलता है, इसलिए वह टनल को अस्वीकार करने वाली चीज़ नहीं हो सकता। अवरोधक चरण प्रवेश पथ में कहीं है, और VPN सेवा के अनुसार Firebox के पास एक से अधिक प्रवेश पथ हैं। जाँचें क्रम से करें और जैसे ही उनमें से कोई अस्वीकृति समझा दे, रुक जाएँ।

जाँच 1: आने वाली सेवा का नाम दें

SSL के साथ Mobile VPN, Access Portal और TLS पर BOVPN के लिए आने वाला प्रवेश WatchGuard SSLVPN नीति है। इच्छित प्रतिबंध वहीं, वास्तव में कॉन्फ़िगर की गई सेवा पर लागू करें, बजाय उसे बाद में चलने वाले उपयोगकर्ता-प्रवेश नियम से निकालने के।

IPsec अलग रास्ता लेता है। अंतर्निहित IPSec नीति लागू शाखा और मोबाइल VPN सेवाओं के लिए बाहरी IPsec ट्रैफ़िक को Firebox तक अनुमति देती है, और यह हाथ से बनाई गई IPSec नीति पर प्राथमिकता रखती है। यदि आपका क्लाइंट IKEv2 है, तो आप उस दूसरे पथ पर हैं, और SSLVPN नीति अप्रासंगिक है।

यहाँ गलती करना इस क्षेत्र में सबसे आम बर्बाद दोपहर है: ऐसी नीति संपादित करना जो पैकेट को कभी नहीं देखती, फिर निष्कर्ष निकालना कि प्रतिबंध काम नहीं करता।

जाँच 2: सिद्धांत नहीं, अस्वीकृति पढ़ें

एक नियंत्रित अनुमत प्रयास करें और चार चीज़ें सहसंबंधित करें: क्लाइंट का सार्वजनिक स्रोत पता, उसने जिस प्रवेश सेवा को छुआ, जो नीति मेल खाई, और लॉग में कोई भी अस्वीकृति कारण। WatchGuard का IKEv2 समस्या-निवारण मार्गदर्शन बताता है कि भू-स्थान और डिफ़ॉल्ट पैकेट प्रबंधन अंतर्निहित नीति के प्रवेश से पहले ट्रैफ़िक अस्वीकार कर सकते हैं, जिसका अर्थ है कि आप जो अस्वीकृति देख रहे हैं वह ऐसे चरण का नाम ले सकती है जिस पर आपने विचार नहीं किया।

देश वर्गीकरण देखे गए नेटवर्क स्रोत का अनुसरण करता है। घूमता उपयोगकर्ता, ऊपर का NAT या कोई दूसरा स्वीकृत पथ Firebox जो देखता है उसे बदल सकते हैं, इसलिए उपयोगकर्ता के अपने स्थान के वर्णन के बजाय पते की पुष्टि करें। क्लाइंट जो सार्वजनिक पता देखता है उसे माँगें, और Firebox लॉग के स्रोत से तुलना करें। जब वे भिन्न हों, तो वर्गीकरण ऐसे पथ का अनुसरण कर रहा है जिसका किसी ने उल्लेख नहीं किया।

जाँच 3: क्या अंतर्निहित नीति अभी भी स्वामी है?

यदि हाथ से बनाई IPSec नीति को अनदेखा किया जाता दिखे, तो जाँचें कि अंतर्निहित अभी भी सक्षम है या नहीं। उच्च प्राथमिकता वाली अंतर्निहित नियम से ढका हाथ का नियम और वह हाथ का नियम जो एकमात्र प्रवेश है, एक जैसे दिखने वाले इंटरफ़ेस के साथ अलग कॉन्फ़िगरेशन हैं।

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

जाँच 4: अक्षम करने से पहले प्रतिस्थापन की योजना बनाएँ

अंतर्निहित IPSec नीति को अक्षम करने से प्रभावित VPN सेवाओं के लिए उसका प्रवेश हट जाता है। इसमें वे शाखा टनल भी हैं जिनके बारे में आप एक मोबाइल उपयोगकर्ता का कनेक्शन ठीक करते समय शायद नहीं सोच रहे होंगे।

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

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

जाँच 5: पहचान को स्थान से अलग रखें

भू-स्थान प्रवेश निर्णय में संदर्भ जोड़ता है। यह तय नहीं करता कि उपयोगकर्ता कौन है, और इसे गेटवे पहचान जाँच, खाता प्राधिकरण या MFA का विकल्प नहीं बनना चाहिए।

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

जाँच 6: इसे दर्ज करें और दोनों पथ सत्यापित करें

सेवा, प्रवेश नीति, इच्छित स्थान परिक्षेत्र, अपवाद और पुनर्प्राप्ति का उत्तरदायी दर्ज करें। फिर बदलाव के बाद मोबाइल पथ और कम से कम एक साइट पथ परखें, ताकि प्रतिबंध उस सेवा से जुड़ा रहे जिसके लिए इसे बनाया गया।

अंत में, जिस अस्वीकृति से आपने शुरू किया उसे दोबारा पढ़ें। यदि वह स्थान अस्वीकृति से प्रमाणीकरण या प्राधिकरण विफलता में बदल गई है, तो प्रवेश समस्या हल हो गई है और अब दूसरी दिख रही है। ऊपर वर्णित चरण क्रम के लिए IKEv2 अस्वीकृतियों पर WatchGuard मार्गदर्शन संदर्भ है।

संबंधित लेख