up અને down હૂક વડે OpenVPN ક્લાયન્ટનો અપટાઇમ કેવી રીતે માપવો

એક ડેશબોર્ડ જોડાણ કેટલા સમયથી ચાલુ છે તેની સંખ્યા માંગે છે, અને OpenVPN તે આપતું નથી। ક્લાયન્ટ જાણે છે કે તેની ટનલ ક્યારે ઉપર આવી, પણ જો સેશન સ્થિતિ ખોવાય તે પહેલાં કોઈ તે ક્ષણ નોંધે તો જ। સમર્થિત જગ્યા up હૂક છે, અને સાચવવા લાયક મૂલ્ય ફોર્મેટ કરેલ સ્ટ્રિંગ નહીં પણ કાચી epoch સેકન્ડ છે। તેના પછી બધું ગણિત છે, સાથે થોડા ક્રમના નિયમો જે નક્કી કરે છે કે સંખ્યા પ્રામાણિક રહે છે કે નહીં।

ખાતરી કરો કે હૂક ખરેખર ચાલે છે

તેની આસપાસ કંઈ પણ રચના કરતાં પહેલાં સાબિત કરો કે હૂક ચાલે છે। ન્યૂનતમ ક્લાયન્ટ રૂપરેખાંકનને script-security 2 અને સ્પષ્ટ માર્ગો up અને down ની જરૂર છે; સુરક્ષા લાઇન વિના OpenVPN સ્ક્રિપ્ટ ચલાવવાનો ઇનકાર કરે છે અને તે સ્પષ્ટ કહે છે। તે જ સમયે up-restart અને down-pre ઉમેરો જેથી રીસ્ટાર્ટ અને ટિયરડાઉન માર્ગો અનુમાનિત રીતે વર્તે।

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

હૂક કયા વપરાશકર્તા તરીકે ચાલે છે તે તપાસો। user અને group સેટ હોય ત્યારે OpenVPN સ્ક્રિપ્ટ ચલાવતાં પહેલાં વિશેષાધિકારો છોડી દે છે, તેથી root જે ડિરેક્ટરીમાં લખી શકે તે હૂક માટે બંધ હોઈ શકે। માર્ગ તમારા શેલની દૃષ્ટિએ નહીં, સેવાની દૃષ્ટિએ પસંદ કરો।

એક epoch મૂલ્ય નોંધો અને તેને જાણી જોઈને ભૂંસો

up હૂકને એક લાઇનની જરૂર છે, date +%s > /run/openvpn-client.started, દરેક ઇન્સ્ટન્સ માટે માર્ગ ગોઠવેલો। epoch મૂલ્ય પછીથી ભાષા, સમય ક્ષેત્ર અને ફોર્મેટના પ્રશ્નો ટાળે છે, અને તે એ જ સંખ્યા છે જે મોનિટરિંગ એજન્ટ તેના પોતાના ઘડિયાળ સાથે સરખાવી શકે।

ભૂંસવું લખવા જેટલું જ મહત્ત્વનું છે। down હૂકે ફાઇલ ખાલી કરવી કે દૂર કરવી જોઈએ, અને down-pre તેને ઇન્ટરફેસ બંધ થાય તે પહેલાં કરે છે, જે એ વિન્ડો દૂર કરે છે જ્યાં ફાઇલ પહેલેથી ગયેલી ટનલ વર્ણવે છે। up-restart પછી આંતરિક રીસ્ટાર્ટ પર સ્ટેમ્પ તાજો કરે છે, મૂળ મૂલ્યને જગ્યાએ રહેવા દેવાને બદલે। તે જોડી વિના ping સમયમર્યાદા પછીનો રીસ્ટાર્ટ એવી સંખ્યા આપે છે જે ટનલ ફરી સ્થપાય ત્યાં સુધી વધતી રહે છે।

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

લોગ લાઇન પર ભરોસો ન રાખતાં અપટાઇમ ગણો

સંગ્રહિત સેકન્ડ વાંચો, વર્તમાન સેકન્ડ વાંચો, બાદ કરો। જ્યારે ફાઇલ ગેરહાજર કે ખાલી હોય, ત્યારે પ્રામાણિક જવાબ એ છે કે કોઈ ટનલ સક્રિય નથી, એ નહીં કે અપટાઇમ શૂન્ય છે, કારણ કે એ બે સ્થિતિએ અલગ ચેતવણીઓ ઉઠાવવી જોઈએ। મોનિટરિંગ પેલોડમાં કાચી સેકન્ડ રાખો અને દિવસ તથા કલાક દર્શન સ્તરે ફોર્મેટ કરો। નિકાસકર્તાની અંદર ગોળ કરતું ફોર્મેટર એ ચોકસાઈ ફેંકી દે છે જે ઘટનાના સમયે કોઈને જોઈશે।

લોગના ટાઇમસ્ટેમ્પ પાર્સ કરવા એ લોભામણો ટૂંકો રસ્તો છે, અને તે ત્રણ રીતે નિષ્ફળ જાય છે: ફોર્મેટ સેટ કરેલા વિકલ્પોને અનુસરે છે, રોટેશન ઇતિહાસ દૂર કરે છે, અને ફરી જોડાણો એક સતત ટનલને બદલે અલગ સેશન તરીકે દેખાય છે। હૂક ઘટના એક જ વાર નોંધે છે, જે ક્ષણે તે બને છે।

જ્યારે તપાસ બીજા હોસ્ટ પર ચાલે, ત્યારે અવધિને બદલે ટાઇમસ્ટેમ્પ મોકલો જેથી વાચક તેની પોતાની ઘડિયાળ લગાવે। પછી નાનું નકારાત્મક પરિણામ તૂટેલા હૂકને બદલે ઘડિયાળના તફાવત તરીકે વંચાય છે।

ફરી જોડાણ, રીસ્ટાર્ટ અને અનેક ઇન્સ્ટન્સ આવરી લો

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

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

સર્વર બાજુ, સ્થિતિ ફાઇલ દરેક ક્લાયન્ટ માટે connected-since મૂલ્ય ધરાવે છે, જે બીજા પ્રશ્નનો જવાબ આપે છે: સર્વરે તે પીઅરને છેલ્લે ક્યારે જોયું। તેને બદલી તરીકે નહીં, ક્રોસ-ચેક માટે વાપરો, કારણ કે તે વર્ણવેલ સેશન સાથે અદૃશ્ય થાય છે। બંનેમાંથી કોઈ માપ ટનલ પાછળની એપ્લિકેશનની સ્વાસ્થ્ય વિશે કંઈ કહેતું નથી।

ક્રમની ભૂલો પકડતી ત્રણ તપાસ ચલાવો

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

દર સાઠ સેકન્ડે એક પોલ ચેતવણી આવરે છે, અને કોઈ હૂકે તે પોલર જીવતો હોવાની આશા ન રાખવી જોઈએ। એ બે જવાબદારીઓ અલગ રાખો અને કોઈપણ બાજુ ફરી તૈનાત થાય ત્યારે સંખ્યા વિશ્વસનીય રહે છે।