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

{एक पैकेट दूसरे के अंदर, दो डिलीवरी मॉडल}

{रूटेड मोड में वर्चुअल इंटरफ़ेस 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 पता-समाधान उसी रूप में इस्तेमाल नहीं करता; वह पड़ोसी खोज इस्तेमाल करता है। परतों वाला प्रश्न अपरिवर्तित रहता है: असली बाहरी पैकेट स्थानीय अगले हॉप तक कैसे पहुँचता है, और क्या साबित करता है कि उत्तर वर्तमान है।}

{डिज़ाइन को पूर्ण घोषित करने से पहले दूसरे स्टैक पर वही दो तथ्य जाँचें, क्योंकि दोनों परिवार ढोने वाली टनल के पास विचार करने के लिए दो बाहरी रास्ते हैं। लिखें कि किसे आपने सत्यापित किया और किसे मान लिया।}

संबंधित लेख