એક VPN ખાતું, બે સર્વર: ત્રણ સ્ટેટ લેજર
શેર કરેલું પ્રવેશ, નોડ-સ્થાનિક નેટવર્ક રૂપરેખાંકન અને જીવંત સત્રો અલગ સમસ્યાઓ છે. એક ખાતું નોડ્સ વચ્ચે પ્રતિકૃતિ કરતાં પહેલાં તેમને અલગ રાખો.
એક ખાતું જે બે VPN નોડમાંથી કોઈપણ એકમાં સાઇન ઇન કરી શકે છે, તે સોફ્ટવેર પ્રશ્ન થવાના ઘણા સમય પહેલાં ડિઝાઇન પ્રશ્ન ઊભો કરે છે. ખાતાનું દૃશ્ય, દરેક નોડનું પોતાનું નેટવર્ક અને જોડાયેલા ક્લાયન્ટનું સત્ર, એ ત્રણ અલગ પ્રકારની સ્થિતિ છે, અને તેમને એક જગ્યાએથી બીજે કોપી કરો ત્યારે તેઓ જુદી જુદી રીતે નિષ્ફળ જાય છે. ત્રણેયને એક સિસ્ટમમાં કોપી કરવી એ તેમાંથી એક ગુમાવવાની સામાન્ય રીત છે.
નીચેનાં ત્રણ લેજર ક્રમમાં કાર્ય કરો. દરેક પૂછે છે કે શું સત્તાવાર છે, શું સ્થાનિક છે, અને બીજો નોડ ન હોય ત્યારે શું થાય છે, અને જવાબો એકબીજામાંથી આવતા નથી.
કોણ જોડાઈ શકે: એક સત્તા, ઘણા નોડ
પ્રવેશ લેજરથી શરૂ કરો: કયો ઓળખ સ્રોત સત્તાવાર છે, કયા પ્રમાણપત્ર ઇશ્યુઅરો પર ભરોસો છે, કયા ખાતાં પાત્ર છે, કયો બીજો પરિબળ લાગુ પડે છે, અને દરેક ખાતું ક્યાં સુધી પહોંચી શકે છે. પછી લખો કે દરેક નોડ ફેરફારો વિશે કેવી રીતે જાણે છે, અને કેટલી ઝડપથી.
શેર કરેલો ડેટાબેઝ તે જવાબનો એક શક્ય ઘટક છે. તે પુરાવો નથી કે દરેક સંબંધિત નીતિ ત્યાં જ રહે છે, અથવા દરેક નોડ એક જ ક્ષણે ફેરફાર લાગુ કરે છે. નોડ A પર નિષ્ક્રિય પણ નોડ B પર હજી સ્વીકૃત ખાતું એટલે ઓફબોર્ડિંગ પ્રક્રિયા પૂરી થઈ નથી.
સત્તા પહોંચમાં ન હોય ત્યારે નોડ શું કરશે તે નક્કી કરો. વિક્ષેપ દરમિયાન કેશ કરેલી ઓળખપત્રો સ્વીકારવી એ સુરક્ષા ખર્ચ સાથેની નીતિ પસંદગી છે, અને તેમને નકારવી એ ઉપલબ્ધતા ખર્ચ સાથેની નીતિ પસંદગી છે. બંને વાજબી છે; તેને દસ્તાવેજ વગર છોડવું નહીં.
ઇશ્યુઅરની સત્તા ખાતાના ડેટાથી અલગ રાખો. ઘણા ગેટવે તેની સહી કી રાખ્યા વગર એક જ CA પર ભરોસો કરી શકે છે, અને દરેક નોડને હજી પોતાનું સર્વર પ્રમાણપત્ર અને પોતાનો ક્લાયન્ટ-બાજુનો ભરોસો સંબંધ જોઈએ છે.
નોડ શું ધરાવે છે: સરનામાં અને માર્ગો
બીજું લેજર દરેક નોડ માટે સ્થાનિક છે: સાંભળવાનું સરનામું, સર્વર ઓળખ, સરનામા પૂલ, ખાનગી સ્રોતો તરફના માર્ગો, રિઝોલ્વર નીતિ, અને ટ્રાફિક ઇન્ટરનેટ તરફ કેવી રીતે નીકળે છે. એક જ ખાતું કોઈપણ નોડ પરથી સેવા આપી શકે છે જ્યારે આ વસ્તુઓ અલગ રહે છે.
પરત માર્ગ એ છે જે ભૂલાઈ જાય છે. જો બંને નોડ એક જ પૂલમાંથી સરનામાં આપે, તો ખાનગી નેટવર્ક કહી શકતું નથી કે આપેલો ક્લાયન્ટ કયા નોડનો છે, અને જવાબ ખોટી જગ્યાએ મોકલાઈ શકે છે. અલગ પૂલને પણ માર્ગો અને પરવાનગીઓ જોઈએ, તેથી અલગ સંખ્યા શ્રેણી સંપૂર્ણ ડિઝાઇન નથી.
ક્લાયન્ટને જાણી જોઈને એક નોડ તરફ દોરો. DNS પસંદગી, ક્લાયન્ટ એન્ડપોઇન્ટ યાદીઓ અને ફ્રન્ટ-એન્ડ સેવા જુદા જુદા મિકેનિઝમ છે જેમનું આરોગ્ય અને નિષ્ફળતા-સ્વિચિંગ વર્તન જુદું છે. એક પસંદ કરવું ઠીક છે; “લોડ બેલેન્સિંગ”ને ડિઝાઇન ગણવું પરત માર્ગ અને નિષ્ફળતાના વર્તનને અસ્પષ્ટ રાખે છે.
દસ્તાવેજીકૃત ઉત્પાદન ઉદાહરણ અહીં મદદ કરે છે. Pritunl નું પ્રતિકૃતિ દસ્તાવેજીકરણ VPN નેટવર્કને પ્રતિ-નકલ વસ્તુ તરીકે ગણે છે, અને અલગ નકલો પરના ક્લાયન્ટને એકબીજા સુધી પહોંચવા વધારાના માર્ગો અને જોડાણ જોઈએ છે. આ ઉત્પાદન-વિશિષ્ટ ગોઠવણ છે, Community OpenVPN માટે રેસીપી નથી, પણ તે દર્શાવે છે કે નકલ ઉમેરવાથી ફક્ત ખાતાનો સંગ્રહ નહીં, નેટવર્ક પણ બદલાય છે.
સત્ર શું છે: જીવંત સ્થિતિ, પંક્તિ નહીં
ત્રીજું લેજર જીવંત સત્ર છે. જોડાયેલા ક્લાયન્ટ પાસે જે નોડે તેને સ્વીકાર્યો તેના પર પ્રોટોકોલ સ્થિતિ અને નેટવર્ક ફાળવણી છે. બીજા નોડ પર ખાતું જાણીતું હોવાથી તે નોડને સત્ર, કીઓ કે પેકેટ ચાલુ રાખવાની ક્ષમતા મળતી નથી.
નોડ નિષ્ફળ જાય ત્યારે શું થાય તે સ્પષ્ટ કહો. સમર્થિત પરિણામ બીજા નોડ પર નવી પ્રમાણીકરણ અને નવા સરનામા સાથે ફરી જોડાણ હોઈ શકે છે, જે પછી એપ્લિકેશન પોતાની રીતે પુનઃપ્રાપ્ત થાય છે. જો અવિરત હેન્ડઓફ જરૂરી હોય, તો તે જરૂરિયાતને સ્પષ્ટ અમલીકરણ સમર્થન જોઈએ, ડેટાબેઝ પ્રતિકૃતિમાંથી અનુમાન નહીં. જવાબ ત્યાં લખો જ્યાં ઓન-કોલ એન્જિનિયર તેને શોધી શકે.
ક્ષમતાના નિયમોને પણ એ જ વર્તન જોઈએ. ખાતા દીઠ બે સાથેના સત્રોની મર્યાદા નોડ્સ વચ્ચે ફક્ત ત્યારે લાગુ થઈ શકે જ્યારે કોઈ સત્તાને ભરેલી જગ્યાઓની સંકલિત દૃષ્ટિ હોય. નોડ-સ્થાનિક યાદીઓ અને ઐતિહાસિક ખાતા રેકોર્ડ તે દૃષ્ટિ નથી બનાવતા.
ત્રણ લેજરની કસોટી
દરેકને અલગથી કસોટી કરો. નોડ A દ્વારા સાઇન ઇન કરો, પછી નોડ B દ્વારા, અને અપેક્ષિત સરનામા શ્રેણીઓ સાથે બંને સફળ થાય તેની ખાતરી કરો. એક ઓળખ પાછી ખેંચો અને બંને નોડ તપાસો, ફક્ત જે તમે આકસ્મિક રીતે પરીક્ષણ કર્યું તે નહીં. પછી એક નોડ બંધ કરો અને ક્લાયન્ટ અને ખાનગી એપ્લિકેશન ખરેખર શું કરે છે તે જુઓ.
સ્વીકૃતિ પરીક્ષણમાં પરત માર્ગ સામેલ કરો. જે ક્લાયન્ટ B સાથે જોડાય છે પણ A પાછળના સ્રોતમાંથી જવાબ મેળવી શકતો નથી, તેણે પ્રવેશ તપાસ પાસ કરી છે અને નેટવર્કની નિષ્ફળ કરી છે, અને તે ભેદ અહેવાલમાં આવવો જોઈએ.
મલ્ટી-નોડ ખાતાની ડિઝાઇન ત્યારે જ સંપૂર્ણ છે જ્યારે ત્રણેય લેજરમાં સ્પષ્ટ માલિક, ફેરફારનો માર્ગ અને નિષ્ફળતાનું વર્તન હોય. નોડ્સ વચ્ચે રૂપરેખાંકન ફાઇલ કોપી કરવી આ પ્રશ્નોમાંથી એકનો પણ જવાબ આપતી નથી.