ફક્ત NEW નિયમો દરેક WAN માર્ગ બંધ કરતા નથી

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

સ્થિતિ એ મેળની શરત છે, ચુકાદો નહીં

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

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

નિયમને તેના પરિવેશમાં વાંચો

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

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

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

નિષેધને સ્થિતિથી સ્વતંત્ર રીતે વ્યક્ત કરો

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

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

WAN પર દૂરથી શરૂ થયેલા પ્રવેશના જવાબોને જાણી જોઈને મંજૂરી આપતી નીતિ વાજબી છે. ફક્ત તેને સંપૂર્ણ ટનલ-એકમ અલગાવ તરીકે રજૂ કરવાને બદલે એ જ રીતે વર્ણવવી જોઈએ.

જૂથમાં ખરેખર કોણ છે તે તપાસો

ઉદાહરણ એક ઇન્ટરફેસમાંથી એક પ્રીફિક્સના ફોરવર્ડ IPv4 ટ્રાફિકને આવરી લે છે. તે IPv6, બીજા અપલિંક, અથવા રાઉટર પોતે ઉત્પન્ન કરે તે ટ્રાફિક વિશે કંઈ કહેતું નથી. DNS રિઝોલ્વર તરીકે કામ કરતું રાઉટર પોતાની અપસ્ટ્રીમ ક્વેરી મોકલે છે, અને તે ફોરવર્ડ સાંકળમાંથી જતી જ નથી.

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

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

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