GDOI: कुंजी सर्वर आपके डेटा पथ पर क्यों नहीं है

समूह कुंजी सर्वर सदस्यों को नीति और कुंजियाँ वितरित करता है, और सदस्य स्वयं ट्रैफ़िक की सुरक्षा करते हैं। यह वाक्य औपचारिकता जैसा लगता है जब तक कोई डिज़ाइन नियंत्रक को हर संरक्षित पैकेट के लिए रिले न मान ले; तब टोपोलॉजी को वह हॉप मिल जाता है जिसकी उसे कभी आवश्यकता नहीं थी और ट्रैफ़िक पथ ऐसे उपकरण पर निर्भर हो जाता है जो केवल स्थिति बाँटने के लिए था। कुंजी सर्वर कहाँ बैठता है और डेटा कहाँ बहता है, यह कहना दो अलग आरेख हैं, और GDOI उसी अंतर के इर्द-गिर्द बना है। इसे उल्टा समझना छोटी मॉडलिंग त्रुटि नहीं है, क्योंकि इससे बदलता है कि आप किस पर नज़र रखते हैं और किसे स्केल करते हैं। नीचे के खंड प्रोटोकॉल के अपने विभाजन का पालन करते हैं।

सुरक्षा स्थिति के दो प्रकार

RFC 6407 सदस्य के पुल एक्सचेंज को परिभाषित करता है जो नीति और कुंजी सामग्री माँगने के लिए है, और एक पुश एक्सचेंज जो अधिकृत सदस्यों को नीति और कुंजी अपडेट वितरित करता है। दोनों सुरक्षा संबद्धताओं का प्रबंधन करते हैं। इनमें से कोई भी एप्लिकेशन का डेटा प्रवाह नहीं है, इसलिए सफल एक्सचेंज केवल यह सिद्ध करता है कि नियंत्रण चैनल काम कर गया। सदस्य स्वच्छ पंजीकरण कर सकता है, वैध कुंजियाँ रख सकता है और फिर भी ट्रैफ़िक की सुरक्षा या अग्रेषण नहीं कर पा सकता यदि उसकी डेटा नीति गलत है। कौन-सा एक्सचेंज किसे ले जाता है यह जानने के बाद ये दो विफलताएँ बिल्कुल अलग दिखती हैं।

मानक कुंजी-अपडेट संदेशों की सुरक्षा करने वाली एक नवीनीकरण सुरक्षा संबद्धता का भी नाम देता है, जो उन डेटा-सुरक्षा संबद्धताओं से अलग है जो बताती हैं कि सदस्य ट्रैफ़िक की सुरक्षा कैसे करते हैं।

एक्सचेंजों का पालन करें, आरेख का नहीं

देखें कि प्रत्येक संदेश किस लिए है। पंजीकरण नियंत्रक को बताता है कि कौन-सा सदस्य पूछ रहा है और स्थिति स्थापित करता है; नवीनीकरण सदस्यों को बताता है कि नीति या कुंजियाँ बदल गई हैं; फिर संरक्षित एप्लिकेशन ट्रैफ़िक स्थापित डेटा-सुरक्षा संबद्धता का उपयोग करके सदस्यों के बीच बहता है। नियंत्रक का पता पहले दो में दिखता है और तीसरे में बिल्कुल भी दिखने की आवश्यकता नहीं है।

इसीलिए भौतिक निकटता के आधार पर खींचा गया इंटरफ़ेस आरेख यहाँ भ्रामक है। नियंत्रक का इंटरफ़ेस एक नियंत्रण स्रोत है, हर एन्क्रिप्टेड पैकेट के लिए स्वतः अगला हॉप नहीं।

रखने योग्य तीन रिकॉर्ड

सदस्य का प्रमाणित पंजीकरण और वह नियंत्रण स्रोत जिस तक वह पहुँच सकता है, आगे के कुंजी-अपडेट पहुँचाने वाला पथ, तथा संरक्षित एप्लिकेशन ट्रैफ़िक ले जाने वाले मार्ग और संलग्नताएँ लिखें। तीन रिकॉर्ड, तीन स्वामी, और इनमें से किसी एक में विफलता अलग लक्षण देती है। जो सदस्य पंजीकरण करता है और फिर कभी अपडेट नहीं पाता, वह पुरानी नीति के साथ पंजीकृत सदस्य जैसा ही दिखता है, जब तक आपके पास दोनों रिकॉर्ड न हों।

इन्हें किसी की स्मृति में नहीं, कॉन्फ़िगरेशन के पास रखें। सदस्यता परिवर्तन इतने कम होते हैं कि जब आवश्यकता होती है तब तक तर्क हमेशा गायब हो चुका होता है।

इंटरफ़ेस, सेवा संलग्नता, प्रसंस्करण पथ

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

सेवा संलग्नता ट्रैफ़िक कैसे प्राप्त करती है, इसके लिए प्लेटफ़ॉर्म का अपना दस्तावेज़ पढ़ें। प्रोटोकॉल मानक होने पर भी तंत्र विक्रेता-विशिष्ट है।

मानकीकृत प्रोटोकॉल संदेश भी विक्रेताओं के बीच संगतता स्थापित नहीं करते। दो कार्यान्वयनों के साथ काम करने का अनुमान लगाने से पहले आवश्यक विशेषताओं, नीति और संबद्धता विशेषताओं, प्रमाणीकरण विधि तथा सटीक प्लेटफ़ॉर्म और संस्करण की तुलना करें।

नियंत्रण उपलब्धता और डेटा अग्रेषण अलग जाँचें हैं

सामान्य संचालन, सदस्यता परिवर्तन और कुंजी अपडेट के लिए नियंत्रक की पहुँच की योजना बनाएँ। पहले से स्थापित स्थिति पर सफल होने वाला एप्लिकेशन एक्सचेंज यह सिद्ध नहीं करता कि अगला पंजीकरण या नवीनीकरण सदस्य तक पहुँच सकता है, और यह अंतर आमतौर पर घंटों बाद ऐसी सुरंग के रूप में दिखता है जो नए सदस्य लेना बंद कर देती है। केवल चल रहा सत्र नहीं, नया पंजीकरण जाँचें।

फिर नियंत्रक को बाहर रखकर अग्रेषण अलग से जाँचें। दो जाँचें, दो परिणाम, और कौन-सा आधा टूटा है इस पर बहुत छोटी बहस।