ફાયરવોલ નિયમનો ફેરફાર કામ કરતું નથી: નિયમનો ક્રમ અને કનેક્શનની સ્થિતિ

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

નિયમનો ક્રમ અને કનેક્શનની સ્થિતિ જુદી જુદી ખામીઓ છે

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

કનેક્શન ટ્રેકિંગ બીજું લક્ષણ ઉત્પન્ન કરે છે, અને બહારથી તે બરાબર એવું જ દેખાય છે. એકવાર પ્રવાહ સ્ટેટ ટેબલમાં આવે, સાંકળની ટોચ નજીકની established-or-related મંજૂરી તમારા નવા નિયમની સલાહ લેવાય તે પહેલાં જ પાછી ફરે છે. NAT મેપિંગમાં પણ એ જ ગુણધર્મ છે: પ્રવાહ શરૂ થયો ત્યારે અનુવાદ નિશ્ચિત થઈ ગયો હતો, તેથી સંપાદિત postrouting નિયમ પહેલેથી ચાલી રહેલા સત્રને ફરી લખતું નથી. તેથી જ ફેરફાર 09:00 વાગ્યે નવા કનેક્શન માટે કામ કરતો દેખાય છે અને 08:55 વાગ્યે કોઈએ ખોલેલા સત્ર માટે કંઈ જ કરતો નથી દેખાતો.

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

સક્રિય નિયમસેટ વાંચો, તમે સંપાદિત કરેલી ફાઇલ નહીં

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

nft list ruleset
iptables-save

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

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

વાસ્તવિક પરીક્ષણ પ્રયાસ પછી શૂન્ય પેકેટવાળો લોકડાઉન નિયમ નીતિની સમસ્યા નથી, તે સ્થાનની સમસ્યા છે. તેને ખસેડવું એક લીટીનો ફેરફાર છે, અને સિન્ટેક્સ બરાબર એ જ છે જે મૂળ બગનું કારણ બન્યું. iptables સાથે -I દાખલ કરે છે અને -A અંતમાં ઉમેરે છે; nftables સાથે insert નિયમને સાંકળની શરૂઆતમાં મૂકે છે જ્યારે add અંતમાં ઉમેરે છે. જ્યારે નિયમને જીતવું જ પડે, ત્યારે આકસ્મિક રીતે લોડ થયેલા ક્રમ પર ભરોસો કરવાને બદલે તે સ્પષ્ટ કહો.

પ્રવાહ ટ્રેક થાય છે કે નહીં તે સાબિત કરો

નિયમને દોષ આપતા પહેલાં, ટ્રાફિક બિલકુલ ટ્રેક કરેલું કનેક્શન છે કે નહીં તે તપાસો. આખું સ્ટેટ ટેબલ ઠાલવવાને બદલે ચોક્કસ પ્રવાહ વિશે પૂછો:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

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

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

કેટલાક માર્ગો ટ્રેક થતા નથી, અને તે ઊલટું વર્તે છે. raw ટેબલમાં notrack તરીકે ચિહ્નિત ટ્રાફિક, સામાન્ય હૂક ટાળતી કેટલીક ટનલ, અને પ્રવાહને બે ગેટવે વચ્ચે વિભાજિત કરતું અસમમિત રૂટિંગ—બધા એક-એક કરીને મૂલ્યાંકિત થતાં પેકેટો ઉત્પન્ન કરે છે, અથવા એવી સ્થિતિ જે બંને છેડે ક્યારેય બનતી નથી. જો દરેક પેકેટ પર કાઉન્ટર હલે છે, તો ક્રમ પર શંકા કરતાં પહેલાં એ પ્રકારના માર્ગ પર શંકા કરો.

પાછા ફરવાના રસ્તા સાથે નવા પ્રવાહથી પરીક્ષણ કરો

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

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

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

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

નિયમ સાથે હેતુ અને સ્થાન નોંધો

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

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