GDOI: किन कुञ्जी सर्भर तपाईंको डेटा मार्गमा छैन

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

दुई प्रकारका सुरक्षा अवस्था

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

मानकले कुञ्जी अद्यावधिक सन्देशहरू सुरक्षित गर्ने कुञ्जी नवीकरण सुरक्षा सम्बन्धको पनि नाम दिन्छ, जो सदस्यहरूले ट्राफिक कसरी सुरक्षित गर्छन् भनी वर्णन गर्ने डेटा सुरक्षा सम्बन्धहरूभन्दा छुट्टै छ।

रेखाचित्र होइन, आदानप्रदान अनुसरण गर्नुहोस्

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

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

राख्न योग्य तीन अभिलेख

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

यी कसैको सम्झनामा होइन, कन्फिगरेसनको छेउमा राख्नुहोस्। सदस्यता परिवर्तन पर्याप्त दुर्लभ छन् कि आवश्यक पर्दासम्म तर्क सधैं हराइसकेको हुन्छ।

इन्टरफेस, सेवा जडान, प्रशोधन मार्ग

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

सेवा जडानले ट्राफिक कसरी प्राप्त गर्छ भन्नेबारे प्लेटफर्मको आफ्नै कागजात पढ्नुहोस्। प्रोटोकल मानक भए पनि कार्यविधि विक्रेता-विशिष्ट हुन्छ।

मानकीकृत प्रोटोकल सन्देशहरूले पनि विक्रेताहरूबीच अनुकूलता स्थापित गर्दैनन्। दुई कार्यान्वयनले सँगै काम गर्ने अनुमान गर्नुअघि आवश्यक विशेषताहरू, नीति र सम्बन्धका गुणहरू, प्रमाणीकरण विधि र ठ्याक्कै प्लेटफर्म तथा संस्करण तुलना गर्नुहोस्।

नियन्त्रण उपलब्धता र डेटा फर्वार्डिङ छुट्टाछुट्टै जाँच हुन्

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

त्यसपछि नियन्त्रक बाहिर राखेर फर्वार्डिङ छुट्टै परीक्षण गर्नुहोस्। दुई जाँच, दुई नतिजा, र कुन आधा भाग बिग्रिएको छ भन्नेबारे धेरै छोटो बहस।