IKE पहचान या एंडपॉइंट पता: इन्हें मिलाएँ नहीं
FQDN प्रकार की IKE पहचान एक शाब्दिक प्रमाणीकरण मान है, रिवर्स-DNS लुकअप नहीं। एंडपॉइंट पता, स्थानीय पहचान और अपेक्षित peer को अलग रखें।
FQDN पहचान के रूप में लेबल किए गए फ़ील्ड को शाब्दिक स्ट्रिंग के रूप में पढ़ें, अपने सार्वजनिक पते के रिवर्स-DNS नाम के अनुरोध के रूप में नहीं। strongSwan के पार्सर में यह ठीक वही है, एक स्ट्रिंग, और इसे पढ़ने से यह कभी किसी एंडपॉइंट में हल नहीं होता। यह तथ्य अकेले ही सबसे आम ध्यान-भटकाव को हटा देता है जब आप किसी peer के लिए पहचानकर्ता चुनते हैं। नीचे दी गई जाँचें तीनों संबंधित मानों को एक में पिघलने से रोकती हैं।
लेबल कोई लुकअप नहीं है
विक्रेता इंटरफ़ेस FQDN और hostname जैसे शब्दों को ढीले ढंग से उपयोग करते हैं, और बॉक्स पर लगा लेबल उसके पीछे के एन्कोडिंग के बारे में कुछ नहीं कहता। जो उपकरण किसी फ़ील्ड को Client FQDN कहता है, वह FQDN, ईमेल के आकार की स्ट्रिंग या नंगा पता भेज सकता है। टेक्स्ट और प्रकार को दो अलग निर्णय मानें और दोनों दर्ज करें।
शाब्दिक पहचान में कुछ भी DNS की माँग नहीं करता। यह एक दावा है जिसे दूसरा सिरा जाँचता है, ऐसा नाम नहीं जिसे नेटवर्क को हल करना हो।
तीन अलग मान, अलग-अलग लिखे गए
एक कॉन्फ़िगरेशन स्क्रीन के पीछे तीन काम हैं, और उन्हें मिलाना महँगी गलती है। एक मान है एंडपॉइंट पता, जो तय करता है कि पैकेट कहाँ जाएँगे। दूसरा वह स्थानीय पहचान है जो यह peer प्रस्तुत करता है, और तीसरा वह पहचान है जिसकी आप प्रमाणीकरण से पहले दूर के सिरे से अपेक्षा करते हैं। उन्हें चेंज टिकट में तीन पंक्तियों के रूप में लिखें, क्योंकि इससे कम कुछ भी VPN का वर्णन करता है, रिश्ते का नहीं।
| Job | Example | What it decides |
|---|---|---|
| Where the packets go | 198.51.100.7 | The endpoint address |
| What this peer claims | gw.branch.internal | The local IKE identity |
| Who should answer | ike.hub.internal | The expected remote identity |
उदाहरण पहचानों को परिनियोजन के हिस्से के रूप में चुना और अधिकृत करना होता है। वे ऐसे दावे हैं जिन्हें प्रमाणीकरण सत्यापित करता है, ऐसे क्रेडेंशियल नहीं जो किसी भी peer को भरोसेमंद बना दें, इसलिए विश्वसनीय दिखने वाली स्ट्रिंग कुछ भी अधिकृत नहीं करती।
प्रकार मान का हिस्सा है
strongSwan पहचान संदर्भ FQDN, ईमेल के आकार के मान, IP पते और अन्य एन्कोडिंग को अलग करता है, इसलिए एन्कोडिंग उतनी ही मायने रखती है जितने अक्षर। दो उपकरण अलग-अलग प्रकारों के अंतर्गत एक ही टेक्स्ट स्वीकार कर सकते हैं और फिर भी एक-दूसरे को अस्वीकार कर सकते हैं। प्रकार के बिना मान दर्ज करने वाला नोट आधा कॉन्फ़िगरेशन है।
विक्रेता से पूछें कि उपकरण वास्तव में कौन-सा प्रकार भेजता है, और इंटरफ़ेस लेबल के बजाय डिकोड के विरुद्ध पुष्टि करें। अनुमानित प्रकार अगले बदलाव का इंतज़ार करती असंगति है।
हर पक्ष को दूसरे को संतुष्ट करना होता है
हर पक्ष की स्थानीय पहचान को दूसरे पक्ष की प्रमाणीकरण नीति पार करनी होती है। यह दोनों उपकरणों के हर पहचान बॉक्स में एक ही स्ट्रिंग चिपकाने जैसा नहीं है, जो वह शॉर्टकट है जो ऐसा कॉन्फ़िगरेशन बनाता है जिसे कोई डीबग नहीं कर सकता।
प्रमाणपत्र प्रमाणीकरण अपनी अलग आवश्यकताएँ जोड़ता है, क्योंकि प्रमाणपत्र की पहचान और भरोसे की शर्तें आपके द्वारा टाइप की गई IKE पहचान के साथ बैठती हैं। केवल IKE पहचान का मेल प्रमाणपत्र वाले peer को अधिकृत नहीं करता।
DNS कहाँ मायने रखता है, और आपका संस्करण क्या थोपता है
खोज के लिए उपयोग किया गया गेटवे hostname वास्तव में काम करने वाला DNS चाहता है, और वह आवश्यकता एंडपॉइंट खोजने की है, टाइप की गई पहचान के किसी रिवर्स लुकअप की नहीं। टिकट में दोनों को अलग रखें, क्योंकि खोज विफलता और पहचान असंगति क्लाइंट लॉग में एक जैसी पढ़ी जाती हैं और अलग-अलग जगहों पर ठीक होती हैं।
प्रकार थोपने वाला सिंटैक्स कॉपी करने से पहले उस उत्पाद और संस्करण का पार्सर पढ़ें जिसे आप वास्तव में चलाते हैं, क्योंकि पुराने strongSwan संस्करण अलग व्यवहार करते थे और अन्य विक्रेता अपनी बाधाएँ जोड़ते हैं। जब आप दोनों सिरों की तुलना करें, चार चीज़ें साथ रखें: अपेक्षित पहचान, प्रस्तुत पहचान, प्रकार और प्रमाणीकरण त्रुटि। यह समुच्चय असंगति को राय के बजाय साक्ष्य बना देता है।