Firebox भू-स्थान अस्वीकृति: पहिले VPN प्रवेश चरण पत्ता लगाउनुहोस्
VPN क्लाइन्ट अवरोध गर्ने नियम प्रायः प्रवेश नीति हुन्छ, प्रयोगकर्ता-प्रवेश नियम होइन। केही बदल्नु अघि वास्तविक चरण पत्ता लगाउने छ जाँच।
अर्को देशमा कोही जोडिन सक्दैन, र पहिलो प्रवृत्ति आन्तरिक स्रोतहरूमा पहुँच दिने नियम हेर्ने हुन्छ। त्यो नियम प्रवेश पछि चल्छ, त्यसैले यो टनेल अस्वीकार गर्ने कुरा हुन सक्दैन। अवरोध गर्ने चरण प्रवेश मार्गमा कतै छ, र 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 मार्गदर्शन सन्दर्भ हो।