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 संस्करणहरू फरक व्यवहार गर्थे र अन्य विक्रेताले आफ्नै सीमा थप्छन्। दुई छेउको तुलना गर्दा चार कुरा सँगै राख्नुहोस्: अपेक्षित पहिचान, प्रस्तुत पहिचान, प्रकार र प्रमाणीकरण त्रुटि। त्यो समूहले असङ्गतिलाई रायको सट्टा प्रमाण बनाउँछ।