સાઇટ-થી-સાઇટ VPN: કઈ દિશાને ખરેખર નિયમની જરૂર છે?

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

સ્ટેટફુલ પરત ટ્રાફિક ગણતરી બદલે છે

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

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

ફાયરવૉલ ડિક્રિપ્ટ થયેલા પેકેટ ક્યાં જુએ છે

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

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

અસમમિત રૂટિંગ ધારણા તોડે છે

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

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

વાસ્તવિક સ્રોત સરનામાં સાથે બંને દિશા તપાસો

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

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

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

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