આ લેખ "તમારા નેટવર્ક ઇન્ફ્રાસ્ટ્રક્ચર પર નિયંત્રણ કેવી રીતે લેવું" લેખોની શ્રેણીમાં ત્રીજો લેખ છે. શ્રેણીના તમામ લેખોની સામગ્રી અને લિંક્સ મળી શકે છે અહીં.

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

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

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

અમારું કાર્ય હવે નેટવર્ક સ્તરે સુરક્ષા સાથે સંકળાયેલા જોખમોને ઓળખવાનું અને તેને વાજબી સ્તરે ઘટાડવાનું છે.

નેટવર્ક સુરક્ષા ઓડિટ

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

હું કેટલાક સંભવિત નેટવર્ક સુરક્ષા ઓડિટ પ્રકાશિત કરીશ:

• સાધન રૂપરેખાંકન ઓડિટ (સખ્તાઇ)
• સુરક્ષા ડિઝાઇન ઓડિટ
• ઍક્સેસ ઓડિટ
• પ્રક્રિયા ઓડિટ

ઇક્વિપમેન્ટ કન્ફિગરેશન ઓડિટ (સખ્તાઇ)

એવું લાગે છે કે મોટાભાગના કિસ્સાઓમાં તમારા નેટવર્કની સુરક્ષા અને ઑડિટ કરવા માટે આ શ્રેષ્ઠ પ્રારંભિક બિંદુ છે. IMHO, આ પેરેટોના કાયદાનું સારું પ્રદર્શન છે (20% પ્રયત્નો 80% પરિણામ આપે છે, અને બાકીના 80% પ્રયત્નો માત્ર 20% પરિણામ આપે છે).

મુખ્ય વાત એ છે કે સાધનસામગ્રીને ગોઠવતી વખતે અમારી પાસે સામાન્ય રીતે સુરક્ષા માટે "શ્રેષ્ઠ પ્રથાઓ" સંબંધિત વિક્રેતાઓની ભલામણો હોય છે. આને "સખ્તાઇ" કહેવામાં આવે છે.

તમે આ ભલામણોના આધારે વારંવાર પ્રશ્નાવલી (અથવા જાતે બનાવી શકો છો) પણ શોધી શકો છો, જે તમને તે નિર્ધારિત કરવામાં મદદ કરશે કે તમારા સાધનોનું રૂપરેખાંકન આ "શ્રેષ્ઠ પ્રથાઓ"નું કેટલી સારી રીતે પાલન કરે છે અને પરિણામ અનુસાર, તમારા નેટવર્કમાં ફેરફારો કરો. . આ તમને વર્ચ્યુઅલ રીતે કોઈ ખર્ચ વિના, સુરક્ષા જોખમોને નોંધપાત્ર રીતે સરળતાથી ઘટાડવાની મંજૂરી આપશે.

કેટલીક સિસ્કો ઓપરેટિંગ સિસ્ટમ માટે કેટલાક ઉદાહરણો.

સિસ્કો આઇઓએસ રૂપરેખાંકન સખ્તાઇ
સિસ્કો IOS-XR રૂપરેખાંકન સખત
સિસ્કો NX-OS રૂપરેખાંકન સખત
સિસ્કો બેઝલાઇન સુરક્ષા તપાસ સૂચિ

આ દસ્તાવેજોના આધારે, દરેક પ્રકારના સાધનો માટે રૂપરેખાંકન આવશ્યકતાઓની સૂચિ બનાવી શકાય છે. ઉદાહરણ તરીકે, Cisco N7K VDC માટે આ જરૂરિયાતો જેવી દેખાઈ શકે છે તેથી.

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

સુરક્ષા ડિઝાઇન ઓડિટ

સામાન્ય રીતે, એન્ટરપ્રાઇઝ નેટવર્કમાં એક અથવા બીજા સ્વરૂપમાં નીચેના સેગમેન્ટ્સ હોય છે:

• DC (જાહેર સેવાઓ DMZ અને ઇન્ટ્રાનેટ ડેટા સેન્ટર)
• ઇન્ટરનેટનો ઉપયોગ
• રીમોટ એક્સેસ VPN
• WAN ધાર
• શાખા
• કેમ્પસ (ઓફિસ)
• કોર

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

આ દરેક વિભાગો માટે, સુરક્ષા જરૂરિયાતો, જોખમો અને, તે મુજબ, ઉકેલો અલગ હશે.

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

