शाखेचे सबनेट मुख्यालयाच्या 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 समाविष्ट करा, कारण शाखेच्या रिझोल्व्हरला विचारणारा क्लायंट राउटर-उगमस्थान असलेला वेगळ्या स्रोताचा शोध तयार करू शकतो आणि त्यामुळे वेगळा मार्ग।

रोलबॅक म्हणजे जतन केलेला धोरण क्रम आणि पत्ता गट। पूर्वीचा क्रम पुनर्संचयित करा, धोरणातून गट काढा, आणि दोन्ही उपकरण वर्ग पुन्हा तपासा। बदल नोंदीसोबत निर्यात केलेली संरचना ठेवा, कारण पुढील अभियंत्याला कोणी संपादित करण्यापूर्वी कोणता नियम व्यापक होता हे माहीत असणे आवश्यक आहे।