आउने IPsec पियर कुनै प्रोफाइलसँग मिल्दैन? चार फिल्ड जाँच्नुहोस्
फाइलमा रहेको जडान नाम तबसम्म केही प्रमाणित गर्दैन जबसम्म चलिरहेको प्रतिक्रियाकर्ताले त्यसलाई छान्दैन। लोड गरिएको परिभाषा, अन्त्य बिन्दु, पहिचान र चयनकर्ताहरू तुलना गर्नुहोस्।
तपाईंको पियरले सुरुङ माथि रहेको जनाउँछ, तपाईंको पक्षले कुनै सुरक्षा सम्बन्ध देखाउँदैन, र कन्फिगरेसन फाइलमा स्पष्ट रूपमा मिल्ने जडान नाम छ। यी तीनै भनाइहरू एकैसाथ सत्य हुन सक्छन्। आउने वार्ता चलिरहेको कन्फिगरेसनसँग मिलाइन्छ, पियरको ठेगाना, उसले प्रस्तुत गर्ने पहिचान र उसले सुझाउने ट्राफिकको आधारमा। डिस्कमा रहेको कहिल्यै लोड नगरिएको फाइल, अपेक्षित मानसँग नमिल्ने पहिचान, वा एक प्रिफिक्सले च्युत भएको चयनकर्ता जोडी — प्रत्येकले मौनता उत्पन्न गर्छ। प्रतिक्रियाकर्ताले हिँड्ने क्रममै चार फिल्ड समूह पार गर्नुहोस्।
फाइलबाट होइन, प्याकेटबाट सुरु गर्नुहोस्
प्रतिक्रियाकर्ताले IKE अनुरोध प्राप्त गर्छ, यो पियरलाई स्वीकार गर्न सक्ने परिभाषा खोज्छ, र त्यसपछि प्रमाणीकरण र ट्राफिक छनोटसँग अगाडि बढ्छ। पहिलो चरणमा कुनै पनि लोड गरिएको परिभाषा मिलेन भने उपयोगी त्रुटि प्रयोगकर्तासम्म पुग्नुअघि नै वार्ता अन्त्य हुन्छ।
त्यसैले “कन्फिगरेसन ठीक देखिन्छ” प्रमाण होइन। प्रश्न यो हो कि चलिरहेको सेवाले के लोड गरेको छ र यो प्रयासका लागि कुन प्रविष्टि छानेको छ। स्थिति सूचीले एउटै आदेशमा त्यसको उत्तर दिन्छ, जबकि सम्पादक बफरले अर्को प्रश्नको उत्तर दिन्छ। फाइल फेरि बदल्नुअघि सूची जाँच्नुहोस्।
पहिलो फिल्ड समूह: साँच्चै लोड भएको परिभाषा
चलिरहेको स्थिति डेमनको स्वामित्वमा रहेको उपकरणले जाँच्नुहोस्: लोड गरिएका जडान सूचीबद्ध गर्ने स्थिति आदेश, सम्पादक बफर होइन। अपेक्षित प्रविष्टि छ, तपाईंले चाहेको सुरुवाती व्यवहारका लागि सक्षम छ, र तपाईंको अन्तिम सम्पादनपछि लोड भएको छ भनी पुष्टि गर्नुहोस्। सुरक्षित तर पुनः लोड नगरिएको फाइल “ठीक गरें र केही बदलिएन” भन्नेको सबैभन्दा सामान्य कारण हो।
सेवाले कुन फाइल पढ्छ भनी पनि पुष्टि गर्नुहोस्। वितरणहरू फरक हुन्छन्, र गलत समावेशमा लेखिएको जडान अस्वीकार गर्नुको सट्टा चुपचाप बेवास्ता गरिन्छ। स्थिति सूचीले तपाईंको प्रविष्टि बिलकुलै देखाएन भने वाक्यरचनाभन्दा पहिले समावेश मार्गमा शंका गर्नुहोस्।
दोस्रो फिल्ड समूह: अन्त्य बिन्दुहरू पहिचान होइनन्
पियर जुन ठेगानाबाट जोडिन्छ र जुन पहिचानले प्रमाणीकरण गर्छ ती छुट्टै फिल्ड हुन्। होस्टनाम, विशिष्ट नाम, कुञ्जी आईडी र ठेगाना — कन्फिगरेसनअनुसार सबै IKE पहिचान बन्न सक्छन्, र तिनीहरू सार्वजनिक ठेगानाजस्तो देखिनु आवश्यक छैन।
अन्त्य बिन्दु मिलानमा NAT दृष्टिकोण पनि समावेश हुन सक्छ: सञ्जालमा देखिने ठेगाना पियरले आफूसँग छ भनी ठान्ने ठेगानाभन्दा फरक हुन सक्छ। libreswan को जडान मोडेलमा left र right दुई सहभागीका लेबल हुन्, स्थिर स्थानीय-दूर क्रम होइन, त्यसैले अर्को साइटको चल्ने कन्फिगरेसन प्रतिलिपि गरेर ठेगाना बदल्नु विश्वसनीय अनुवाद होइन।
दुवै पक्षको अपेक्षित पहिचान र त्यसलाई प्रमाणित गर्ने प्रमाणपत्र लेख्नुहोस्। ती दुई लाइन मिलेनन् भने ठेगाना जतिसुकै मिलाए पनि मिलान हुँदैन।
तेस्रो फिल्ड समूह: संरक्षित ट्राफिक
चयनकर्ताले आन्तरिक स्रोत र गन्तव्य दायरा, तिनको ठेगाना परिवार र कुनै पनि प्रोटोकल वा पोर्ट प्रतिबन्ध वर्णन गर्छन्। एउटा होस्ट ठेगानाका लागि प्रस्ताव पूरै सबनेटका लागि अनुरोध जस्तै होइन, र सबनेटका लागि कन्फिगर गरिएको प्रतिक्रियाकर्ताले त्यसलाई अस्वीकार वा साँघुरो बनाउन सक्छ।
दुई छेउ नमिल्दा केही जोडियोस् भनेर हरेक चयनकर्ता फराकिलो बनाउनुको सट्टा दुवै दृष्टिकोणबाट अभिप्रेत प्रवाह तुलना गर्नुहोस्। हरेक प्रशासकलाई आफूले संरक्षण गरेको ठान्ने प्रवाह सोध्नुहोस्, त्यसपछि दुई उत्तर तुलना गर्नुहोस्। असमझदारी सामान्यतया एकातर्फ होस्ट प्रिफिक्स र अर्कातर्फ सबनेट हुन्छ। अहिले सबै संरक्षण गर्ने भएकाले मिल्ने सुरुङ अर्को सुरक्षा निर्णय हो, र कसैले स्वीकृत नगरेको निर्णय।
चौथो फिल्ड समूह: तपाईं एउटा कार्यान्वयन पढ्दै हुनुहुन्छ
Libreswan, पुरानो Openswan र strongSwan का व्यवस्थापन उपकरण, कन्फिगरेसन वाक्यरचना र मिलान क्रम फरक छन्। एउटाको चल्ने उदाहरणले अर्काको प्रोफाइल छनोट प्राथमिकता वा त्रुटि शब्दावलीबारे केही ठ्याक्कै भन्दैन, त्यसैले यो होस्टको डेमनका कागजातसँग प्रमाणित गर्नुहोस्।
एउटा प्रयास सुरुदेखि अन्त्यसम्म जोड्नुहोस्: सुरु गर्नेको स्रोत ठेगाना, प्रस्तुत पहिचान र सुझाइएका चयनकर्ता — प्रतिक्रियाकर्ताको छनोट सन्देश र उसले नाम दिएको लोड गरिएको प्रविष्टिसँग। शून्य इन्क्याप्सुलेसन र डिक्याप्सुलेसन काउन्टरले अवलोकन गरिएका सम्बन्धले ती प्याकेट बोकेका छैनन् भन्ने मात्र भन्छन्; तिनले प्रस्ताव अस्वीकार गर्ने अन्त्य बिन्दुको नाम दिँदैनन् र त्यस क्षण मिल्ने प्रविष्टि थियो भनी प्रमाणित गर्दैनन्।
समन्वित सुधारपछि छानिएको प्रोफाइल र सम्बन्ध पुष्टि गर्नुहोस्, त्यसपछि वास्तवमै अनुमति दिइएको सेवा र त्यसको प्रतिक्रिया मार्ग परीक्षण गर्नुहोस्। प्रोफाइल मिलानले वार्ता सम्भव बनाउँछ, र वार्ता अन्तिम पहुँच जाँच होइन।