VPN कटओवर को निजी सर्किट से क्या सुरक्षित रखना चाहिए

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

सर्किट को गुणों की सूची में बदलें

पहला प्रश्न यह है कि पुरानी सेवा ने वास्तव में क्या सौंपा: छोटे सबनेट वाला रूटेड लिंक, या साइटों के बीच साझा लेयर 2 सेगमेंट। यह अंतर तय करता है कि IP टनल उसे बिलकुल भी दोहरा सकती है या नहीं, क्योंकि टनल दो पतों के बीच पैकेट ले जाती है और ब्रॉडकास्ट खोज या मनमाने EtherTypes नहीं ले जाती। जिस सर्किट ने स्वयं को स्विच पोर्ट के रूप में प्रस्तुत किया, वह /30 प्रस्तुत करने वाले सर्किट से भिन्न माइग्रेशन है।

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

नए मार्ग को दोनों दिशाओं में रूट करें

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

ip route get 10.20.0.10

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

उस रोलबैक के साथ स्विच करें जिसे आप पहले ही जाँच चुके हैं

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

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

उस ट्रैफ़िक के साथ स्वीकार करें जो सर्किट वास्तव में ले जाता था

Ping पहुँच सिद्ध करता है और बहुत कम और। नाम विश्लेषण, लंबे समय तक चलने वाले सत्र, अस्वीकृत प्रवाह और उन पैकेट आकारों की जाँच करें जिन्हें पुराना मार्ग बिना विखंडन के संभालता था। MTU वह जगह है जहाँ टनल सर्किट से सबसे अधिक भिन्न होती हैं, क्योंकि एनकैप्सुलेशन उन बाइटों को खर्च करता है जिन्हें अनुप्रयोग उपलब्ध मानता था। दोनों दिशाओं में बिना विखंडन के गुजरने वाला सबसे बड़ा पेलोड मापें, केवल सर्वर की ओर नहीं।

ping -M do -s 1400 -c 3 10.20.0.10

यदि 1400 बाइट का पेलोड गुजरता है और 1472 नहीं, तो मार्ग का अधिकतम अनुप्रयोगों की अपेक्षा से छोटा है और आपने वास्तविक रिग्रेशन पाया है, सजावटी नहीं। उस परिणाम की तुलना पहले चरण में लिखी आवश्यकताओं से करें, और सर्किट को तभी हटाएँ जब उन अनुप्रयोगों के स्वामी माप स्वीकार करें। यही हस्ताक्षर सफल परीक्षण को स्वीकृत माइग्रेशन में बदलता है।