IPsec प्रोफाइलमा पाँच ठेगाना भूमिका, र कुन गलत छ

सामान्य जडान परिभाषामा पाँच फरक कामले ठेगाना पाउँछन्, र तिनीहरू एकअर्कासँग मिल्नैपर्ने छैन। प्रशासकहरू अलपत्र पर्छन् किनभने सबै फिल्ड एउटै होस्टतर्फ देखाउने समझदार प्रवृत्ति तिनमध्ये कम्तीमा तीनका लागि गलत छ। निकास भनेको पहिले लक्षणको नाम दिनु र त्यसपछि त्यो उत्पन्न गर्न सक्ने एक वा दुई फिल्ड हेर्नु हो।

पाँच काम, महत्त्वको क्रममा

यातायात एन्डपोइन्ट भनेको IKE आदानप्रदान हुने ठाउँ हो। प्रमाणित पहिचान भनेको प्रत्येक पक्षले प्रमाणित गर्ने नाम, र त्यो राउटिङ तालिकाभन्दा नीतिसँग जाँचिन्छ। सुरक्षित सबनेटहरू ती चयनकर्ता हुन् जसले कुन आन्तरिक ट्राफिक सुरुङमा पर्छ भनी निर्धारण गर्छन्। त्यसपछि गेटवे आफैंले कुराकानी सुरु गर्दा प्रयोग हुने स्रोत, र अन्तमा साथीसम्म पुग्न तल्लो तहको अर्को हप।

left र right जस्ता सहभागी लेबल जडानका दुई पक्षका लागि परम्परा हुन्, स्थानीय र टाढाका समानार्थी होइनन्। कुनै कुञ्जीले अर्को उत्पादनले त्यसबाट बुझेको अर्थ नै बुझाउँछ भनी मान्नुअघि वास्तवमै स्थापित कार्यान्वयनको निर्देशिका पढ्नुहोस्।

पहिलो निर्णय: केही पनि स्थापित हुँदैन

जब लगमा कुनै पनि आदानप्रदान देखिँदैन, एन्डपोइन्ट पहिलो शंकास्पद हो: गलत ठेगाना, छानिएको मार्ग, वा डेमन नसुन्ने इन्टरफेस। हात मिलाउने देखिएपछि मात्र पहिचानका फिल्डतर्फ जानुहोस्, किनभने पहिचान आदानप्रदानभित्रै मूल्याङ्कन गरिन्छ, त्यसअघि होइन। छानिएको मार्ग र गलत ठेगाना क्लाइन्टबाट एउटै देखिन्छन्, त्यसैले केही सम्पादन गर्नुअघि सुन्ने पक्ष जाँच्नुहोस्। डेमन तपाईंले अपेक्षा गरेको इन्टरफेसमा बाँधिएको छ भनी पुष्टि गर्नुहोस्, किनभने एउटै ठेगानामा सुन्ने सेवा अवरुद्ध मार्गजस्तै देखिन्छ।

अनुवादमार्फत देखिएको सार्वजनिक ठेगाना साथीले प्रमाणित गर्ने पहिचानसँग एउटै कुरा होइन। टाढाको छेउमा प्याकेट क्याप्चरले देखाउनेसँग मिलाउन ठेगाना बदल्नु सामान्य र गलत सुधार हो।

दोस्रो निर्णय: सुरुङ माथि छ र ट्राफिक मर्छ

चयनकर्ताले सुरुङमा के जान्छ भनी निर्धारण गर्छन्, र यहाँको असमझदारीले सफलतापूर्वक वार्ता गर्ने तर अनुप्रयोग अझै असफल हुने जडान उत्पन्न गर्छ। टाढाको पक्षले तपाईंको सुरक्षित दायरालाई आफ्नो टाढाको दायरा भनी नाम दिनुपर्छ, र त्यहीँ उल्टा मानहरू छिर्छन्।

