અનધ્યક્ષ VPN સર્વર અપડેટને ચકાસાયેલ પુનઃપ્રાપ્તિ માર્ગની જરૂર છે
અપડેટ તે જ સેવાને ફરી શરૂ કરી શકે છે જેનાથી તમે સર્વર સુધી પહોંચો છો. ઓટોમેશન પહેલાં આઉટ-ઓફ-બેન્ડ કન્સોલને ફક્ત ટનલ આધારિત પુનઃપ્રાપ્તિ યોજના સાથે સરખાવો.
અનધ્યક્ષ અપડેટ એ સર્વર માટે વાજબી નીતિ છે જે સુધી તમે તેના પોતાના VPN દ્વારા પહોંચો છો, અને તે જ સમયે તે તમે જાતે ઊભું કરેલું એક જ નિષ્ફળતાનું બિંદુ છે. પેકેજ ક્રિયા સેવાને ફરી શરૂ કરે છે, ટનલ તૂટી પડે છે, અને તમે વાપરી રહ્યા હતા તે વહીવટી માર્ગ તેની સાથે જ અદૃશ્ય થઈ જાય છે. પુનઃપ્રાપ્તિના બે મોડેલ છે, અને તેમની વચ્ચેની પસંદગી એક શરત પર આધાર રાખે છે: શું તમારી પાસે એવો પ્રવેશ માર્ગ છે જે અપડેટ થઈ રહેલી વસ્તુમાંથી પસાર થતો નથી.
બે પુનઃપ્રાપ્તિ મોડેલ, એક નિર્ણાયક શરત
પહેલું મોડેલ અપડેટ પર ભરોસો રાખે છે અને ધારે છે કે પછી તમે ફરી જોડાઈ શકશો. તે ત્યારે કામ કરે છે જ્યારે VPN હોસ્ટ સુધી પહોંચવાના ઘણા રસ્તાઓમાંનો એક હોય અને જ્યારે ટનલની નિષ્ફળતા તેને નિદાન કરવાની તમારી ક્ષમતા છીનવી ન લે. બીજું મોડેલ અગાઉથી એક સ્વતંત્ર માર્ગ મૂકે છે, સામાન્ય રીતે હોસ્ટિંગ પ્રદાતાનું કન્સોલ, અને ટનલને એ વસ્તુ તરીકે ગણે છે જેને જાળવણી સૌથી વધુ સંભવતઃ તોડશે. બંને મોડેલ સમર્થનીય છે, અને તેમાંથી ફક્ત એક જ અગાઉથી કામ માગે છે.
નિર્ણાયક શરત કહેવી સરળ છે અને ચૂકી જવી પણ સરળ છે. જો મશીન સુધીનો દરેક વહીવટી માર્ગ અપડેટ થઈ રહેલી સેવામાંથી પસાર થાય છે, તો તમારી પાસે કોઈ પુનઃપ્રાપ્તિ મોડેલ નથી, ફક્ત એક અપેક્ષા છે. પરિવર્તન સમીક્ષામાં તે મોટેથી કહો.
તે શરત ચકાસવામાં દસ મિનિટ લાગે છે અને તે પહેલા અનધ્યક્ષ અપડેટ પહેલાં થવું જોઈએ, ઘટનાના સમયે નહીં. જ્યારે બધું કામ કરતું હોય ત્યારે કન્સોલ ખોલો, ઓળખપત્રો વર્તમાન છે તેની ખાતરી કરો, અને ફરી બંધ કરો. ખાતરી કરો કે કન્સોલ તમે ધારો છો તે હોસ્ટ પર ખૂલે છે. પછી ખાતરી કરો કે રાત્રે 3 વાગ્યે તમે ખરેખર વાપરશો તે લોગિન હજી પણ કામ કરે છે.
તે છેલ્લો ભાગ સાંભળવામાં જેટલો લાગે તેનાથી વધુ મહત્ત્વનો છે. જે કન્સોલ ખાતાનો પાસવર્ડ છ મહિના પહેલાં બદલાયો અને ક્યારેય ચકાસાયો નહીં, તે પુનઃપ્રાપ્તિ માર્ગ નથી; તે એવા માર્ગનું વર્ણન કરતું દસ્તાવેજ છે.
બેકઅપ શું પુનઃસ્થાપિત કરતું નથી
રૂપરેખાંકન આર્કાઇવ ફાઇલોનું રેકોર્ડ છે, અને અપડેટ ફાઇલોથી વધુ બદલે છે. પેકેજ સ્થિતિ, કર્નલ મોડ્યુલ, સક્ષમ યુનિટ લિંક અને અલગ ટૂલ દ્વારા લાગુ કરાયેલા ફાયરવોલ નિયમો બધા રૂપરેખાંકન ડિરેક્ટરીની બહાર રહે છે, અને તેમને અવગણતું પુનઃસ્થાપન એવું મશીન બનાવે છે જે રૂપરેખાંકિત દેખાય છે અને ફોરવર્ડ કરતું નથી.
| What changed | Restored by a configuration backup | Needs its own action |
|---|---|---|
| Service unit or startup ordering | Partly, if the unit file was included | Package state and enabled links |
| Kernel module or interface support | No | Kernel or module rollback, or a boot-time decision |
| Peer or device authorization | Only if the backup predates the revocation | A deliberate decision about which peers return |
| Firewall rules applied outside the config | Only if they were captured | Replaying and verifying each rule |
અધિકૃતિ પોતાની અલગ લાઇનને લાયક છે. જોખમી ઉપકરણ દૂર કરવામાં આવે તે પહેલાં લીધેલો બેકઅપ તે ઉપકરણની ઍક્સેસ ખુશીથી પુનઃસ્થાપિત કરશે. અડચણ દરમિયાન તેના પર પાછા જવું એ જ રીતે એક ઘટના બે ઘટના બને છે, અને પુનઃસ્થાપનનો નિર્ણય ફાઇલો વિશે જેટલો સ્પષ્ટ છે તેટલો જ પીઅર્સ વિશે પણ લેવો જોઈએ.
રોલબેકની પદ્ધતિ પણ મહત્ત્વની છે. પેકેજ-સંચાલિત ફાઇલ પર જૂની એક્ઝિક્યુટેબલ કૉપી કરવી એ પેકેજ ફેરફારનું સમર્થિત ઉલટાવવું નથી, અને તે પેકેજ ડેટાબેઝને એવી સ્થિતિ વર્ણવવા દે છે જે ફાઇલસિસ્ટમ સાથે મેળ ખાતી નથી. પેકેજ મેનેજરનો પોતાનો ડાઉનગ્રેડ માર્ગ અથવા પ્રદાતા આપે તે સ્નેપશોટ વાપરો. પેકેજ ડેટાબેઝ જે ડાઉનગ્રેડ નોંધે છે તે તમે પુનરાવર્તિત કરી શકો તેવો છે.
આમાંથી કંઈ પણ બેકઅપ વિરુદ્ધ દલીલ કરતું નથી. તે એ જાણવાની તરફેણમાં દલીલ કરે છે કે દરેક આર્ટિફેક્ટ કયો સ્તર આવરી લે છે, કારણ કે આંશિક પુનઃસ્થાપનની નિષ્ફળતાની રીત મૂળ અડચણ કરતાં વધુ ગૂંચવણભરી છે. રનબુકમાં દરેક બેકઅપની બાજુમાં સ્તર લખો.
ચેકપોઇન્ટ, અપડેટ, પછી બહારથી ચકાસણી
પરિવર્તન પહેલાંની સ્થિતિ એવી રીતે નોંધો જે પછી સરખાવી શકાય: સ્થાપિત આવૃત્તિઓ, સંબંધિત સેવા યુનિટ, સાંભળતા સોકેટ અને વર્તમાન પીઅર યાદી. લિનક્સ હોસ્ટ પર ચાર આદેશ તેમાંથી મોટા ભાગને આવરી લે છે.
systemctl list-units --type=service | grep -E 'openvpn|wg-quick'
ss -lunp | grep -E ':51820|:1194'
journalctl -u wg-quick@wg0 --since '-10 min'પહેલો દર્શાવે છે કે કયા યુનિટ છે અને તે ચાલી રહ્યા છે કે નહીં, બીજો પુષ્ટિ કરે છે કે શ્રોતા ખરેખર બંધાયેલો છે, અને ત્રીજો તમને છેલ્લી થોડી મિનિટોનો સેવાનો પોતાનો હિસાબ આપે છે. તેમાંથી કોઈ પણ સાબિત કરતું નથી કે ક્લાયન્ટ જોડાઈ શકે છે, તેથી આગળનું પગલું હોસ્ટની બહાર થાય છે. તે વાંચનોને તમારા સરખામણીના આધાર તરીકે રાખો.
એવા નેટવર્કથી ચકાસો જે ટનલ વાપરતું નથી: એક અધિકૃત ક્લાયન્ટને પ્રમાણિત કરો, નામ ઉકેલો, અને એક ઇચ્છિત એપ્લિકેશન સુધી પહોંચો. ઇન્ટરફેસ ઉપર છે એમ કહેતી સ્થાનિક સ્થિતિ લાઇન ઇન્ટરફેસ વિશેનું નિવેદન છે, રૂટિંગ, કી કે પીઅર સ્વીકારતી નીતિ વિશે નહીં.
પછી ફરી જોડાવાના માર્ગને જાણી જોઈને ચકાસો. સેવાને એક વાર ફરી શરૂ કરો અને ખાતરી કરો કે ટનલ જાતે કોઈ દખલ વિના પાછી આવે છે, કારણ કે જે સેવા ફક્ત બૂટ વખતે જ યોગ્ય રીતે શરૂ થાય છે તે તમને સૌથી ખરાબ ક્ષણે ચોંકાવશે.
જ્યારે તે નિષ્ફળ જાય, ત્યારે ચકાસેલા માર્ગનો ઉપયોગ કરો
પુનઃપ્રાપ્તિનો ક્રમ ભવ્ય નથી અને તે કામ કરે છે: સ્વતંત્ર માર્ગથી હોસ્ટ સુધી પહોંચો, સેવાના પોતાના લોગ વાંચો, અને નિષ્ફળતાને અનુરૂપ ચોક્કસ ચેકપોઇન્ટ પુનઃસ્થાપિત કરો. દરેક પ્રયાસમાં એક વસ્તુ બદલો જેથી આગલું લોગ વાંચન કંઈક અર્થ ધરાવે.
કનેક્ટિવિટી પાછી લાવવા માટે ઘણા નોંધ ન કરેલા ફેરફારો કરવાની ઉત્કટતાનો પ્રતિકાર કરો. એકસાથે પાંચ સંપાદનોથી સમારેલું મશીન પછી સમજાવી શકાતું નથી, અને આગલું અપડેટ તેમાંથી જે ખરેખર ભાર ઉપાડતું હતું તેને ફરી દાખલ કરશે.
પછી પુરાવા સાથે કાયમી નીતિ નક્કી કરો. જો અપડેટ એવી નિર્ભરતા ઉજાગર કરે જે કોઈએ દસ્તાવેજીકૃત ન કરી હોય, તો ઉકેલ દસ્તાવેજીકરણ અને પરીક્ષણ છે, અપડેટ બંધ કરવું નહીં. જો તે એવી સેવા ઉજાગર કરે જે સ્વચ્છ રીતે ફરી શરૂ થઈ શકતી નથી, તો ઉકેલ યુનિટમાં છે, સમયપત્રકમાં નહીં.
શરતને નામ આપતાં જ સરખામણી સ્વચ્છ રીતે ઉકેલાય છે. સ્વતંત્ર માર્ગ અનધ્યક્ષ અપડેટને સંચાલનીય જોખમ બનાવે છે. તેની ગેરહાજરી એ જ નીતિને અજાણ્યા પુનઃપ્રાપ્તિ સમય સાથેની નિર્ધારિત અડચણ બનાવે છે, અને કોઈ પણ ઓટોમેશન તે ગણિત બદલતું નથી.