IPv6 पत्ता कोलनांनी भरलेला असतो, आणि पोर्टही ठेवणाऱ्या एंडपॉइंट फील्डला पत्ता कुठे संपतो हे दर्शवण्याची पद्धत लागते. हे चुकीचे केल्यास क्लायंट एकतर प्रोफाइल पार्स करण्यास नकार देतो किंवा शांतपणे चुकीच्या गोष्टीशी जोडतो. योग्य स्वरूप सार्वत्रिक नाही: ते फील्डमध्ये पत्ता आणि पोर्ट, केवळ पत्ता, की होस्टनेम आहे यावर अवलंबून असते. रनबुक क्रमाने पूर्ण करा, कारण क्लायंटचे आउटपुट वाचायला सुरुवात केल्यावर सिंटॅक्स दुरुस्ती आणि पोहोच दुरुस्ती पूर्णपणे वेगळ्या दिसतात.

पत्ता लिहिण्यापूर्वी फील्डचा प्रकार तपासा

उदाहरणार्थ, WireGuard Endpoint फील्डमध्ये पोर्टसह IPv6 लिटरल पत्त्याभोवती कंस वापरते, जसे [2001:db8::10]:51820 मध्ये. त्या उदाहरणातील दस्तऐवजीकरण उपसर्ग सार्वजनिक सर्व्हर नाही, आणि कंस सिंटॅक्सचा भाग आहेत, पत्त्याचा नाही.

इतर स्वरूपांना स्वतःचे नियम असतात. URI कंसांमध्ये IPv6 लिटरल ठेवू शकतो, पण VPN कॉन्फिगरेशन जरूरीचे URI नाही. स्वतंत्र पत्ता आणि पोर्ट बॉक्स असलेला क्लायंट एका बॉक्समध्ये केवळ लिटरल आणि दुसऱ्यात संख्या अपेक्षित धरू शकतो, आणि तिथे कंस जोडणे एकत्रित फील्डमध्ये ते सोडण्याइतकेच चुकीचे आहे.

पोर्ट तेच फील्ड सामायिक करत असेल तर लिटरल कंसात ठेवा

लक्षात ठेवण्याचा नियम सोपा आहे: त्याच स्ट्रिंगमध्ये पोर्ट आला तर कंस येतात. पोर्ट नसलेल्या फील्डमध्ये पत्ता एकटाच उभा असेल तर ते येत नाहीत.

एका प्रोटोकॉलची पूर्ण एंडपॉइंट स्ट्रिंग प्रत्येक क्लायंटमध्ये कॉपी करणे हे या त्रुटीचे नेहमीचे कारण आहे. OpenVPN, IPsec प्रोफाइल आणि अनुप्रयोग इंटरफेस प्रत्येकी आपले सिंटॅक्स दस्तऐवजीकरण करतात, आणि एकासाठी योग्य स्ट्रिंग दुसऱ्याने नाकारली किंवा चुकीची अर्थ लावली जाऊ शकते. तुम्ही संपादित करत असलेल्या फील्डसाठी क्लायंटचे स्वतःचे दस्तऐवजीकरण वाचा, आणि दस्तऐवजीकरण उपसर्ग किंवा उदाहरण पत्ता टिप्पणीत ठेवा जेणेकरून कोणीही तो खरा होस्ट म्हणून पाठवणार नाही. मॅन्युअल दोन स्वरूप देत असेल तर तुमच्यासमोरच्या फील्ड प्रकाराशी जुळणारे वापरा.

पत्ता आणि पोर्ट फील्ड वेगळे करा

क्लायंट दोन बॉक्स देत असेल तर पत्ता एकात आणि पोर्ट दुसऱ्यात ठेवा. पत्ता बॉक्समध्ये पेस्ट केलेले एकत्रित स्वरूप पार्स त्रुटी किंवा, त्याहून वाईट, अनपेक्षित गोष्टीत निराकरण होणारा पत्ता निर्माण करते.

मूल्य बरोबर दिसत असताना शेवटच्या स्पेस आणि अदृश्य अक्षरे तपासा. कॉपी केलेल्या पत्त्यात अनेकदा न तोडणारी स्पेस किंवा शून्य-रुंदीचे अक्षर असते जे क्लायंट पार्स करू शकत नाही आणि स्क्रीन दाखवत नाही. त्रुटीचा अर्थ नसेल तर पेस्ट करण्याऐवजी मूल्य पुन्हा टाइप करा.

झोन ओळखकर्त्यांना काळजीपूर्वक हाताळा

लिंक-लोकल लिटरलला इंटरफेसशी जोडलेला झोन ओळखकर्ता लागू शकतो, जो टक्के चिन्ह आणि इंटरफेसच्या नावाने लिहिला जातो. ते स्वरूप इंटरफेस असलेल्या होस्टवर वैध आहे, आणि ते सर्वसाधारणपणे पोहोचण्यायोग्य दूरच्या एंडपॉइंटची जागा घेत नाही.

पार्स यशस्वी झाल्यावरही व्याप्ती आणि मार्गक्रमण महत्त्वाचे आहे. क्लायंट स्वीकारत असलेल्या झोन-पात्र पत्त्याला मशीनमधून कोणताही मार्ग नसू शकतो, आणि इंटरनेटवरून पोहोचणाऱ्या दूरच्या एंडपॉइंटने स्थानिक झोनवर अजिबात अवलंबून राहू नये. हँडशेक अयशस्वी झाल्यानंतर नाही, झोन लिहिण्यापूर्वी पॅकेट कोणत्या इंटरफेसने बाहेर पडावे हे ठरवा.

आधी पार्स, नंतर पोहोच तपासा

दोन अपयश स्पष्टपणे वेगळे करा. विकृत पत्ता पार्स त्रुटी किंवा तत्काळ नकार निर्माण करतो, तर सुबद्ध एंडपॉइंट प्रमाणीकरण नाकारत असेल किंवा कधीही उत्तर देत नसेल तर ती वेगळ्या उपायाची वेगळी समस्या आहे.

समर्थित दुरुस्तीनंतर बोगदा वाटाघाटी करतो आणि इच्छित अनुप्रयोग चालतो याची खात्री करा. केवळ हँडशेक मार्ग सिद्ध करत नाही, आणि एंडपॉइंटवर ping बोगदा सिद्ध करत नाही। जिथे ऑपरेटर होस्टनेम देतो तिथे समर्थित नाव आणि त्याची ओळख तपासणी ठेवा, ते अन्यत्र सापडलेल्या अंकीय पत्त्याने बदलू नका.

बदल टिप्पणीत नेमके फील्ड, तुम्ही वापरलेले मूल्य आणि क्लायंटचा प्रतिसाद नोंदवा. नाहीतर प्रोफाइल संपादित करणारी पुढील व्यक्ती कंसाचा प्रयोग पुन्हा करेल, आणि उत्तर आधीच तुमच्या तिकिटात आहे.

संबंधित लेख