OpenVPN client-connect નિષ્ફળતા: શું disconnect સફાઈની ખાતરી છે?
નકારાયેલ ક્લાયન્ટ ફાયરવોલ નિયમ કે લખાયેલ રેકોર્ડ પાછો નથી ખેંચતો. કૉલબેક કરારની સરખામણી તે રોલબેક સાથે કરો જે તમારા hookએ જાતે કરવો પડે છે.
જ્યારે client-connect સ્ક્રિપ્ટ બિન-શૂન્ય કોડ સાથે બહાર નીકળે છે, ત્યારે OpenVPN ક્લાયન્ટને નકારે છે, અને ઓપરેટરો સામાન્ય રીતે ધારે છે કે સંબંધિત client-disconnect સ્ક્રિપ્ટ બધું ગોઠવી દેશે. ઘણી વાર તે ક્યારેય ચાલતું નથી, કારણ કે disconnect પ્રક્રિયા એના પર આધાર રાખે છે કે connect તબક્કો શું પૂરું કરી શક્યો. નકાર અને રોલબેકને એક જ કાર્યવિધિ ગણવી એ જ નિષ્ફળ લોગિનને લીક થયેલા ફાયરવોલ નિયમ કે અનાથ રેકોર્ડમાં ફેરવે છે. આ બે અલગ જવાબદારીઓ છે, અને તેમાંથી માત્ર એક જ સ્વયંસંચાલિત છે. સર્વર પર સ્થિતિ છોડવાનો આરોપ મૂકતા પહેલાં hookનો પોતાનો એક્ઝિટ માર્ગ વાંચો.
બિન-શૂન્ય એક્ઝિટ ક્લાયન્ટને નકારે છે; તમારું કામ પાછું નથી ખેંચતું
client-connectની એક્ઝિટ સ્થિતિ એ પ્રવેશ નિર્ણય છે. શૂન્ય એટલે પ્રવેશ, બીજું કંઈ પણ એટલે ઇન્સ્ટન્સ સંપૂર્ણ સ્થપાય તે પહેલાં તોડી પાડવું. તે કરારમાં કંઈ પણ તપાસતું નથી કે સ્ક્રિપ્ટે બહારની દુનિયામાં પહેલેથી શું કર્યું છે. જો સ્ક્રિપ્ટે iptables નિયમ ઉમેર્યો, પંક્તિ લખી કે કાઉન્ટર વધાર્યું, તો તે ફેરફારો નકાર પછી પણ ટકી રહે છે.
એ જ અસમાનતા પ્લગઇનોને પણ લાગુ પડે છે, જ્યાં એક ઇન્સ્ટન્સ માટે ઘણા connect ફંક્શન ચાલી શકે છે. પછીની નિષ્ફળતા પહેલાની સફળતાને પૂર્વવર્તી રીતે રદ કરતી નથી, અને પહેલાના ફંક્શન પાસે એ જાણવાનો કોઈ રસ્તો નથી કે સહોદર ફંક્શન નિષ્ફળ ગયું છે.
નકાર સ્વયંસંચાલિત છે, સફાઈ નથી
OpenVPN 2.6 માર્ગદર્શિકા client-disconnect પ્રક્રિયાને પહેલાની connect પ્રક્રિયા સફળ થવા સાથે જોડે છે. એક દસ્તાવેજી અપવાદ કાસ્કેડ સાંકળોને આવરી લે છે: જો એક connect પગલું પહેલેથી સફળતા પરત કરી ચૂક્યું હોય, તો ઇન્સ્ટન્સ તોડતી વખતે સંબંધિત disconnect પગલાં તો પણ ચાલે છે, ભલે પછીનું connect પગલું નિષ્ફળ ગયું હોય. તે અપવાદ સાંકડો છે અને કેટલા કૉલબેક ગોઠવાયા છે તેના પર આધાર રાખે છે, તેથી એક shell સ્ક્રિપ્ટનું પરીક્ષણ સાંકળ વિશે તમને કંઈ જ કહેતું નથી.
ડિઝાઇન કરતા પહેલાં વાસ્તવિક રૂપરેખા નકશા પર ઉતારો: કઈ સ્ક્રિપ્ટ, કયું પ્લગઇન અને કયા ક્રમમાં ચાલે છે. નીચેનું કોષ્ટક દર્શાવે છે કે અધૂરું સેટઅપ પાછળ શું છોડે છે.
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
દરેક પંક્તિ ક્લાયન્ટ માટે એક જ રીતે અને હોસ્ટ માટે અલગ રીતે પૂરી થાય છે. ક્લાયન્ટ કહી શકતું નથી કે તેમાંથી કઈ બની, તેથી hookએ નિષ્ફળતાની સ્થિતિ પરત કરતા પહેલાં પોતે કરેલું પાછું ખેંચવું પડે છે.
જે સ્ક્રિપ્ટ નિષ્ફળ ગઈ તેની અંદર ભરપાઈ કરો
શેર કરેલી સ્થિતિને સ્પર્શતા પહેલાં જે શક્ય હોય તે બધું માન્ય કરો: પ્રમાણપત્રનાં ક્ષેત્રો, સરનામાની ઉપલબ્ધતા, ક્લાયન્ટ જે જૂથનો છે. સૌથી સસ્તો નકાર એ છે જે કોઈ પણ ફાળવણી પહેલાં થાય. એક વાર સેટઅપ ઘણી બાહ્ય ક્રિયાઓને આવરી લે, તો કઈ પૂરી થઈ તેનો રેકોર્ડ રાખો અને નિષ્ફળતાની સ્થિતિ પરત કરતા પહેલાં તેમને ઊલટા ક્રમમાં પાછા ખેંચો.
એક ઠોસ કિસ્સો: સ્ક્રિપ્ટ દરેક ક્લાયન્ટ માટે ફાયરવોલ એન્ટ્રી બનાવે છે, પછી તેનું વર્ણન કરતી સ્થિતિ-પંક્તિ લખવામાં નિષ્ફળ જાય છે. નિષ્ફળ શાખાએ હમણાં જ બનાવેલી એન્ટ્રી દૂર કરવી જોઈએ અને પછી બિન-શૂન્ય કોડ સાથે બહાર નીકળવું જોઈએ. એવી disconnect ઘટનાની રાહ જોવી જે કદાચ ક્યારેય નિર્ધારિત ન થાય તે જ રીતે નિયમ તે સત્ર કરતાં વધુ જીવે છે જેના માટે તે બનાવાયો હતો.
ભરપાઈને ઇડેમ્પોટેન્ટ અને માલિકીની બનાવો
સફાઈ બે વાર ચલાવવા માટે સુરક્ષિત હોવી જોઈએ અને તે શું ડિલીટ કરી શકે તે અંગે ચોક્કસ હોવી જોઈએ. પહેલાના પ્રયાસની મોડી ઘટના ફક્ત એટલા માટે નવા સત્રની ફાળવણી દૂર ન કરવી જોઈએ કે બંને સામાન્ય નામ કે ફરી વપરાયેલું ટનલ સરનામું વહેંચે છે. ચોક્કસ હેન્ડલ કે ઓપરેશન આઈડી સંસાધન સાથે નોંધો, અને નામથી નહીં પણ તે કી દ્વારા ડિલીટ કરો. ડેટાબેઝ ટ્રાન્ઝેક્શન ફક્ત ડેટાબેઝના પોતાના ફેરફારોમાં મદદ કરે છે; તે સીમાની બહારનો ફાયરવોલ નિયમ સ્પષ્ટ ભરપાઈ પગલું માંગે છે.
ધારો કે પ્રક્રિયા ફેરફાર અને સફાઈ વચ્ચે મરી શકે છે, અને એક સમાધાનકર્તા ઉમેરો જે સમયપત્રક મુજબ બાહ્ય સ્થિતિની સરખામણી સ્વીકૃત ક્લાયન્ટ યાદી સાથે કરે છે.
ખરેખર અલગ પડતા ત્રણ માર્ગોનું પરીક્ષણ કરો
ત્રણ કિસ્સા કરો: કંઈ પણ ફાળવાય તે પહેલાં નકાર, આંશિક ફાળવણી પછી નકાર, અને પછીથી પૂરું થતું સામાન્ય સ્વીકૃત સત્ર. તે ત્રણ અલગ લોગ લાઇન અને અલગ અવશેષો ઉત્પન્ન કરે છે. દરેક પછી બાહ્ય સ્થિતિની ચકાસણી કરો, ફક્ત ક્લાયન્ટની નિષ્ફળતા સંદેશની નહીં, કારણ કે ત્રણમાંથી બેમાં ક્લાયન્ટની નિષ્ફળતા જ અપેક્ષિત પરિણામ છે.
hookનો તબક્કો, એક્ઝિટ સ્થિતિ અને શું ફાળવાયું કે મુક્ત થયું તે લોગ કરો, ઓળખપત્રો બાદ કરીને. જે hook લોગ પોતે બનાવેલા સંસાધનનું નામ લે છે તે જ છ મહિના પછી લીક થયેલા નિયમને શોધી શકાય તેવો બનાવે છે.