GDOI: की सर्व्हर तुमच्या डेटा मार्गावर का नाही

गट की सर्व्हर सदस्यांना धोरण आणि की वितरित करतो, आणि सदस्य स्वतः रहदारी संरक्षित करतात. हे वाक्य औपचारिकता वाटते, जोपर्यंत एखादी रचना नियंत्रकाला प्रत्येक संरक्षित पॅकेटसाठी रिले मानू लागते; तेव्हा टोपोलॉजीला कधीही नको असलेला हॉप मिळतो आणि रहदारीचा मार्ग केवळ स्थिती वाटण्यासाठी असलेल्या उपकरणावर अवलंबून राहतो. की सर्व्हर कुठे आहे आणि डेटा कुठे वाहतो हे सांगणे दोन वेगवेगळे आकृती आहेत, आणि GDOI त्याच फरकाभोवती बांधलेला आहे. हे उलटे समजणे छोटी मॉडेलिंग चूक नाही, कारण त्यामुळे तुम्ही कशावर लक्ष ठेवता आणि काय स्केल करता हे बदलते. खालील विभाग प्रोटोकॉलच्या स्वतःच्या विभाजनाचे अनुसरण करतात.

दोन प्रकारची सुरक्षा स्थिती

RFC 6407 सदस्याच्या धोरण आणि की सामग्री मागण्यासाठीच्या ओढ विनिमयाची आणि अधिकृत सदस्यांना धोरण व की अद्ययावत वितरित करणाऱ्या ढकल विनिमयाची व्याख्या करतो. दोन्ही सुरक्षा सहयोग व्यवस्थापित करतात. यापैकी कोणतेही अनुप्रयोगाचा डेटा प्रवाह नाही, म्हणून यशस्वी विनिमय केवळ नियंत्रण चॅनेलने काम केले हे सिद्ध करतो. सदस्य स्वच्छ नोंदणी करू शकतो, वैध की ठेवू शकतो आणि तरीही त्याचे डेटा धोरण चुकीचे असल्यास रहदारी संरक्षित किंवा अग्रेषित करू शकत नाही. कोणता विनिमय कोणते वाहतो हे कळल्यावर या दोन अयशस्वीता पूर्णपणे वेगळ्या दिसतात.

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

आकृती नाही, विनिमयांचे अनुसरण करा

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

म्हणूनच भौतिक सान्निध्यानुसार काढलेली इंटरफेस आकृती येथे दिशाभूल करते. नियंत्रकाचा इंटरफेस नियंत्रण स्रोत आहे, प्रत्येक एन्क्रिप्टेड पॅकेटसाठी आपोआप पुढील हॉप नाही.

ठेवण्यासारखे तीन नोंदी

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

हे कोणाच्याही स्मरणात नाही, संरचनेजवळ ठेवा. सदस्यत्व बदल पुरेसे दुर्मिळ आहेत की गरज पडेपर्यंत तर्क नेहमीच नाहीसा झालेला असतो.

इंटरफेस, सेवा जोडणी, प्रक्रिया मार्ग

सेवा-आधारित गेटवेवर आणखी एक फरक आहे: भौतिक अंडरले पत्ता स्थानिक सेवा जोडणीइतका तोच नसतो, आणि रहदारी तिच्या IPsec प्रक्रिया मार्गापर्यंत कशी पोहोचते हे प्लॅटफॉर्मची अंमलबजावणी ठरवते. त्रुटी संदेशाने सेवा-इंटरफेस नियमाचा उल्लेख केला म्हणून सेवा भौतिक इंटरफेसवर हलवणे किंवा असंबंधित भाषांतर जोडणे म्हणजे दुरुस्तीच्या वेशातील एक अंदाज.

सेवा जोडणी रहदारी कशी स्वीकारते याबद्दल प्लॅटफॉर्मचे स्वतःचे दस्तऐवज वाचा. प्रोटोकॉल मानक असला तरी यंत्रणा विक्रेता-विशिष्ट असते.

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

नियंत्रण उपलब्धता आणि डेटा अग्रेषण स्वतंत्र तपासण्या आहेत

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

मग नियंत्रक बाजूला ठेवून अग्रेषण स्वतंत्रपणे तपासा. दोन तपासण्या, दोन निकाल, आणि कोणता अर्धा भाग बिघडला आहे याबद्दल खूपच छोटी चर्चा.