VPN कॉन्फ़िगरेशन में IPv6 एंडपॉइंट कैसे लिखें

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

पता लिखने से पहले फ़ील्ड का प्रकार जाँचें

एक WireGuard Endpoint फ़ील्ड के लिए पोर्ट सहित IPv6 लिटरल पते के चारों ओर कोष्ठक लगाता है, जैसे [2001:db8::10]:51820 में। उस उदाहरण का दस्तावेज़ीकरण प्रीफ़िक्स सार्वजनिक सर्वर नहीं है, और कोष्ठक सिंटैक्स का हिस्सा हैं, पते का नहीं।

अन्य प्रारूपों के अपने नियम हैं। URI कोष्ठकों में IPv6 लिटरल रख सकता है, लेकिन VPN कॉन्फ़िगरेशन ज़रूरी नहीं कि URI हो। अलग पता और पोर्ट बॉक्स वाला क्लाइंट एक बॉक्स में केवल लिटरल और दूसरे में संख्या की अपेक्षा कर सकता है, और वहाँ कोष्ठक जोड़ना संयुक्त फ़ील्ड में उन्हें छोड़ देने जितना ही गलत है।

जब पोर्ट वही फ़ील्ड साझा करे तो लिटरल को कोष्ठक में रखें

याद रखने वाला नियम सरल है: कोष्ठक तब आते हैं जब उसी स्ट्रिंग में पोर्ट आता है। वे तब नहीं आते जब पता बिना पोर्ट वाले फ़ील्ड में अकेला खड़ा हो।

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

पता और पोर्ट फ़ील्ड अलग रखें

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

जब कोई मान सही दिखे तो पीछे के स्पेस और अदृश्य अक्षर जाँचें। कॉपी किया गया पता अक्सर नॉन-ब्रेकिंग स्पेस या शून्य-चौड़ाई वाला अक्षर रखता है जिसे क्लाइंट पार्स नहीं कर सकता और स्क्रीन नहीं दिखाती। जब त्रुटि बेतुकी लगे तो चिपकाने के बजाय मान फिर से टाइप करें।

ज़ोन पहचानकर्ताओं को सावधानी से संभालें

लिंक-लोकल लिटरल को इंटरफ़ेस से जुड़ा ज़ोन पहचानकर्ता चाहिए हो सकता है, जो प्रतिशत चिह्न और इंटरफ़ेस नाम के साथ लिखा जाता है। वह रूप उस होस्ट पर मान्य है जो इंटरफ़ेस का स्वामी है, और यह सामान्य रूप से पहुँचने योग्य दूरस्थ एंडपॉइंट का विकल्प नहीं है।

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

पहले पार्स की, फिर पहुँच की जाँच करें

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

समर्थित सुधार के बाद पुष्टि करें कि टनल बातचीत करता है और इच्छित एप्लिकेशन काम करता है। अकेला हैंडशेक पथ सिद्ध नहीं करता, और एंडपॉइंट पर ping टनल सिद्ध नहीं करता। जहाँ ऑपरेटर होस्टनाम देता है, वहाँ समर्थित नाम और उसकी पहचान जाँच बनाए रखें, उसे कहीं और मिले संख्यात्मक पते से न बदलें।

परिवर्तन नोट में सटीक फ़ील्ड, आपने जो मान इस्तेमाल किया और क्लाइंट की प्रतिक्रिया लिखें। वरना प्रोफ़ाइल संपादित करने वाला अगला व्यक्ति कोष्ठक वाला प्रयोग दोहराएगा, और उत्तर पहले से आपके टिकट में है।