તમારું VPN ઇન્ટરફેસ કેમ વારંવાર તેનો firewalld ઝોન છોડી દે છે

તમે tun0 ને યોગ્ય ઝોનમાં ઉમેરો છો, એપ્લિકેશન કામ કરવા લાગે છે, અને આગલા ફરી-કનેક્શનમાં સુધારો વરાળની જેમ ઊડી જાય છે. એ જ કમાન્ડ ફરી ચલાવવાથી કામ કરે છે, જે એવું લાગે છે કે firewalld ભૂલી ગયું. તે ભૂલ્યું નથી; તે ઇન્ટરફેસ પર વધુ મજબૂત દાવો ધરાવતી કોઈ વસ્તુએ તેને ફરી સોંપી.

ઇન્ટરફેસ ફરી બને ત્યાં સુધી ઝોન ટકી રહે છે

ઇન્ટરફેસ માટે firewalld ઝોનની સોંપણી એક બાઇન્ડિંગ છે, અને બાઇન્ડિંગ હાલ જે રીતે છે તે ઇન્ટરફેસ ઑબ્જેક્ટ સાથે બંધાયેલા છે. જે VPN ક્લાયન્ટ ઉપકરણને તોડીને ફરી બનાવે છે તે નવું ઑબ્જેક્ટ ઉત્પન્ન કરે છે, અને નવું સોંપતા ઘટક જે કહે તેનાથી શરૂ થાય છે. તેથી જ લક્ષણ દરેક પેકેટમાં નહીં, દરેક ફરી-કનેક્શનમાં પુનરાવર્તિત થાય છે.

એ જ તર્ક રીબૂટની વર્તણૂક સમજાવે છે: રનટાઇમ બાઇન્ડિંગ રીસ્ટાર્ટ ટકી શકતાં નથી, અને કાયમી બાઇન્ડિંગ ફક્ત એ જ ઉપકરણોને લાગુ પડે છે જે firewalld પોતાના માને છે.

કંઈપણ બદલતા પહેલાં શોધો કે કયું ઘટક ઝોન સોંપે છે.

કંઈપણ બદલતા પહેલાં ત્રણ વસ્તુઓ વાંચો

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

દરેક પગલે ઉપકરણનું ખરું નામ પણ નોંધો, કારણ કે આજે tun0 પર ઉતરતી ટનલ કાલે tun1 પર ઉતરી શકે છે.

સામાન્ય નામ પર સાચવેલું બાઇન્ડિંગ ઓળખ-ચકાસણી નથી, અને બે મિનિટની નોંધ એક કલાકની અટકળ બચાવે છે.

જ્યારે NetworkManager જોડાણનો માલિક હોય

જો NetworkManager VPN જોડાણનું સંચાલન કરે છે, તો તેની પ્રોફાઇલ ઝોન ધરાવે છે અને જોડાણ સક્રિય થાય ત્યારે તેને firewalld ને આપે છે. ત્યારે એ જ ઉપકરણ માટે firewalld નું કાયમી ઇન્ટરફેસ બાઇન્ડિંગ અવગણાઈ શકે છે, કારણ કે માલિક NetworkManager છે. ઝોન જોડાણ પર સેટ કરો, અને ખાતરી કરો કે તમે VPN પ્રોફાઇલ સંપાદિત કરો છો, કોઈ અસંબંધિત ભૌતિક જોડાણ કે કામચલાઉ રેકોર્ડ નહીં.

તે ગુણધર્મ બદલવાથી સક્રિય જોડાણ પર તરત અસર પડી શકે છે.

સંચાલન માર્ગ ઉપલબ્ધ રાખો અને લાગુ કરતા પહેલાં લક્ષ્ય ઝોનની નીતિ વાંચો. ifcfg ફાઇલના ZONE ક્ષેત્રને સંપાદિત કરવું ફક્ત ત્યાં જ યોગ્ય છે જ્યાં તે ફાઇલ હજી રૂપરેખાંકનનો સ્રોત છે.

જ્યારે firewalld બાઇન્ડિંગનો માલિક હોય

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

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

ફક્ત એપ્લિકેશન ચાલે તે માટે ઇન્ટરફેસને trusted માં ફેંકશો નહીં.

રીલોડ, ફરી-કનેક્શન અને રીબૂટની કસોટી કરો

ફેરફાર ફક્ત ત્યારે જ પૂરો થાય છે જ્યારે તે ત્રણેય ટકી જાય.

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

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

માલિક, મૂલ્ય અને અપેક્ષિત પરિણામ રનબુકમાં લખો, અને આગલી ફરી-સોંપણી સમજાવી શકાય તેવી હશે.