GDOI: કી સર્વર તમારા ડેટા માર્ગ પર કેમ નથી

જૂથ કી સર્વર સભ્યોને નીતિ અને કીનું વિતરણ કરે છે, અને સભ્યો પોતે ટ્રાફિકનું રક્ષણ કરે છે. એ વાક્ય ઔપચારિકતા જેવું લાગે છે જ્યાં સુધી કોઈ ડિઝાઇન નિયંત્રકને દરેક સુરક્ષિત પેકેટ માટે રિલે તરીકે ગણવા લાગે; ત્યારે ટોપોલોજીને એ હોપ મળે છે જેની તેને કદી જરૂર ન હતી અને ટ્રાફિક માર્ગ એવા ઉપકરણ પર નિર્ભર બને છે જેને ફક્ત સ્થિતિ આપવાની હતી. કી સર્વર ક્યાં બેસે છે અને ડેટા ક્યાં વહે છે એ કહેવું બે અલગ રેખાચિત્રો છે, અને GDOI એ ફરકની આસપાસ જ બનેલું છે. તેને ઉલટું સમજવું નાની મોડેલિંગ ભૂલ નથી, કારણ કે તે બદલે છે કે તમે શું દેખરેખ રાખો છો અને શું સ્કેલ કરો છો. નીચેના વિભાગો પ્રોટોકોલના પોતાના વિભાજનને અનુસરે છે.

બે પ્રકારની સુરક્ષા સ્થિતિ

RFC 6407 સભ્યના પુલ વિનિમયને વ્યાખ્યાયિત કરે છે જે નીતિ અને કી સામગ્રી માંગવા માટે છે, અને પુશ વિનિમય જે અધિકૃત સભ્યોને નીતિ અને કી અપડેટનું વિતરણ કરે છે. બંને સુરક્ષા સંગઠનોનું સંચાલન કરે છે. બંમાંથી એક પણ એપ્લિકેશનનો ડેટા પ્રવાહ નથી, તેથી સફળ વિનિમય ફક્ત એ સાબિત કરે છે કે નિયંત્રણ ચેનલ કામ કરી. સભ્ય સ્વચ્છ રીતે નોંધણી કરી શકે, માન્ય કી રાખી શકે અને તેમ છતાં તેની ડેટા નીતિ ખોટી હોય તો ટ્રાફિકનું રક્ષણ કે ફોરવર્ડિંગ કરી શકે નહીં. કયો વિનિમય કયું વહન કરે છે તે જાણ્યા પછી આ બે નિષ્ફળતાઓ બિલકુલ અલગ દેખાય છે.

ધોરણ કી-અપડેટ સંદેશાઓનું રક્ષણ કરતું કી-નવીકરણ સુરક્ષા સંગઠન પણ નામ આપે છે, જે સભ્યો ટ્રાફિકનું કેવી રીતે રક્ષણ કરે છે તે વર્ણવતા ડેટા-સુરક્ષા સંગઠનોથી અલગ છે.

વિનિમયોને અનુસરો, રેખાચિત્રને નહીં

દરેક સંદેશ શેના માટે છે તે જુઓ. નોંધણી નિયંત્રકને કહે છે કે કયો સભ્ય પૂછે છે અને સ્થિતિ સ્થાપે છે; કી-નવીકરણ સભ્યોને કહે છે કે નીતિ કે કી બદલાઈ છે; પછી સુરક્ષિત એપ્લિકેશન ટ્રાફિક સ્થાપિત ડેટા-સુરક્ષા સંગઠનનો ઉપયોગ કરીને સભ્યો વચ્ચે વહે છે. નિયંત્રકનું સરનામું પ્રથમ બેમાં દેખાય છે અને ત્રીજામાં બિલકુલ દેખાવાની જરૂર નથી.

તેથી જ ભૌતિક સાન્નિધ્ય પ્રમાણે દોરેલું ઇન્ટરફેસ રેખાચિત્ર અહીં ભ્રામક છે. નિયંત્રકનું ઇન્ટરફેસ નિયંત્રણ સ્રોત છે, દરેક એન્ક્રિપ્ટેડ પેકેટ માટે આપોઆપ આગલું હોપ નથી.