ત્યાં કોઈ સંપૂર્ણ ઉકેલ નથી (ઓછામાં ઓછું હજી સુધી નથી). તે હંમેશા સમાધાન છે. પરંતુ તે મહત્વપૂર્ણ છે કે એક અથવા બીજા અભિગમનો ઉપયોગ કરવાનો નિર્ણય તેના ગુણદોષ બંનેની સમજણ સાથે સભાનપણે લેવામાં આવે છે.

ડેટા સેન્ટર

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

ફાયરવોલ જરૂરી છે કે નહીં?

એવું લાગે છે કે જવાબ સ્પષ્ટ છે, પરંતુ બધું એટલું સ્પષ્ટ નથી જેટલું તે લાગે છે. અને તમારી પસંદગી માત્ર પ્રભાવિત થઈ શકે છે ભાવ.

ઉદાહરણ 1 વિલંબ.

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

ઉદાહરણ 2 પ્રદર્શન.

ટોચના L3 સ્વીચોનું થ્રુપુટ સામાન્ય રીતે સૌથી શક્તિશાળી ફાયરવોલના થ્રુપુટ કરતાં વધુ તીવ્રતાનો ઓર્ડર હોય છે. તેથી, ઉચ્ચ-તીવ્રતાવાળા ટ્રાફિકના કિસ્સામાં, તમારે આ ટ્રાફિકને ફાયરવૉલને બાયપાસ કરવાની મંજૂરી આપવી પડશે.

ઉદાહરણ 3 વિશ્વસનીયતા

ફાયરવોલ, ખાસ કરીને આધુનિક NGFW (નેક્સ્ટ-જનરેશન FW) જટિલ ઉપકરણો છે. તેઓ L3/L2 સ્વીચો કરતાં વધુ જટિલ છે. તેઓ મોટી સંખ્યામાં સેવાઓ અને ગોઠવણી વિકલ્પો પ્રદાન કરે છે, તેથી તે આશ્ચર્યજનક નથી કે તેમની વિશ્વસનીયતા ઘણી ઓછી છે. જો નેટવર્ક માટે સેવા સાતત્ય મહત્વપૂર્ણ છે, તો તમારે તે પસંદ કરવું પડશે કે જે વધુ સારી ઉપલબ્ધતા તરફ દોરી જશે - ફાયરવોલ સાથેની સુરક્ષા અથવા નિયમિત ACL નો ઉપયોગ કરીને સ્વીચો (અથવા વિવિધ પ્રકારના કાપડ) પર બનેલા નેટવર્કની સરળતા.

ઉપરોક્ત ઉદાહરણોના કિસ્સામાં, તમારે મોટે ભાગે (હંમેશની જેમ) સમાધાન શોધવું પડશે. નીચેના ઉકેલો તરફ ધ્યાન આપો:

• જો તમે ડેટા સેન્ટરની અંદર ફાયરવોલનો ઉપયોગ ન કરવાનું નક્કી કરો છો, તો તમારે શક્ય તેટલું પરિમિતિની આસપાસ ઍક્સેસને કેવી રીતે મર્યાદિત કરવી તે વિશે વિચારવાની જરૂર છે. ઉદાહરણ તરીકે, તમે ઈન્ટરનેટ (ક્લાયન્ટ ટ્રાફિક માટે) માંથી ફક્ત જરૂરી પોર્ટ અને જમ્પ હોસ્ટ્સથી જ ડેટા સેન્ટરની વહીવટી ઍક્સેસ ખોલી શકો છો. જમ્પ હોસ્ટ પર, તમામ જરૂરી તપાસો કરો (પ્રમાણીકરણ/અધિકૃતતા, એન્ટિવાયરસ, લોગિંગ, ...)
• તમે ડેટા સેન્ટર નેટવર્કના લોજિકલ પાર્ટીશનનો ઉપયોગ સેગમેન્ટમાં કરી શકો છો, PSEFABRIC માં વર્ણવેલ સ્કીમની જેમ ઉદાહરણ p002. આ કિસ્સામાં, રૂટીંગ એવી રીતે ગોઠવેલું હોવું જોઈએ કે વિલંબ-સંવેદનશીલ અથવા ઉચ્ચ-તીવ્રતાનો ટ્રાફિક એક સેગમેન્ટમાં (p002, VRF ના કિસ્સામાં) "અંદર" જાય અને ફાયરવોલમાંથી પસાર ન થાય. ફાયરવોલ દ્વારા વિવિધ સેગમેન્ટ વચ્ચેનો ટ્રાફિક ચાલુ રહેશે. ફાયરવોલ દ્વારા ટ્રાફિકને રીડાયરેક્ટ કરવાથી બચવા માટે તમે VRF વચ્ચે લીક થતા રૂટનો પણ ઉપયોગ કરી શકો છો
• તમે ફાયરવોલનો ઉપયોગ પારદર્શક મોડમાં પણ કરી શકો છો અને ફક્ત તે VLAN માટે જ્યાં આ પરિબળો (લેટન્સી/પ્રદર્શન) નોંધપાત્ર નથી. પરંતુ તમારે દરેક વિક્રેતા માટે આ મોડના ઉપયોગ સાથે સંકળાયેલા પ્રતિબંધોનો કાળજીપૂર્વક અભ્યાસ કરવાની જરૂર છે
• તમે સર્વિસ ચેઇન આર્કિટેક્ચરનો ઉપયોગ કરવાનું વિચારી શકો છો. આ ફાયરવોલમાંથી માત્ર જરૂરી ટ્રાફિકને જ પસાર થવા દેશે. સિદ્ધાંતમાં સરસ લાગે છે, પરંતુ મેં ઉત્પાદનમાં આ ઉકેલ ક્યારેય જોયો નથી. અમે લગભગ 5 વર્ષ પહેલાં Cisco ACI/Juniper SRX/F3 LTM માટે સર્વિસ ચેઇનનું પરીક્ષણ કર્યું હતું, પરંતુ તે સમયે આ સોલ્યુશન અમને "ક્રૂડ" લાગતું હતું.

