બે IPsec ગેટવે, કોઈ સામાન્ય IP નહીં: ફેલઓવર ખરેખર શું કરે છે

મીટિંગ દરમિયાન ગેટવે A બંધ કરો અને એક મિનિટ પછી ટનલ B દ્વારા પાછી આવતી જુઓ; જોડાણ કામ કરે છે, વિડિયો કૉલ કદાચ નહીં. સ્વતંત્ર સરનામાં ધરાવતા બે IPsec ગેટવે વચ્ચેની કોલ્ડ ફેલઓવરનું આ પ્રામાણિક સ્વરૂપ છે. ક્લાયન્ટ એક એન્ડપોઇન્ટ ફરી પસંદ કરે છે અને નવો સંબંધ બનાવે છે, જે જૂની સેશનની ક્રિપ્ટોગ્રાફિક સ્થિતિ ટ્રાન્સફર કર્યા વિના પહોંચ પુનઃસ્થાપિત કરે છે. ક્રમને અનુસરવાથી સ્પષ્ટ થાય છે કે ડિઝાઇન કયા વચનો પાળી શકે છે.

દૃશ્ય ગોઠવો: બે સરનામાં, કોઈ ફ્લોટિંગ IP નહીં

ગેટવે A એક પહોંચી શકાય તેવા સરનામે જવાબ આપે છે અને ગેટવે B બીજા પર. A ગયા પછી B પસંદ કરવાની મંજૂર રીત ક્લાયન્ટ પાસે છે, અને બંને ગેટવે દાવો કરે તેવું કોઈ સામાન્ય બાહ્ય સરનામું નથી. આ ડિઝાઇનમાં, વર્ચ્યુઅલ IP એ સામાન્ય પ્રવેશ બિંદુ દર્શાવે છે, રિમોટ-એક્સેસ ક્લાયન્ટને આપેલું આંતરિક સરનામું નહીં.

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

નિષ્ફળતામાંથી પસાર થાઓ: શોધો, પછી ફરી પસંદ કરો

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

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

B શું વારસામાં લઈ શકે અને શું નહીં

B એ A સાથે રૂપરેખાંકન ટેમ્પલેટ, પ્રમાણપત્ર સત્તાધિકારી અને પ્રમાણીકરણ નીતિ વહેંચી શકે છે. તે જીવંત સુરક્ષા સંગઠનો વારસામાં લઈ શકતું નથી. સેશન કી, સુરક્ષા પરિમાણ સૂચકાંકો અને ક્રમ સ્થિતિ A અને ક્લાયન્ટે બનાવેલા સંબંધની છે, અને B પાસે તેમાંથી એક પણ નથી.

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

નવો સંબંધ સ્થાપિત કરવો

B પસંદ થયા પછી ક્લાયન્ટ નવી IKE આપલે કરે છે: નવા nonce મૂલ્યો, નવા Diffie-Hellman મૂલ્યો, પરિણામી સંગઠનો માટે નવા ઓળખકર્તા. B પર ફરી પ્રમાણીકરણ થાય છે. જો ડિઝાઇન મશીન ક્રેડેન્શિયલ પર આધાર રાખે, તો ફરી જોડાવું દેખરેખ વિનાનું હોઈ શકે; જો માનવ પરિબળ જરૂરી હોય, તો ફેલઓવર પૂર્ણ કરવા કોઈએ હાજર રહેવું પડે.

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

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

સમાંતરમાં બે ટનલ અલગ ડિઝાઇન છે

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

ઓવરલેપિંગ ટનલ નીતિઓ પોતાની રીતે વ્યવસ્થિત ફેલઓવર બનાવતી નથી. તેઓ બે ઉમેદવારો બનાવે છે, અને તેમની વચ્ચે કંઈક નિર્ણાયક રીતે નિર્ણય લેવો પડે છે, પછી તે રૂટિંગ મેટ્રિક હોય, નીતિ અગ્રતા હોય કે ક્લાયન્ટમાં સ્પષ્ટ પસંદગી હોય.

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