રાખવા લાયક ત્રણ રેકોર્ડ

સભ્યની પ્રમાણિત નોંધણી અને તે જે નિયંત્રણ સ્રોત સુધી પહોંચી શકે છે, પછીના કી-અપડેટ પહોંચાડતો માર્ગ, અને સુરક્ષિત એપ્લિકેશન ટ્રાફિક વહન કરતા રૂટ અને જોડાણો લખો. ત્રણ રેકોર્ડ, ત્રણ માલિક, અને તેમાંથી કોઈપણમાં નિષ્ફળતા અલગ લક્ષણ આપે છે. જે સભ્ય નોંધણી કરે અને પછી કદી અપડેટ ન મળે તે જૂની નીતિ સાથે નોંધાયેલા સભ્ય જેવો જ દેખાય છે, સિવાય કે તમારી પાસે બંને રેકોર્ડ હોય.

આને કોઈની યાદમાં નહીં, રૂપરેખાંકનની બાજુમાં રાખો. સભ્યપદના ફેરફાર પૂરતા દુર્લભ છે કે જરૂર પડે ત્યાં સુધીમાં તર્ક હંમેશા ગાયબ થઈ ગયો હોય છે.

ઇન્ટરફેસ, સેવા જોડાણ, પ્રક્રિયા માર્ગ

સેવા-આધારિત ગેટવે પર વધુ એક ભેદ છે: ભૌતિક અંડરલે સરનામું સ્થાનિક સેવા જોડાણ જેવું જ નથી, અને પ્લેટફોર્મનું અમલીકરણ નક્કી કરે છે કે ટ્રાફિક તેના IPsec પ્રક્રિયા માર્ગ સુધી કેવી રીતે પહોંચે. સેવાને ભૌતિક ઇન્ટરફેસ પર ખસેડવી અથવા અસંબંધિત ભાષાંતર ઉમેરવું કારણ કે કોઈ ભૂલ સંદેશે સેવા-ઇન્ટરફેસ નિયમનો ઉલ્લેખ કર્યો, એ સુધારાના વેશમાં અનુમાન છે.

સેવા જોડાણ ટ્રાફિક કેવી રીતે મેળવે છે તે માટે પ્લેટફોર્મના પોતાના દસ્તાવેજીકરણ વાંચો. પ્રોટોકોલ ધોરણે હોવા છતાં ક્રિયાવિધિ વેન્ડર-વિશિષ્ટ છે.

ધોરણીકૃત પ્રોટોકોલ સંદેશો પણ વેન્ડર-આંતર સુસંગતતા સ્થાપિત કરતા નથી. બે અમલીકરણો સાથે કામ કરશે એમ ધારવા પહેલાં જરૂરી લક્ષણો, નીતિ અને સંગઠનના લક્ષણો, પ્રમાણીકરણ પદ્ધતિ અને ચોક્કસ પ્લેટફોર્મ તથા આવૃત્તિની સરખામણી કરો.

નિયંત્રણ ઉપલબ્ધતા અને ડેટા ફોરવર્ડિંગ અલગ તપાસ છે

સામાન્ય કામગીરી, સભ્યપદ ફેરફાર અને કી-અપડેટ માટે નિયંત્રકની પહોંચની યોજના કરો. પહેલેથી સ્થાપિત સ્થિતિ પર સફળ થતો એપ્લિકેશન વિનિમય સાબિત કરતો નથી કે આગલી નોંધણી કે નવીકરણ સભ્ય સુધી પહોંચી શકે છે, અને આ અંતર સામાન્ય રીતે કલાકો પછી એવી ટનલ તરીકે દેખાય છે જે નવા સભ્યો લેવાનું બંધ કરે છે. ફક્ત ચાલતું સત્ર નહીં, તાજી નોંધણી ચકાસો.

પછી નિયંત્રકને બહાર રાખીને ફોરવર્ડિંગ અલગથી ચકાસો. બે તપાસ, બે પરિણામ, અને કયો અડધો ભાગ બગડેલો છે તે અંગે ઘણી ટૂંકી ચર્ચા.