VPN સર્વર રૂપરેખાંકનને સુરક્ષિત રીતે કેવી રીતે રોલબેક કરવું
રોલબેક જાણીતી સારી નેટવર્ક નીતિ પુનઃસ્થાપિત કરે છે, તમને મળતી સૌથી જૂની ફાઇલ નહીં। રદ્દીકરણોને અદ્યતન રાખો અને ટ્યુનલની બહાર વ્યવસ્થાપન માર્ગ રાખો।
સર્વરને રોલબેક કરવું એ કયો સ્તર નિષ્ફળ ગયો તેનો નિર્ણય છે, ફાઇલોની નકલ કરવાની કવાયત નહીં। રૂપરેખાંકન, ઓળખપત્રો અને પેકેજ આવૃત્તિઓ અલગ ઘડિયાળો પર ચાલે છે, અને એકને પુનઃસ્થાપિત કરતી વખતે બાકીની અદ્યતન રહે તો એવો યજમાન બને છે જે સ્વસ્થ દેખાય છે અને અસંગત રીતે વર્તે છે। નીચેનો ક્રમ ધારે છે કે પરિવર્તન પહેલેથી જ ખોટું ગયું છે અને તમને સૌથી નાની સુસંગત સ્થિતિ પુનઃસ્થાપિત કરવાનું કહે છે। તેને ક્રમમાં પૂર્ણ કરો અને આઉટ-ઓફ-બેન્ડ ઍક્સેસ તપાસને એ પગલું ગણો જે કોઈએ ટાળવું ન જોઈએ।
એવો ચેકપોઇન્ટ બનાવો જે તમે ખરેખર પુનઃસ્થાપિત કરી શકો
સેવા શરૂ થતી વખતે જે રૂપરેખાંકન વાંચે છે તે નોંધો, સાથે જે આવૃત્તિએ તેને છેલ્લે પાર્સ કર્યું હતું। જૂની આવૃત્તિ હેઠળ સ્વચ્છ રીતે લોડ થયેલી ફાઇલ અપગ્રેડ પછી નકારાઈ અથવા ચૂપચાપ અવગણાઈ શકે છે, તેથી આવૃત્તિ એ જ નોંધમાં આવે છે। રૂપરેખાંકન જે સામગ્રી તરફ ઇશારો કરે છે તે સામેલ કરો: ખાનગી કી, પ્રમાણપત્ર માર્ગો, શ્રોતા વ્યાખ્યાઓ અને DNS તથા ફાયરવોલ એન્ટ્રીઓ જે સેવાને પહોંચી શકાય તેવી બનાવે છે। જો પુનઃસ્થાપનને એવી ફાઇલની જરૂર પડે જે તમે સાચવી નથી, તો ચેકપોઇન્ટ અપૂર્ણ છે।
સિસ્ટમ હજી સ્વસ્થ હોય ત્યારે દરેક સેટિંગના માલિકનું નામ આપો। પ્રદાતા પેનલ દ્વારા સ્થાપિત માર્ગ, યજમાન ફાયરવોલ દ્વારા ઉમેરાયેલો માર્ગ અને ક્લાયન્ટોને મોકલાયેલો માર્ગ ત્રણ અલગ વસ્તુઓ છે, અને ખોટાને પુનઃસ્થાપિત કરવાથી બાકીના બે યથાસ્થાને રહે છે। સેટિંગ, માલિક અને ફાઇલ માર્ગનું ટૂંકું કોષ્ટક પૂરતું છે।
રદ્દીકરણોને રૂપરેખાંકનથી અલગ રાખો
જૂનું રૂપરેખાંકન તમે જાણી જોઈને દૂર કરેલા ઉપકરણને ચૂપચાપ ફરી જોડી શકે છે, જે પુનઃપ્રાપ્તિને સુરક્ષા પતનમાં ફેરવે છે। નેટવર્ક નીતિ પુનઃસ્થાપિત કરતી વખતે વર્તમાન રદ્દીકરણ યાદી અને નિષ્ક્રિય ખાતાં જાળવી રાખો, પછી સેવા ક્લાયન્ટ સ્વીકારે તે પહેલાં તેમને ફરી લાગુ કરો।
ઓળખની સ્થિતિને તેના પોતાના પુરાવા સાથે અલગ રોલબેક તરીકે ગણો। પ્રમાણપત્ર રદ્દીકરણ ફાઇલો, ખાતાનું નિષ્ક્રિયકરણ અને MFA નોંધણી ભાગ્યે જ ડીમન રૂપરેખાંકનની જ જગ્યાએ હોય છે, અને રૂપરેખાંકન પુનઃસ્થાપન તેમને સ્પર્શતું નથી। પહેલાં વર્તમાન સ્થિતિ તપાસો જેથી ખબર પડે કઈ વસ્તુ ટકી રહેવી જોઈએ। પુનઃસ્થાપન પછી ખાતરી કરો કે દૂર કરેલી ઓળખ હજી પણ જોડાઈ શકતી નથી।
ટ્યુનલ નિષ્ફળ જાય ત્યારે યજમાન સુધી પહોંચો
મશીન સુધી એવો માર્ગ ખોલો જે બદલાતા ઘટક પર આધારિત ન હોય। હાઇપરવાઇઝર કન્સોલ, અલગ ઇન્ટરફેસ પરનું વ્યવસ્થાપન સરનામું અથવા સિરિયલ કન્સોલ બધા યોગ્ય છે; ટ્યુનલમાંથી વહેતું SSH સત્ર નહીં। જો પ્રવેશનો એકમાત્ર રસ્તો એ VPN હોય જે તમે ફરી શરૂ કરવા જઈ રહ્યા છો, તો ખોટો માર્ગ કે ફાયરવોલ નિયમ તમારી સુધારવાની ક્ષમતા છીનવી લે છે। વૈકલ્પિક માર્ગ પરિવર્તન પહેલાં ચકાસો, પછી નહીં। તેના દ્વારા એક વાર લોગિન કરો, sudo કામ કરે છે તેની ખાતરી કરો અને તમે વાપરેલું ચોક્કસ સરનામું નોંધો।
કસોટી સરળ છે: વૈકલ્પિક માર્ગ પરથી જોડાયેલા હોવ ત્યારે ટ્યુનલ નીચે ઉતારો અને જુઓ સત્ર ટકે છે કે નહીં। જો તે તૂટે, તો તમણે નિષ્ફળતા એ પહેલાં શોધી કાઢી છે કે તે તમને ફસાવી શકે।
એક સુધારો લાગુ કરો અને જાણો તે ક્યારે અમલમાં આવે છે
સેવાના reload અથવા restart દસ્તાવેજીકરણનો ઉપયોગ કરો અને જાણો કયા નિર્દેશો કઈ ક્ષણે વંચાય છે। કેટલાક મૂલ્યો reload પર લાગુ થાય છે, અન્ય ફક્ત ત્યારે જ જ્યારે નવું સત્ર કે પ્રક્રિયા શરૂ થાય, તેથી ફાઇલનું સંપાદન ચાલુ સ્થિતિ વિશે કંઈ સાબિત કરતું નથી। નવી ફાઇલને જૂની રનટાઇમ સ્થિતિ સાથે ભેળવવાને બદલે એક જ સુધારો પુનઃસ્થાપિત કરો। શંકા હોય તો સેવાનું સંપૂર્ણ પુનઃપ્રારંભ આંશિક reload કરતાં વધુ સહેલાઈથી સમજી શકાય છે।
પસંદ કરતા પહેલાં યુનિટ વ્યાખ્યા તપાસો: systemctl show -p ExecReload openvpn@server તમને કહે છે કે reload હૂક બિલકુલ છે કે નહીં। પછી સુધારો લાગુ કરો અને બીજું કંઈપણ બદલતા પહેલાં જર્નલમાં પ્રથમ નવી ભૂલો વાંચો।
ચકાસો, નોંધો અને પછી તપાસ કરો
એક અધિકૃત ક્લાયન્ટ જોડો અને સેવા શેના માટે છે તે ચલાવો: નામ ઉકેલ, પુનઃજોડાણ અને જે એપ્લિકેશન નિષ્ફળ ગઈ। ખાતરી કરો કે રદ કરેલી ઓળખ હજી પણ નકારાય છે। તમે પુનઃસ્થાપિત કરેલો સુધારો, સમય અને કારણ નોંધો, કારણ કે આગલા ઓપરેટરને ત્રણેયની જરૂર પડશે। જે રોલબેક કોઈએ દસ્તાવેજ ન કર્યો તે આગલી વાર સેવા ખરાબ વર્તે ત્યારે રહસ્ય બની જાય છે।
systemctl status openvpn@server --no-pager
journalctl -u openvpn@server -n 50 --no-pager
સેવા સ્થિર થાય પછી, નિષ્ફળ પરિવર્તનને એવા યજમાન કે સ્નેપશોટ પર પુનઃઉત્પાદિત કરો જે તમે ફેંકી શકો। તે ખરાબ રૂપરેખાંકનને ખરાબ પેકેજ કે સમાપ્ત પ્રમાણપત્રથી અલગ પાડે છે। પુનઃસ્થાપિત રૂપરેખાંકનને આવૃત્તિ નિયંત્રણ હેઠળ રાખો જેથી આગલો ચેકપોઇન્ટ જાણીતા કમિટથી શરૂ થાય। કવાયતનો હેતુ દસ્તાવેજીકૃત અંતિમ બિંદુ છે, કાયમી ડાઉનગ્રેડ નહીં।