शाखाको सबनेटलाई प्रधान कार्यालयको SonicWall इन्टरनेट एक्जिटबाट रुट गर्नुहोस्
शाखाको स्रोत समूह छान्नुहोस्, टनेल नीतिमा स्वीकार गर्नुहोस्, केन्द्रीय WAN मा अनुवाद गर्नुहोस्, त्यसपछि तीन क्लाइन्ट परीक्षण गर्नुहोस्। मात्र एउटा रुटले गेटवे बनाउँदैन।
शाखाका फोनहरू प्रधान कार्यालयबाट बाहिर जानुपर्छ भने शाखाका ल्यापटपहरू स्थानीय WAN प्रयोग गर्न जारी राख्छन्, र मात्र रुटिङ नीतिले त्यो दिँदैन। शाखाको रुटले टनेल छान्न सक्छ, तर टनेल नीतिले ट्राफिक स्वीकार गर्नुपर्छ, प्रधान कार्यालयले त्यसलाई अगाडि पठाउन र अनुवाद गर्नुपर्छ, र जवाफ त्यही बाटो फर्कनुपर्छ। यी तीनमध्ये कुनै पनि छुट्यो भने लक्षण टनेल सक्रिय रहँदा ठ्याक्कै इन्टरनेट गुमाउने क्लाइन्टहरूको उपसमूह हुनेछ।
सेलेक्टरबाट सुरु गर्नुहोस्, रुटबाट होइन
रुटिङ नीति स्रोतमा मिल्छ, त्यसैले अरू केही गर्नुअघि स्रोत स्थिर हुनुपर्छ। छानिएका यन्त्रहरूलाई प्रशासकले राख्ने ठेगाना समूहमा राख्नुहोस्, वा अझ राम्रो, सदस्यता यन्त्रको भूमिका पछ्याउने समर्पित खण्डमा राख्नुहोस्। जब सामान्य DHCP परिवर्तनले मिल्ने ठेगाना अर्को मेसिनमा सार्न सक्छ, नीतिले चुपचाप गलत क्लाइन्ट छान्छ, र पहिलो रिपोर्ट सामान्यतया ढिलो ब्राउजिङको बारेमा हुन्छ जुन वास्तवमा एउटा घुम्ती हो।
समूहको नाम यसले सेवा गर्ने नीतिको नाममा राख्नुहोस्, तल्ला वा विभागको नाममा होइन, किनकि रुटिङ नियम दुवैभन्दा लामो समय टिक्नेछ। यसमा कुन यन्त्रहरू छन् र कसले एउटा थप्न सक्छ भनी लेख्नुहोस्।
शाखाको नीति थप्नुहोस्, त्यसपछि यसको क्रम जोगाउनुहोस्
शाखाको SonicWall मा रुट नीतिले स्रोत समूह छान्छ, इच्छित गन्तव्यहरूको नाम दिन्छ र टनेल इन्टरफेसलाई गेटवेको रूपमा सेट गर्छ, समर्थित टनेल-इन्टरफेस डिजाइन यहीका लागि हो। स्थानीय र निजी-गन्तव्य नियमहरू फराकिलो इन्टरनेट नियममाथि राख्नुहोस्, किनकि पहिलो मिलान जित्छ र टनेलमा धकेलिएको निजी प्रिफिक्स प्रधान कार्यालयमा फालिन मात्र पुग्छ। फायरवालको आफ्नै रुट यसको VPN साथीतर्फ पनि जोगाउनुहोस्, नत्र टनेल यातायातले यो निर्भर हुने नीति पछ्याउनेछ। यीमध्ये केहीले पनि तपाईंलाई हरेक विद्यमान नीति-आधारित टनेल रूपान्तरण गर्न बाध्य पार्दैन; टनेल इन्टरफेस धेरैमध्ये एउटा समर्थित विकल्प हो।
क्रम त्यो भाग हो जो दुर्घटनावश बदलिन्छ। अपवाद थप्ने जो कोहीले यसलाई फराकिलो नियममाथि राख्नुपर्छ, र फराकिलो नियम सम्पादन गर्ने जो कोहीले एउटै सुरक्षणले पूरै डिजाइन उल्टाउन सक्छ। इच्छित क्रम नीतिको छेउमा लेख्नुहोस् र फर्मवेयर अद्यावधिकपछि फेरि जाँच्नुहोस्, किनकि इन्टरफेस नामकरण र नीति प्रस्तुति संस्करणहरूबीच साँच्चै परिवर्तन हुन्छ।
प्रधान कार्यालयमा बाटो पूरा गर्नुहोस्
प्रधान कार्यालयको टनेल नीतिले अब शाखाको रुटले छान्ने ट्राफिक स्वीकार गर्नुपर्छ। प्रधान कार्यालयको निजी LAN मा सीमित अन्तर-कार्यालय चयनकर्ता स्वेच्छाचारी सार्वजनिक गन्तव्य बोक्ने अनुमति होइन, त्यसैले नीतिलाई शाखाको स्रोत र तपाईंले साँच्चै इच्छा गर्नुभएको गन्तव्य दायरा चाहिन्छ। त्यसपछि प्रधान कार्यालयले त्यो आउने ट्राफिक आफ्नै पहुँच नियमअनुसार आफ्नो इन्टरनेट अपलिङ्कमा पठाउँछ, र SonicWall को केन्द्रीय एक्जिट उदाहरण ले केन्द्रीय WAN मा टाढाको नेटवर्कका लागि स्रोत अनुवाद समावेश गर्छ। त्यो अनुवाद बिना टाढाको पक्षले निजी शाखा ठेगाना देख्छ र त्यहाँ फर्कने रुट हुँदैन।
जवाफहरू सम्झौताको अर्को आधा हुन्। तिनीहरू टनेलबाट वा तिनका लागि बनाइएको अवस्थायुक्त अनुवादबाट फर्कनुपर्छ, र निजी साइटहरूको ट्राफिकलाई सार्वजनिक एक्जिटभन्दा फरक NAT उपचार चाहिन सक्छ। ती नियमहरू छुट्याउन सकिने राख्नुहोस्, किनकि हरेक आन्तरिक स्रोत लुकाउने एउटा फराकिलो अनुवाद नियमले पछिको लगिङ र समस्या समाधान पढ्न धेरै गाह्रो बनाउँछ।
टनेल खस्दा समूहले के गर्ने निर्णय गर्नुहोस्
यदि केन्द्रीय एक्जिट प्राथमिकता नभई आवश्यकता हो भने, स्थानीय WAN मा फर्कनु प्रयोगकर्ता अनलाइन रहे पनि अनुपालन असफलता हो। SonicOS ले छानिएको ट्राफिकलाई अनिच्छित वैकल्पिक बाटो लिनबाट रोक्ने समर्थित तरिकाको रूपमा टनेल इन्टरफेस खसाल्ने रुटलाई अभिलेख गर्छ।
त्यो रुटको दायरा र प्राथमिकता स्थापित संस्करणसँग मिलाउनुहोस्, र लेबलमा भरोसा गर्नुको सट्टा टनेल तल झारेर परीक्षण गर्नुहोस्। कहिल्यै स्थानीय रूपमा बाहिर नजानुपर्ने समूह बन्द रूपमा असफल हुनुपर्छ, जबकि उपलब्धता बढी महत्त्वपूर्ण भएको समूह वैध रूपमा फर्कन सक्छ; दुवै निर्णय हुन्, र कुनै पनि पूर्वनिर्धारित रूपमा हुनुहुँदैन।
तीन क्लाइन्टबाट प्रमाणित गर्नुहोस्, त्यसपछि सफा रूपमा रोलब्याक गर्नुहोस्
केन्द्रीय गेटवेमा पिङले गलत कुरा परीक्षण गर्छ, किनकि यो फायरवालबाट उत्पन्न हुन्छ, छानिएको क्लाइन्टबाट होइन। यसको सट्टा यन्त्रहरूबाट परीक्षण गर्नुहोस्, र तीमध्ये तीन परीक्षण गर्नुहोस्: एउटा छानिएको यन्त्र, स्थानीय रहनुपर्ने सामान्य यन्त्र, र स्थानीय सेवाहरूमा निर्भर एउटा।
ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10
सार्वजनिक अनुरोध वास्तवमा कहाँ देखा पर्यो भनी तुलना गर्नुहोस्। छानिएको क्लाइन्टले प्रधान कार्यालयको एक्जिटबाट इन्टरनेटमा पुग्नुपर्छ, र सामान्य क्लाइन्टले टाढाको पक्षमा शाखाको आफ्नै ठेगाना अझै देखाउनुपर्छ; 203.0.113.10 तपाईंलाई महत्त्वपूर्ण गन्तव्यको विकल्पको रूपमा प्रयोग गरिने कागजात ठेगाना हो। त्यही चरणमा DNS समावेश गर्नुहोस्, किनकि शाखाको रिजोल्भरलाई सोध्ने क्लाइन्टले फरक स्रोतसहित राउटरबाट उत्पन्न खोजी र त्यसैले फरक रुट उत्पादन गर्न सक्छ।
रोलब्याक भनेको सुरक्षित नीति क्रम र ठेगाना समूह हो। अघिल्लो क्रम पुनर्स्थापित गर्नुहोस्, नीतिबाट समूह हटाउनुहोस्, र दुवै यन्त्र वर्ग फेरि परीक्षण गर्नुहोस्। परिवर्तन अभिलेखसँगै निर्यात गरिएको कन्फिगरेसन राख्नुहोस्, किनकि अर्को इन्जिनियरले कसैले सम्पादन गर्नुअघि कुन नियम फराकिलो थियो भनी जान्नुपर्छ।