शाखा के सबनेट को मुख्यालय के SonicWall इंटरनेट एग्ज़िट से रूट करें

शाखा के फ़ोन मुख्यालय से बाहर जाने चाहिए जबकि शाखा के लैपटॉप स्थानीय 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 शामिल करें, क्योंकि शाखा के रिज़ॉल्वर से पूछने वाला क्लाइंट राउटर-उद्भूत लुकअप भिन्न स्रोत के साथ और इसलिए भिन्न रूट के साथ उत्पन्न कर सकता है।

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