vpnc गट रहस्य की तुमचे लॉगिन: कोणते फील्ड काय घेते?
vpnc प्रोफाइल गट ID, गट रहस्य आणि XAuth लॉगिन मागते, आणि लोक खात्याचा पासवर्ड चुकीच्या बॉक्समध्ये टाकतात. प्रत्येक फील्ड त्याच्या भूमिकेनुसार नकाशा करा.
कोणी तुम्हाला पहिल्यांदा vpnc प्रोफाइल दिल्यावर क्रेडेन्शियल संवाद चार गोष्टी विचारतो आणि एकच पासवर्ड हवा असल्यासारखा वाचला जातो। तसे नाही: गटाचे आधीच सामायिक केलेले रहस्य आणि वैयक्तिक XAuth लॉगिन वेगळ्या मालकांची वेगळी मूल्ये आहेत, आणि खात्याचा पासवर्ड गट फील्डमध्ये टाकल्यास चुकीच्या बॉक्ससारखा नव्हे तर वाईट पासवर्डसारखा दिसणारा अपयश येतो। हे नकाशा योग्य करणे हेच इथले संपूर्ण काम आहे। खालील प्रोटोकॉल दुसऱ्याचा स्थलांतर प्रकल्प आहे, म्हणून यातले काहीही नवीन IKEv1 बोगदे बांधण्याचा युक्तिवाद नाही।
दोन रहस्ये, दोन मालक, एक संवाद
गट रहस्य गेटवे प्रोफाइलचे असते। त्या प्रोफाइलद्वारे जोडणारे सर्वजण तेच मूल्य वापरतात, आणि म्हणूनच ते व्यक्तीची ओळख करू शकत नाही आणि प्रोफाइलच्या इतर सर्व वापरकर्त्यांसाठी न बदलता एका लॅपटॉपवरून मागे घेता येत नाही। XAuth वापरकर्तानाव आणि पासवर्ड त्याऐवजी माणसाचे असतात, आणि IPsec संबंध आधीच उभा असल्यानंतर गेटवे दुसऱ्या टप्प्यात त्यांचे मूल्यांकन करतो।
लोक हेच दोन-टप्प्यांचे स्वरूप चुकवतात। बोगदा उभारणे आणि वापरकर्ता प्रमाणीकरण वेगळ्या इनपुटसह वेगळ्या देवाणघेवाणी आहेत, म्हणून क्रेडेन्शियल सूचनेपर्यंत कधीही न पोहोचणारा क्लायंट लॉगिनमध्ये अजिबात अपयशी ठरलेला नाही। संवाद एक नव्हे तर दोन स्तंभ म्हणून वाचा: डावीकडे प्रोफाइल-व्यापी मूल्ये, उजवीकडे वैयक्तिक मूल्ये। कनेक्शन अयशस्वी झाल्यावर शेवटी भरलेला स्तंभ आपोआप दोषी स्तंभ नसतो।
फील्ड भूमिकेनुसार नकाशा करा, लेबलनुसार नाही
vpnc प्रकल्प दस्तऐवजात आपल्या सूचनांना नावे देतो, आणि प्रत्येक ग्राफिकल फ्रंटएंड त्यांना पुन्हा लेबल करतो। प्रत्येक मूल्याची भूमिका भाषांतरित करा, मग लेबल महत्त्वाची राहत नाहीत:
| Directive | What it carries | Who owns it |
|---|---|---|
| IPSec gateway | Address or hostname of the remote VPN endpoint | Operator |
| IPSec ID | Group identifier selecting the profile on that gateway | Operator |
| IPSec secret | Group preshared secret, not an account password | Profile, shared |
| Xauth username and password | Credentials for the per-user stage after the tunnel | Person |
गट फील्डजवळ «वापरकर्तानाव» आणि «पासवर्ड» दाखवणारा फ्रंटएंड चुकीचा नाही — ती वेगळ्या नावांखालील तीच तीन मूल्ये आहेत। जे तुटते ते म्हणजे मूल्य त्यात बसते म्हणून बॉक्स भरणे। वापरकर्ता पासवर्ड म्हणून चिकटवलेले गट रहस्य प्रोफाइल प्रमाणित करते आणि नंतर वापरकर्ता टप्प्यावर अपयशी ठरते; गट रहस्य म्हणून चिकटवलेला खाते पासवर्ड आधीच, कोणत्याही सूचनेपूर्वी अपयशी ठरतो आणि मजकुराच्या फील्डमध्ये राहणाऱ्या समस्येसाठी लोकांना फायरवॉलमध्ये पाठवतो।
गट ओळखपत्र काय नाही
गट हा शब्द चुकीच्या वाचनाला आमंत्रण देतो। इथले गट ओळखपत्र कोणते प्रोफाइल कॉन्फिगरेशन लागू करायचे हे गेटवेला सांगणारा निवडकर्ता आहे; डिरेक्टरी सदस्यत्वाबद्दल ते काहीही सांगत नाही, आणि दोन्ही बाजूंचे जुळणारे नाव ऑपरेटर पुष्टी करेपर्यंत योगायोग आहे। अधिकृतता XAuth यशस्वी झाल्यानंतर होते, गेटवे कशाचा सल्ला घेण्यासाठी कॉन्फिगर आहे त्यानुसार ठरते, आणि यातले काहीही क्लायंट संवादात दिसत नाही।
तीच सावधानी गट रहस्यालाही लागू होते। ते जाणणे ओळख नाही, आणि एक रहस्य संघात फिरवणे हा क्लायंट तुम्हाला दाखवू शकत नाही अशा परिणामांसहाचा कार्यचालन निर्णय आहे।
जोडण्यापूर्वी अस्पष्ट सूचना सोडवा
जुन्या हस्तांतरण टिपांमध्ये «समर्पित सार्वजनिक IP वापरा» अशी ओळ अनेकदा असते। ते वाक्य पलीकडील परवानगी यादी तुमचा रहदारी कुठून येण्याची अपेक्षा करते तो पत्ता असू शकतो, हे ऑपरेटर नेटवर्कचे बाहेर जाण्याचे गुणधर्म आहे आणि गेटवे फील्डमध्ये तुम्ही टाइप करणाऱ्या अंतिम बिंदूशी त्याचा काहीही संबंध नाही। मूल्य कुठेही जाण्यापूर्वी दोनपैकी कोणता अभिप्रेत आहे विचारा। उलटे भरल्यास ते प्रत्येक पॅकेटला कधीही उत्तर न देणाऱ्या पत्त्यावर पाठवते, आणि त्यातून येणारी वेळमर्यादा अडवलेल्या पोर्टसारखी वाचली जाते।
संस्थेच्या पडताळलेल्या माध्यमातून चार गोष्टी मागा: कोणता क्लायंट आणि प्रोटोकॉल समर्थित आहे, कोणता अंतिम बिंदू वापरायचा, गेटवे कोणती ओळख सादर करेल, आणि क्रेडेन्शियल कसे सुपूर्द होतात। खरे रहस्ये स्क्रीनशॉट, तिकिटे आणि सामायिक समस्या-निवारण टिपांबाहेर ठेवा। प्रमाणपत्र तपासण्या बंद करू नका आणि वेगळ्या पद्धतीने कॉन्फिगर केलेली सेवा सुसंगत दिसावी म्हणून जुनी सिफर यादी चिकटवू नका, कारण तपासणी कमकुवत करूनच चालणारे कनेक्शन हे तुम्हाला बांधायला सांगितलेले कनेक्शन नाही।
जुने प्रोफाइल प्रामाणिक ठेवा
IKEv1 कालबाह्य आहे, आणि स्थलांतराचा प्रश्न उद्भवल्यावर उद्धृत करायचा दस्तऐवज RFC 9395 आहे। यशस्वी फील्ड नकाशा हा तो प्रोटोकॉल नवीन रचनेत आहे याचा पुरावा नाही; तो बदली नियोजित होईपर्यंत चालणारे कनेक्शन, आणि त्यासोबत लिखित व्याप्ती व त्या स्थलांतराचा मालक विकत घेतो।
नंतर संवादाच्या विरुद्ध नव्हे, तर आवश्यकतेच्या विरुद्ध पडताळा। जोडल्यानंतर बोगदा इंटरफेसकडे अपेक्षित पत्ता आहे आणि अंतर्गत गंतव्य त्यातून मार्गक्रमण होते याची खात्री करा; मूळ आवश्यकतेत परवानगी यादीसाठी बाहेर जाण्याचा पत्ता नमूद केला असेल, तर तो पत्ताही तपासा, कारण ते बोगदा उभा असण्यापेक्षा वेगळे तथ्य आहे। योग्य प्रमाणीकरण करून काहीही मार्गक्रमण न करणारे प्रोफाइल ज्या कामासाठी तयार झाले ते अजूनही चुकले आहे।