રક્ષણ સ્તર

હવે તમારે ટ્રાફિકને ફિલ્ટર કરવા માટે તમે કયા સાધનોનો ઉપયોગ કરવા માંગો છો તે પ્રશ્નનો જવાબ આપવાની જરૂર છે. અહીં કેટલીક સુવિધાઓ છે જે સામાન્ય રીતે NGFW માં હાજર હોય છે (ઉદાહરણ તરીકે, અહીં):

• સ્ટેટફુલ ફાયરવોલિંગ (ડિફોલ્ટ)
• એપ્લિકેશન ફાયરવોલિંગ
• જોખમ નિવારણ (એન્ટીવાયરસ, એન્ટી સ્પાયવેર અને નબળાઈ)
• URL ફિલ્ટરિંગ
• ડેટા ફિલ્ટરિંગ (સામગ્રી ફિલ્ટરિંગ)
• ફાઈલ બ્લોકીંગ (ફાઈલ પ્રકારો બ્લોકીંગ)
• ડોસ રક્ષણ

અને બધું સ્પષ્ટ પણ નથી. એવું લાગે છે કે રક્ષણનું સ્તર જેટલું ઊંચું છે, તેટલું સારું. પરંતુ તમારે તે પણ ધ્યાનમાં લેવાની જરૂર છે

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

હંમેશની જેમ, તમારે તમારા નેટવર્ક માટે શ્રેષ્ઠ ઉકેલ શોધવાની જરૂર છે.

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

તેથી, નિર્ણાયક સેગમેન્ટમાં, વિવિધ કંપનીઓની ઑફર્સનો ઉપયોગ કરવો એ સારો ઉકેલ હોઈ શકે છે. ઉદાહરણ તરીકે, તમે ફાયરવોલ પર એન્ટીવાયરસને સક્ષમ કરી શકો છો, પરંતુ હોસ્ટ્સ પર સ્થાનિક રીતે એન્ટીવાયરસ સુરક્ષા (બીજા ઉત્પાદક પાસેથી) નો પણ ઉપયોગ કરી શકો છો.

વિભાજન

અમે ડેટા સેન્ટર નેટવર્કના લોજિકલ સેગ્મેન્ટેશન વિશે વાત કરી રહ્યા છીએ. ઉદાહરણ તરીકે, VLAN અને સબનેટમાં પાર્ટીશન કરવું એ પણ તાર્કિક વિભાજન છે, પરંતુ અમે તેની સ્પષ્ટતાને કારણે તેને ધ્યાનમાં લઈશું નહીં. FW સુરક્ષા ઝોન, VRF (અને વિવિધ વિક્રેતાઓના સંબંધમાં તેમના એનાલોગ), લોજિકલ ઉપકરણો (PA VSYS, Cisco N7K VDC, Cisco ACI ટેનન્ટ, ...), ... જેવી સંસ્થાઓને ધ્યાનમાં લેતા રસપ્રદ વિભાજન.