सम्पादन गर्नुअघि दुवै कन्फिगरेसन छेउछाउ पढ्नुहोस्। एउटा होस्टको स्थानीय दायरा अर्कोको टाढाको दायरा हो, र एउटै अदलबदल भएको जोडीले केही नबोक्ने सुरुङको व्याख्या गर्छ। कुञ्जीलाई छुनुअघि जोडी साँघुरो बनाउनुहोस्: सुरुङभित्र एउटा सबनेट र बाहिर एउटा, दोष चयनकर्ताको हो कि राउटिङको भनी बताउँछ।

तेस्रो निर्णय: गेटवेको आफ्नै ट्राफिक मात्र असफल हुन्छ

क्लाइन्टका लागि अगाडि पठाइएको ट्राफिक उत्तम रूपमा काम गर्न सक्छ, तर गेटवे आफैंले सुरु गरेको अनुरोध असफल हुन्छ, किनभने त्यो प्रवाहसँग उत्तराधिकार लिने क्लाइन्ट स्रोत छैन। प्राथमिकता स्रोतको सेटिङ यही अवस्थाका लागि छ, र त्यो स्रोत अनुवाद होइन: त्यसले स्रोत ठेगाना छान्छ, पुनःलेखन गर्दैन।

अर्को ठेगाना स्पष्ट रूपमा बाँध्ने अनुप्रयोगले प्राथमिकतालाई जित्न सक्छ, त्यसैले सेटिङ बेवास्ता गरिएको छ भनी निष्कर्ष निकाल्नुअघि प्याकेटको वास्तविक स्रोत पुष्टि गर्नुहोस्। कन्फिगरेसनको मनसायमा भर पर्नुको सट्टा गेटवेको आफ्नै इन्टरफेसमा क्याप्चर गर्नुहोस्।

अर्को हप स्थानीय निर्देश हो

तल्लो तहको अर्को हपले यो होस्टलाई साथीसम्म कसरी पुग्ने भनी बताउँछ, र टाढाको पक्षलाई त्यही मान चाहिँदैन। यसलाई साझा सेटिङ मान्नु, वा पूर्वनिर्धारित गेटवे हार्डकोड गर्नु, मार्ग बदलिने वा दोस्रो बाटो देखिने क्षणमा टुट्छ।

केही कार्यान्वयनले यहाँ विशेष मान दिन्छन्। स्थापित संस्करणका लागि निर्देशिकाले सूचीबद्ध गरेको कुरा नै एकमात्र सुरक्षित जवाफ हो, र स्थानीय राउटिङ तालिका त्यो काम गरेको प्रमाण हो। जब साथीसम्म नामले पुगिन्छ तर ठेगानाले पुगिँदैन, त्यो असमझदारी नै खोज हो, छल्नुपर्ने विवरण होइन।

प्रोफाइल दुवै छेउबाट पढ्नुहोस्

कागजमा भूमिका उल्टाउनु उपलब्ध सबैभन्दा छिटो समीक्षा हो: सुरक्षित दायरा बदल्नुहोस्, प्रत्येक पक्षको आफ्नै अर्को हप र प्रत्येक पक्षको आफ्नै पहिचान राख्नुहोस्। अदलबदलमा नटिक्ने कुरा सम्भवतः गलत काममा तोकिएको छ।

त्यसपछि प्रत्येक भूमिकाका लागि एउटा प्रवाह परीक्षण गर्नुहोस्: साथीहरूबीचको पहुँच, आन्तरिक क्लाइन्ट प्रवाह र गेटवेबाट उत्पन्न अनुरोध। तीन परीक्षणले कन्फिगरेसन फेरि नखोली कुन काम गलत तोकिएको छ भनी बताउँछन्। नतिजा तपाईंले बदलेको फिल्डको छेउमा टिकटमा थप्नुहोस्, किनभने अर्को इन्जिनियरले त्यही प्रोफाइल भेट्नेछ।