ફાયરવોલ પેકેજ ઇન્સ્ટોલ થયું, રીબૂટ પછી નિયમો ગાયબ

પેકેજ સ્વચ્છ રીતે ઇન્સ્ટોલ થયું, નિયમોની કસોટી થઈ, અને પછીના રીબૂટ પછી ગેટવે સંપૂર્ણ ખુલ્લું હતું. વ્યવહારમાં કંઈ નિષ્ફળ ગયું નહીં; ભૂલ એ ધારણામાં હતી કે શું ટકશે. ફાયરવોલ સાધનો ઇન્સ્ટોલ કરવા, કયા નિયમો ટકવા જોઈએ તે નક્કી કરવા અને યોગ્ય ક્ષણે તેમને પુનઃસ્થાપિત કરવા એ ત્રણ અલગ કામો છે.

લક્ષણ ખરેખર શું કહે છે

રીબૂટ પર અદૃશ્ય થતા નિયમ સમૂહનો ત્રણમાંથી એક માલિક હોય છે: કોઈએ તેને સાચવ્યો નહીં, બીજું કંઈકે તેને બદલ્યો, અથવા જેના પર તે આધાર રાખે છે તે અસ્તિત્વમાં આવ્યા પહેલા તે પુનઃસ્થાપિત થયો. પ્રથમ બે ગોઠવણીમાં દેખાય છે; ત્રીજો ફક્ત ક્રમમાં જ દેખાય છે. તેથી રીબૂટ ડેટા ગુમાવ્યા જેવું લાગી શકે, જ્યારે તે ખરેખર ક્રમની સમસ્યા હોય.

રીબૂટ પહેલા શું સાચું હતું તે લખીને શરૂ કરો: કઈ સેવા નિયમો રાખતી હતી, શરૂઆતમાં તેણે કઈ ફાઇલ કે ડેટાબેઝ વાંચ્યો, અને તે સ્રોતમાં ક્યારેય લખાયું હતું કે નહીં. કોઈએ ન સાચવેલો જીવંત નિયમ સમૂહ માન્ય સમજૂતી છે અને સૌથી સામાન્ય છે.

પેકેજ ફરીથી ઇન્સ્ટોલ કરીને શરૂ ન કરો.

વાપરતા પહેલા પર્સિસ્ટન્સ સાધન વાંચો

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

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

શું લોડ થયું છે તે વાંચ્યા પછી જાણી જોઈને સાચવો.

શું ટકવું જોઈએ તે નક્કી કરો

કેટલાક નિયમો ઇન્ટરફેસના જીવનચક્રના છે અને તેની સાથે અદૃશ્ય થવા જોઈએ. બીજા ટનલ કરતાં વધુ ટકવા જોઈએ, અને સૌથી સ્પષ્ટ ઉદાહરણ એ મર્યાદા છે જે ક્લાયન્ટ ટ્રાફિકને ભૌતિક ઇન્ટરફેસ પર પાછા પડવાથી રોકે છે, જ્યારે ટનલ તૂટે છે. તે બે શ્રેણીઓને અલગ પુનઃસ્થાપન ટ્રિગરની જરૂર છે, એક સહિયારો સ્નેપશોટ નહીં.

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

જવાબ નીતિ નક્કી કરે છે, પેકેજ નહીં.

પુનઃસ્થાપનનો ક્રમ તપાસો

ફાઇલ પુનઃસ્થાપિત કરવી એ પરિણામની માલિકી ધરાવવા જેવું નથી. બીજો મેનેજર નિયમો બદલી શકે છે, અગાઉની પરવાનગી તેમને ઢાંકી શકે છે, અથવા મર્યાદા લાગુ થાય તે પહેલા ક્લાયન્ટ મોકલવાનું શરૂ કરી શકે છે. ફક્ત સાચવેલી ફાઇલની હાજરી નહીં, શરૂઆત અને પુનઃકનેક્શનનું વર્તન સમીક્ષા કરો.

systemctl status netfilter-persistent
iptables -S

ધારશો નહીં કે પર્સિસ્ટન્સ સેવા બંધ કરવી હાનિકારક નથી, કારણ કે પેકેજ બંધ થાય ત્યારે શરતી ફ્લશનું દસ્તાવેજીકરણ કરે છે. દૂરથી સંચાલિત ગેટવે પર બંધ કરવું કે ફરી શરૂ કરવું પ્રયોગ તરીકે વાપરતા પહેલા સેવાની વાસ્તવિક ગોઠવણી સ્થાપિત કરો. તે પરીક્ષણ પહેલા કન્સોલ સત્ર અને દસ્તાવેજીકૃત રોલબેક ન્યૂનતમ છે.

ક્રમ ચાલતી સિસ્ટમનો ગુણધર્મ છે, ડિસ્ક પરની ફાઇલનો નહીં.

ત્રણ અલગ પરિણામો સ્વીકારો

પેકેજ ઇન્સ્ટોલેશન, લોડ થયેલ નિયમ સમૂહ અને લાગુ કરેલ નીતિને અલગ તથ્યો તરીકે નોંધો. સહાય થ્રેડમાં પેકેજનું નામ ફક્ત પ્રથમનો જવાબ આપે છે, અને તે જ ભાગ્યે જ મહત્ત્વનું હોય છે.

nft list ruleset

પછી મંજૂર ક્રિયા અને જરૂરી નકારની કસોટી કરો.

જો નકાર રીબૂટ પછી અને ટનલ તૂટ્યા પછી ટકે, તો નીતિ ટકે છે. જો તે ફક્ત એ સ્થિતિઓમાંથી એકમાં ટકે, તો તમે સુધારવાને બદલે ક્રમની સમસ્યા શોધી કાઢી છે.