આવા તાર્કિક વિભાજન અને હાલમાં માંગમાં રહેલી ડેટા સેન્ટર ડિઝાઇનનું ઉદાહરણ આપવામાં આવ્યું છે PSEFABRIC પ્રોજેક્ટનો p002.

તમારા નેટવર્કના તાર્કિક ભાગોને વ્યાખ્યાયિત કર્યા પછી, તમે પછી વર્ણન કરી શકો છો કે ટ્રાફિક વિવિધ સેગમેન્ટ્સ વચ્ચે કેવી રીતે ફરે છે, કયા ઉપકરણો પર ફિલ્ટરિંગ કરવામાં આવશે અને કયા માધ્યમથી થશે.

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

ઘણીવાર વિભાજન માત્ર FW સુરક્ષા ઝોન પર આધારિત હોય છે. પછી તમારે નીચેના પ્રશ્નોના જવાબ આપવાની જરૂર છે:

• તમને કયા સુરક્ષા ઝોનની જરૂર છે
• તમે આ દરેક ઝોનમાં કયા સ્તરની સુરક્ષા લાગુ કરવા માંગો છો
• શું આંતર-ઝોન ટ્રાફિકને મૂળભૂત રીતે મંજૂરી આપવામાં આવશે?
• જો નહીં, તો દરેક ઝોનમાં કઈ ટ્રાફિક ફિલ્ટરિંગ નીતિઓ લાગુ કરવામાં આવશે
• દરેક જોડી ઝોન (સ્રોત/ગંતવ્ય) માટે કઈ ટ્રાફિક ફિલ્ટરિંગ નીતિઓ લાગુ કરવામાં આવશે

ટીસીએએમ

એક સામાન્ય સમસ્યા રૂટીંગ અને એક્સેસ બંને માટે અપૂરતી TCAM (ટર્નરી કન્ટેન્ટ એડ્રેસેબલ મેમરી) છે. IMHO, સાધનસામગ્રી પસંદ કરતી વખતે આ સૌથી મહત્વપૂર્ણ મુદ્દાઓમાંની એક છે, તેથી તમારે આ સમસ્યાને યોગ્ય ડિગ્રીની કાળજી સાથે સારવાર કરવાની જરૂર છે.

ઉદાહરણ 1. ફોરવર્ડિંગ ટેબલ TCAM.

ચાલો વિચાર કરીએ પાલો અલ્ટો 7k ફાયરવોલ
આપણે જોઈએ છીએ કે IPv4 ફોરવર્ડિંગ ટેબલનું કદ* = 32K
તદુપરાંત, તમામ VSYS માટે આ સંખ્યાના રૂટ સામાન્ય છે.

ચાલો ધારીએ કે તમારી ડિઝાઇન મુજબ તમે 4 VSYS નો ઉપયોગ કરવાનું નક્કી કરો છો.
આમાંના દરેક VSYS એ BGP દ્વારા ક્લાઉડના બે MPLS PE સાથે જોડાયેલ છે જેનો તમે BB તરીકે ઉપયોગ કરો છો. આમ, 4 VSYS બધા ચોક્કસ રૂટ્સ એકબીજા સાથે એક્સચેન્જ કરે છે અને લગભગ સમાન રૂટ (પરંતુ અલગ-અલગ NH) સાથે ફોરવર્ડિંગ ટેબલ ધરાવે છે. કારણ કે દરેક VSYS પાસે 2 BGP સત્રો છે (સમાન સેટિંગ્સ સાથે), પછી MPLS દ્વારા પ્રાપ્ત દરેક રૂટમાં 2 NH છે અને તે મુજબ, ફોરવર્ડિંગ કોષ્ટકમાં 2 FIB એન્ટ્રીઓ છે. જો આપણે ધારીએ કે ડેટા સેન્ટરમાં આ એકમાત્ર ફાયરવોલ છે અને તે તમામ રૂટ્સ વિશે જાણતા હોવા જોઈએ, તો તેનો અર્થ એ થશે કે આપણા ડેટા સેન્ટરમાં કુલ રૂટની સંખ્યા 32K/(4 * 2) = 4K કરતાં વધુ ન હોઈ શકે.

