निजी सर्किटको वर्णन गर्न सजिलो र प्रतिस्थापन गर्न गाह्रो हुन्छ, किनकि सम्झौताले केबलभन्दा बढी समेट्थ्यो। यसले ह्यान्डओभर, ठेगाना योजना, ढिलाइको अपेक्षा र समर्थन व्यवस्था बोक्थ्यो, र यसको सट्टामा आउने सुरुङले चारैवटा उत्तराधिकारमा पाउँछ, कसैले ती लेखे पनि नलेखे पनि। कटओभर तब असफल हुन्छ जब टोलीले रुटिङ कन्फिगरेसन प्रतिलिपि गर्छ र बाँकीलाई सञ्चालन समस्या भन्छ। आवश्यकताबाट सुरु गर्नुहोस्, त्यसपछि पुरानो रद्द हुनु अघि नयाँ मार्गमा प्रत्येकलाई प्रमाणित गर्नुहोस्।

सर्किटलाई गुणहरूको सूचीमा बदल्नुहोस्

पहिलो प्रश्न यो हो कि पुरानो सेवाले वास्तवमा के हस्तान्तरण गर्यो: सानो सबनेटसहितको रुट गरिएको लिङ्क, वा साइटहरूबीच साझा गरिएको 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 जाँदैन भने मार्गको अधिकतम अनुप्रयोगहरूले अपेक्षा गरेभन्दा सानो हुन्छ र तपाईंले सजावटी होइन, वास्तविक रिग्रेसन भेट्नुभयो। त्यो नतिजालाई पहिलो चरणमा लेखिएका आवश्यकतासँग तुलना गर्नुहोस्, र ती अनुप्रयोगका मालिकहरूले मापन स्वीकार गरेपछि मात्र सर्किट हटाउनुहोस्। त्यही हस्ताक्षरले सफल परीक्षणलाई स्वीकृत स्थानान्तरणमा बदल्छ।

सम्बन्धित लेखहरू