પરવાનગીનો નિયમ ખોટી જગ્યાએ મૂકો તો તે નિયમ ન હોય તેમ વર્તે છે. nftables માં insert અને add વચ્ચેની પસંદગી નક્કી કરે છે કે નવું વિધાન સંદર્ભિત નિયમની કઈ બાજુએ પડશે, અને હેન્ડલ જીવંત નિયમસમૂહમાં નિયમને નામ આપે છે, તેની પંક્તિ સંખ્યાને નહીં. જગ્યા ખોટી હોય તો પેકેટ પહેલાં ડ્રોપ સુધી પહોંચે છે.

નીચેની સરખામણી એક નિશ્ચિત પીઅર અને એક બાહ્ય શ્રોતા-અદલાબદલી વાપરે છે. તે જાણી જોઈને સાંકડી છે; આખી શૃંખલા બદલવી એ જુદી જોખમપ્રોફાઇલ ધરાવતી બીજી ફેરફાર છે.

બે જગ્યાઓ, બે જુદા પરિણામો

insert સંદર્ભિત નિયમ પહેલાં નિયમ મૂકે છે. add તેને પછી મૂકે છે. જો સંદર્ભિત નિયમ પ્રવાહ માટે અંતિમ ડ્રોપ હોય, તો નિયમનું લખાણ સમાન હોવા છતાં આ બે આદેશો વિરોધી પરિણામો આપે છે.

સ્થાન છોડી દેવાનું પોતાનું મૂળભૂત વર્તન છે, જે ફોરમમાંથી આદેશ કોપી ન કરવાનું બીજું કારણ છે—તે શેના પર એન્કર છે તે વાંચ્યા વિના. એન્કર એ આખો નિર્ણય છે. આદેશ લખતા પહેલાં ઇચ્છિત બાજુ લખી લો. ફાઇલમાં insert અને add એક શબ્દના અંતરે છે.

સ્થાન ચોક્કસ શૃંખલાના નિયમની સાપેક્ષ છે. એ જ વિધાનને બીજી શૃંખલામાં કે બીજી hook પ્રાથમિકતામાં ખસેડવાથી તે કયા પેકેટ જુએ છે તે બદલાય છે, નિયમનું વાક્યરચના સાચું લાગે ત્યારે પણ.

હેન્ડલ નિયમ ઓળખે છે, પંક્તિ સંખ્યા નહીં

42 જેવું હેન્ડલ વર્તમાન નિયમસમૂહ સ્થિતિમાં ઓળખકર્તા છે. તે બેતાલીસમો નિયમ નથી, અને યજમાનો, પુનર્નિર્માણો કે પોતાની ગોઠવણી ફરી લોડ કરતા મેનેજર વચ્ચે તે સ્થિર નથી.

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

iptables --version
nft -a list ruleset

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

ખરેખર ડ્રોપ કરતી શૃંખલા અને નિયમ શોધો

input hook, શૃંખલાની પ્રાથમિકતા અને આ શ્રોતા-પ્રવાહને નકારતો નિયમ વાંચો. inet ટેબલ બંને સરનામાં કુટુંબો ધરાવી શકે છે, પણ વ્યક્તિગત નિયમ હજી ફક્ત IPv4 સાથે મેળ ખાઈ શકે છે.

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

insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept

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

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

પરવાનગી મર્યાદિત છે, ડ્રોપ અંતિમ છે

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

એક શૃંખલાને અલગથી તપાસવાને બદલે બધી સંબંધિત hook પ્રાથમિકતાઓ તપાસો. પેકેટ input ફિલ્ટર પસાર કરીને પણ બીજા ટેબલના hook દ્વારા જુદી પ્રાથમિકતાએ નકારાઈ શકે છે. પ્રવાહ જોઈ શકતી દરેક આધાર શૃંખલા યાદીમાં લો.

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

ફાઇલ તપાસો, પછી જીવંત પરિણામ ચકાસો

લાગુ કરતા પહેલાં સમીક્ષિત ફાઇલ પર વાક્યરચના અને વ્યવહાર તપાસ ચલાવો. તપાસ મોડ જણાવે છે કે nft ફેરફારને પાર્સ અને તૈયાર કરી શકે છે કે નહીં; તે તેને લાગુ કરતું નથી અને બીજું hook પેકેટને મંજૂરી આપશે તેનો પુરાવો આપતું નથી. માલિક લાગુ ન કરે ત્યાં સુધી ફાઇલ પ્રસ્તાવ રહે છે:

nft -c -f reviewed-vpn-rule.nft

માલિકની નિયંત્રિત પ્રક્રિયા દ્વારા લાગુ કરો અને પુનઃપ્રાપ્તિ પ્રવેશ જાળવો. નિયમ ખોટો હોય તો જે ડ્રોપ પહેલાં તમે આવવા માગતા હતા તે તમે સુધારવા માટે વાપરો છો તે માર્ગ પણ કાપી શકે છે.

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

સંબંધિત લેખો