હવે, જો આપણે ધારીએ કે અમારી પાસે 2 ડેટા કેન્દ્રો છે (સમાન ડિઝાઇન સાથે), અને અમે ડેટા કેન્દ્રો વચ્ચે "વિસ્તૃત" VLAN નો ઉપયોગ કરવા માંગીએ છીએ (ઉદાહરણ તરીકે, vMotion માટે), તો પછી રાઉટીંગ સમસ્યાને ઉકેલવા માટે, આપણે હોસ્ટ રૂટ્સનો ઉપયોગ કરવો જોઈએ. . પરંતુ આનો અર્થ એ છે કે 2 ડેટા કેન્દ્રો માટે અમારી પાસે 4096 થી વધુ સંભવિત હોસ્ટ્સ હશે નહીં અને, અલબત્ત, આ પૂરતું નથી.

ઉદાહરણ 2. ACL TCAM.

જો તમે L3 સ્વીચો (અથવા L3 સ્વીચોનો ઉપયોગ કરતા અન્ય સોલ્યુશન્સ, ઉદાહરણ તરીકે, Cisco ACI) પર ટ્રાફિકને ફિલ્ટર કરવાની યોજના ઘડી રહ્યા હો, તો તમારે સાધનની પસંદગી કરતી વખતે TCAM ACL પર ધ્યાન આપવું જોઈએ.

ધારો કે તમે સિસ્કો કેટાલિસ્ટ 4500 ના SVI ઈન્ટરફેસ પર એક્સેસને નિયંત્રિત કરવા માંગો છો. પછી, અહીંથી જોઈ શકાય છે. આ લેખ, ઇન્ટરફેસ પર આઉટગોઇંગ (તેમજ ઇનકમિંગ) ટ્રાફિકને નિયંત્રિત કરવા માટે, તમે માત્ર 4096 TCAM લાઇનનો ઉપયોગ કરી શકો છો. જે TCAM3 નો ઉપયોગ કરતી વખતે તમને લગભગ 4000 હજાર ACE (ACL લાઇન) આપશે.

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

ઉચ્ચ ઉપલબ્ધતા

પ્રશ્ન એ છે કે: શું મારે ફાયરવોલ માટે HA નો ઉપયોગ કરવો જોઈએ અથવા બે સ્વતંત્ર બોક્સ “સમાંતર” ઇન્સ્ટોલ કરવા જોઈએ અને, જો તેમાંથી એક નિષ્ફળ જાય, તો બીજા દ્વારા ટ્રાફિકને રૂટ કરવો જોઈએ?

એવું લાગે છે કે જવાબ સ્પષ્ટ છે - HA નો ઉપયોગ કરો. આ પ્રશ્ન હજુ પણ શા માટે ઉભો થાય છે તેનું કારણ એ છે કે, કમનસીબે, સૈદ્ધાંતિક અને જાહેરાત 99 અને વ્યવહારમાં સુલભતાની ઘણી દશાંશ ટકાવારી એટલી રોઝી નથી. HA એ તાર્કિક રીતે એકદમ જટિલ વસ્તુ છે, અને વિવિધ સાધનો પર, અને વિવિધ વિક્રેતાઓ સાથે (ત્યાં કોઈ અપવાદો ન હતા), અમે સમસ્યાઓ અને બગ્સ અને સર્વિસ સ્ટોપ પકડ્યા.

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

જો તમે HA નો ઉપયોગ કરતા નથી, તો ડબલ નિષ્ફળતાના દૃષ્ટિકોણથી તમારા જોખમો ઘણા ઓછા છે (કારણ કે તમારી પાસે 2 સ્વતંત્ર ફાયરવોલ છે), પરંતુ ત્યારથી... સત્રો સિંક્રનાઇઝ થતા નથી, પછી જ્યારે પણ તમે આ ફાયરવોલ વચ્ચે સ્વિચ કરશો ત્યારે તમે ટ્રાફિક ગુમાવશો. તમે, અલબત્ત, સ્ટેટલેસ ફાયરવોલિંગનો ઉપયોગ કરી શકો છો, પરંતુ પછી ફાયરવોલનો ઉપયોગ કરવાનો મુદ્દો મોટે ભાગે ખોવાઈ જાય છે.

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

વ્યવસ્થાપનક્ષમતા

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

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

• બેકઅપ રૂપરેખાંકનો
• અપડેટ્સ
• અપગ્રેડ
• દેખરેખ
• લોગીંગ

અને આ બધું કેન્દ્રિય વ્યવસ્થાપન પ્રણાલીઓ દ્વારા ઉકેલી શકાય છે.

તેથી, ઉદાહરણ તરીકે, જો તમે પાલો અલ્ટો ફાયરવોલનો ઉપયોગ કરી રહ્યાં છો, તો પછી પેનોરમા આવો ઉકેલ છે.

ચાલુ રાખવા માટે.

સોર્સ: www.habr.com