{एउटै जडानमा दुई प्याकेट यात्रा गर्छन् र तिनीहरू फरक नियम पालना गर्छन्। एउटा निजी प्याकेट हो जुन टनेलले बोक्छ, जसलाई भर्चुअल इन्टरफेसले कुनै पनि इथरनेट हेडर बिना सम्हाल्छ। अर्को इन्क्रिप्ट गरिएको प्याकेट हो जुन मेसिनलाई पहुँच लिङ्कबाट छोड्छ, र त्यसलाई अझै हार्डवेयर ठेगानामा समाधान हुने स्थानीय अर्को हप चाहिन्छ। यी दुईलाई मिसाउनु नै मानिसहरूले गलत इन्टरफेसमा ठेगाना समाधान बन्द गरेर टनेल किन कहिल्यै सुरु हुँदैन भनी अचम्म मान्ने कारण हो।}

{एउटा प्याकेट अर्कोभित्र, दुई डेलिभरी मोडेल}

{राउटेड मोडमा भर्चुअल इन्टरफेसले IP प्याकेट स्वीकार गर्छ। यसमा इथरनेट हेडर, ब्रोडकास्ट डोमेन र भित्र समाधान गर्ने ठेगाना हुँदैन, त्यसैले भित्री प्याकेट टनेल आफैँले पुर्‍याउँछ। पहुँच सञ्जालमा हुने कुरा छुट्टै डेलिभरी तह हो।}

inner packet: private address -> tunnel device -> the VPN process
outer packet: endpoint address -> access route -> next-hop hardware address

{त्यो बाहिरी प्याकेट इथरनेट इन्टरफेस छोड्दा सामान्य युनिकास्ट फ्रेम हो, र यसलाई आफ्नो अर्को हपको गन्तव्य हार्डवेयर ठेगाना चाहिन्छ। ठेगाना समाधानले त्यो दिन्छ, र अर्को हप सामान्यतया टाढाको सर्भर नभई स्थानीय गेटवे हुन्छ। खोज एन्डपोइन्टका लागि नभई गेटवेका लागि हो भन्ने बुझ्नु नै निदानको ठूलो भाग हो। केही परिवर्तन गर्नुअघि दुवै ठेगाना लेख्नुहोस्।}

{साँच्चै महत्त्वपूर्ण छिमेकी भेट्टाउनुहोस्}

{राउटिङ तालिकालाई एन्डपोइन्टले कुन अर्को हप प्रयोग गर्छ भनी सोध्नुहोस्, त्यसपछि त्यो हपका लागि छिमेकी तालिका जाँच्नुहोस्। एन्डपोइन्ट आफैँ त्यहाँ विरलै देखिन्छ, किनकि त्यो स्थानीय लिङ्कमा छैन।}

ip route get 198.51.100.20
ip neigh show 192.168.0.1

{यदि प्रविष्टि छ र पुग्न सकिने छ भने, बाहिरी मार्ग ठीक छ र त्रुटि अन्यत्र छ। यदि त्यो छैन वा असफल अवस्थामा छ भने, लिङ्क, गेटवे ठेगाना वा समाधान रोक्ने नीति हेर्ने ठाउँ हो। टनेलमा साइफर सेटिङ बदल्नाले दुवै अवस्थामा मद्दत गर्न सक्दैन। छिमेकी तालिकाले रिपोर्ट गर्ने अवस्था-स्ट्रिङ नोट गर्नुहोस्, किनकि यसले चलिरहेको प्रयासलाई स्थायी असफलताबाट छुट्याउँछ।}

{सिकेको प्रविष्टिले निर्भरता लुकाउन सक्छ}

{क्यास गरिएको प्रविष्टि त्यसलाई बनाउने कुरा गएपछि पनि केही समय काम गरिरहन्छ, त्यसैले परिवर्तनको केही मिनेटपछि गरिएको परीक्षण गलत कारणले पास हुन सक्छ। समाधान अनावश्यक छ भनी निष्कर्ष निकाल्नुअघि प्रविष्टि पुरानो हुने प्रतीक्षा गर्नुहोस्, वा जानाजान मेट्नुहोस्।}

{उल्टो गल्ती पनि उत्तिकै सामान्य छ: समाधान नगरिएको प्रविष्टिलाई टनेल बिग्रिएको प्रमाण मानिन्छ। व्यवहारमा यसले स्थानीय खण्ड, दोहोरो ठेगाना वा जवाफ बोक्ने फ्रेम फाल्ने पोर्ट सुरक्षा नियमतर्फ संकेत गर्छ। VPN कन्फिगरेसन छुनुअघि स्विच पोर्ट जाँच्नुहोस्।}

{समयलाई प्रमाणका रूपमा पढ्नुहोस्। समाधान भएर फेरि-फेरि सकिने प्रविष्टिले हल्लिने लिङ्क वा एउटै ठेगानाका लागि जवाफ दिने दुई उपकरणतर्फ संकेत गर्छ, जबकि कहिल्यै समाधान नहुने प्रविष्टिले गेटवे ठेगाना वा पहुँच पोर्टमा फिल्टरिङतर्फ संकेत गर्छ।}

{गतिशील समाधान र स्थिर प्रविष्टिबीच निर्णय गर्नुहोस्}

{गतिशील समाधान एउटा कारणले पूर्वनिर्धारित छ: गेटवे फेरिँदा यो हार्डवेयरको पछि लाग्छ र कसैसँग समन्वय चाहिँदैन। स्थिर प्रविष्टि तब उचित हुन्छ जब सञ्जाल जानाजान व्यवस्थापन गरिन्छ र ठेगाना तथा हार्डवेयर ठेगानाको जोडी दस्तावेजीकृत डिजाइनको भाग हो।}

ApproachGood fitCost you accept
Dynamic resolutionLaptops, changing networks, anything with a spare minute to recoverA short outage while the entry is relearned
Permanent entryFixed appliances where the pairing is controlled and recordedA silent failure the day the hardware changes

{जसरी भए पनि, छनोट बाहिरी प्याकेट बोक्ने पहुँच इन्टरफेसमा लागू गर्नुहोस्। त्यो इन्टरफेसमा समाधान बन्द गर्दा टनेल बलियो हुँदैन; यसले ग्राहकको त्यो गेटवेसम्म पुग्ने क्षमता हटाउँछ जसले यसलाई बोक्छ, र असफलता स्थानीय ठेगाना समस्याजस्तो नभई मृत VPN जस्तो देखिन्छ।}

{अर्को स्ट्याक पनि सम्झनुहोस्}

{IPv6 ले ठेगाना समाधान त्यही रूपमा प्रयोग गर्दैन; यसले छिमेकी खोज प्रयोग गर्छ। तहको प्रश्न अपरिवर्तित रहन्छ: वास्तविक बाहिरी प्याकेट स्थानीय अर्को हपसम्म कसरी पुग्छ, र जवाफ हालको छ भनी केले प्रमाणित गर्छ।}

{डिजाइन पूर्ण घोषणा गर्नुअघि अर्को स्ट्याकमा पनि ती दुई तथ्य जाँच्नुहोस्, किनकि दुवै परिवार बोक्ने टनेलसँग विचार गर्नुपर्ने दुई बाहिरी मार्ग छन्। कुन तपाईंले प्रमाणित गर्नुभयो र कुन अनुमान गर्नुभयो लेख्नुहोस्।}

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