IPsec प्रोफाइलमधील पाच पत्ता भूमिका, आणि कोणती चुकीची आहे

ठराविक कनेक्शन व्याख्येमध्ये पाच वेगवेगळ्या कामांना पत्ता मिळतो, आणि त्यांनी एकमेकांशी जुळणे आवश्यक नाही. प्रशासक अडकतात कारण सर्व फील्ड एकाच होस्टकडे वळवण्याची समजूतदार प्रवृत्ती त्यापैकी किमान तीनसाठी चुकीची आहे. मार्ग म्हणजे आधी लक्षणाला नाव देणे आणि नंतर ते निर्माण करू शकणारी एक किंवा दोन फील्ड पाहणे.

पाच कामे, महत्त्वाच्या क्रमाने

वाहतूक एंडपॉइंट म्हणजे IKE देवघेव पोहोचवली जाते ते ठिकाण. प्रमाणित ओळख म्हणजे प्रत्येक बाजू सिद्ध करणारे नाव, आणि ती राउटिंग तक्त्याऐवजी धोरणाशी तपासली जाते. संरक्षित सबनेट हे निवडक आहेत जे ठरवतात की कोणता आंतरिक रहदारी बोगद्यात येतो. नंतर गेटवे स्वतः संवाद सुरू करतो तेव्हा वापरला जाणारा स्रोत, आणि शेवटी सहकाऱ्यापर्यंत पोहोचण्यासाठी अंडरलेचा पुढील हॉप.

left आणि right सारखी सहभागी लेबल कनेक्शनच्या दोन बाजूंसाठी परंपरा आहेत, स्थानिक आणि दूरचे समानार्थी नाहीत. एखादी की दुसऱ्या उत्पादनाने तिच्याकडून जे अर्थ ठेवले तेच सूचित करते असे गृहीत धरण्यापूर्वी प्रत्यक्षात स्थापित अंमलबजावणीचे पुस्तिका वाचा.

पहिला निर्णय: काहीही प्रस्थापित होत नाही

जेव्हा लॉगमध्ये अजिबात देवघेव दिसत नाही, तेव्हा एंडपॉइंट हा पहिला संशयित असतो: चुकीचा पत्ता, गाळलेला मार्ग, किंवा डीमन ज्या इंटरफेसवर ऐकत नाही तो इंटरफेस. हातमिळवणी दिसल्यानंतरच ओळखीच्या फील्डकडे जा, कारण ओळख देवघेवीच्या आत ठरवली जाते, त्यापूर्वी नाही. गाळलेला मार्ग आणि चुकीचा पत्ता क्लायंटकडून सारखेच दिसतात, म्हणून काहीही संपादित करण्यापूर्वी ऐकणारी बाजू तपासा. डीमन अपेक्षित इंटरफेसला बांधलेले असल्याची खात्री करा, कारण एका पत्त्यावर ऐकणारी सेवा अडवलेल्या मार्गासारखीच दिसते.

भाषांतरातून दिसणारा सार्वजनिक पत्ता सहकाऱ्याने सिद्ध करणाऱ्या ओळखीसारखा नसतो. दूरच्या टोकावर पॅकेट कॅप्चर जे दाखवते त्याला जुळवण्यासाठी पत्ता बदलणे ही सामान्य आणि चुकीची दुरुस्ती आहे.

दुसरा निर्णय: बोगदा वर आहे आणि रहदारी मरते

निवडक ठरवतात बोगद्यात काय जाते, आणि इथली विसंगती अशी जोडणी निर्माण करते जी यशस्वीपणे बोलणी करते पण अनुप्रयोग अजूनही अपयशी ठरतो. दूरच्या बाजूने तुमची संरक्षित श्रेणी आपली दूरची श्रेणी म्हणून नाव दिले पाहिजे, आणि तिथेच उलटी मूल्ये घुसतात.

संपादनापूर्वी दोन्ही संरचना शेजारी शेजारी वाचा. एका होस्टवरील स्थानिक श्रेणी दुसऱ्यावरील दूरची श्रेणी असते, आणि एकच अदलाबदल झालेली जोडी काहीही न वाहणाऱ्या बोगद्याचे स्पष्टीकरण देते. कींना हात लावण्यापूर्वी जोडी अरुंद करा: बोगद्याच्या आत एक सबनेट आणि बाहेर एक, दोष निवडकाचा आहे की राउटिंगचा हे सांगतात.

तिसरा निर्णय: फक्त गेटवेची स्वतःची रहदारी अपयशी ठरते

क्लायंटसाठी पुढे पाठवलेली रहदारी उत्तम काम करू शकते, पण गेटवे स्वतः सुरू करणारी विनंती अपयशी ठरते, कारण त्या प्रवाहाला वारसा घ्यायला क्लायंट स्रोत नसतो. पसंतीच्या स्रोताची सेटिंग याच प्रसंगासाठी आहे, आणि ती स्रोत भाषांतर नाही: ती स्रोत पत्ता निवडते, पुन्हा लिहीत नाही.

दुसरा पत्ता स्पष्टपणे बांधणारा अनुप्रयोग पसंतीला मागे टाकू शकतो, म्हणून सेटिंग दुर्लक्षित आहे असा निष्कर्ष काढण्यापूर्वी पॅकेटचा प्रत्यक्ष स्रोत तपासा. संरचनेच्या हेतूवर विश्वास ठेवण्याऐवजी गेटवेच्या स्वतःच्या इंटरफेसवर कॅप्चर करा.

पुढील हॉप ही स्थानिक सूचना आहे

अंडरलेचा पुढील हॉप या होस्टला सहकाऱ्यापर्यंत कसे पोहोचायचे ते सांगतो, आणि दूरच्या बाजूला तेच मूल्य लागत नाही. त्याला सामायिक सेटिंग म्हणून वागवणे, किंवा डीफॉल्ट गेटवे हार्डकोड करणे, मार्ग बदलतो किंवा दुसरा मार्ग दिसतो त्या क्षणी तुटते.

काही अंमलबजावणी इथे विशेष मूल्ये देतात. स्थापित आवृत्तीसाठी पुस्तिका जे सूचीबद्ध करते तेच एकमेव सुरक्षित उत्तर, आणि स्थानिक राउटिंग तक्ता ते काम केल्याचा पुरावा आहे. जेव्हा सहकाऱ्यापर्यंत नावाने पोहोचता येते पण पत्त्याने नाही, तेव्हा ती विसंगतीच शोध आहे, टाळायची तपशील नाही.

प्रोफाइल दोन्ही टोकांकडून वाचा

कागदावर भूमिका उलटणे हे उपलब्ध सर्वात वेगवान पुनरावलोकन आहे: संरक्षित श्रेण्या बदला, प्रत्येक बाजूचा स्वतःचा पुढील हॉप आणि प्रत्येक बाजूची स्वतःची ओळख ठेवा. अदलाबदलीत टिकत नाही ते बहुधा चुकीच्या कामाला दिलेले असते.

नंतर प्रत्येक भूमिकेसाठी एक प्रवाह तपासा: सहकाऱ्यांमधील पोहोच, आंतरिक क्लायंट प्रवाह आणि गेटवेकडून उद्भवणारी विनंती. तीन चाचण्या संरचना पुन्हा न उघडता कोणते काम चुकीचे दिले आहे ते सांगतात. निकाल तुम्ही बदललेल्या फील्डच्या शेजारी तिकिटात जोडा, कारण पुढील अभियंत्याला तोच प्रोफाइल भेटेल.