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 आवृत्त्या वेगळ्या पद्धतीने वागल्या आणि इतर विक्रेते स्वतःचे निर्बंध जोडतात। दोन्ही टोके तुलना करताना चार गोष्टी एकत्र ठेवा: अपेक्षित ओळख, सादर केलेली ओळख, प्रकार आणि प्रमाणीकरण त्रुटी। हा संच विसंगतीला मताऐवजी पुरावा बनवतो।