શું VPN સબનેટને ASA ઇન્ટરફેસનું સુરક્ષા સ્તર મળે છે?

કોઈ પૂછે છે કે બ્રાંચનું VPN સબનેટ ASA પર «સુરક્ષા સ્તર 0 અથવા 100» ધરાવે છે કે નહીં, અને પ્રશ્નમાં પહેલેથી જ ભૂલ છે. સુરક્ષા સ્તર એ સ્થાનિક ઇન્ટરફેસની ગુણધર્મ છે અને ઇન્ટરફેસ રૂપરેખાંકનમાં 0 થી 100 સુધી નિયુક્ત થાય છે. ટનલ દ્વારા આવતું દૂરસ્થ સબનેટ કોઈ સ્તર મેળવતું નથી, crypto map કેવી રીતે લખાયેલું હોય તે પ્રશ્ન નથી. તેથી પ્રશ્નનો કોઈ આંકડાકીય જવાબ નથી.

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

સુરક્ષા સ્તરો ઇન્ટરફેસોના છે

show running-config interface ચલાવો અને તમે દરેક ભૌતિક ઇન્ટરફેસ અથવા VLAN ઇન્ટરફેસ હેઠળ security-level જોશો, ટનલ જૂથ અથવા crypto map હેઠળ નહીં. ઊંચાથી નીચા તરફની મૂળભૂત પરવાનગી તે ઇન્ટરફેસો વચ્ચે મૂલ્યાંકિત થાય છે, તેથી સંખ્યા જે પથની છે તેના પર નિરીક્ષણ અને ગર્ભિત ACLનું વર્તન બદલે છે.

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

ACL બાયપાસની એક નામવાળી સીમા છે

sysopt connection permit-vpn એ સેટિંગ છે જે લોકો અડધું યાદ રાખે છે જ્યારે તેઓ કહે છે કે VPN ટ્રાફિક ACLને અવગણે છે. તે VPN ટ્રાફિક તરીકે લાયક ટ્રાફિક માટે ઇન્ટરફેસ ACL ખરેખર છોડી દે છે, અને 9.x પરિમાણ માર્ગદર્શિકા તેને વૈશ્વિક અપવાદ જાહેર કરવાને બદલે ઇન્ટરફેસ અને દિશા પ્રમાણે મર્યાદિત કરે છે.

સ્મૃતિમાંથી વિચાર કરતા પહેલા તપાસો કે શું રૂપરેખાંકિત છે:

• show running-config all sysopt વાસ્તવિક મૂલ્ય જોવા માટે, ફક્ત બિન-મૂળભૂત લાઇનો નહીં.
• show running-config access-group કઈ ACL કયા ઇન્ટરફેસ અને દિશા પર લાગુ થઈ છે તે જોવા માટે.
• show vpn-sessiondb detail l2l સત્ર ખરેખર કયું ટનલ જૂથ અને ફિલ્ટર વાપરે છે તેની ખાતરી કરવા માટે.

VPN ઍક્સેસ કડક કરવા માટે તે સેટિંગ બંધ કરવી એ મોટા પ્રભાવનો ફેરફાર છે. તે દરેક લાયક VPN પ્રવાહને ફરીથી બહારની ACLને આધીન કરે છે, જે સામાન્ય રીતે કાર્યરત ટનલને એવી રીતે તોડે છે જેનો તમને પૂછવામાં આવેલી બ્રાંચ સાથે સંબંધ નથી.

સત્ર સાથે જોડાયેલ ફિલ્ટર વાંચો

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

અગ્રતાને ધારવાને બદલે તેની ખાતરી કરો. show running-config group-policy <name> જૂથનું મૂલ્ય બતાવે છે, અને show running-config username <name> બતાવે છે કે દરેક વપરાશકર્તા માટે મૂલ્ય છે કે નહીં. બંને હાજર હોય તો વપરાશકર્તાનું મૂલ્ય જીતે છે. પછી તે ACLની એન્ટ્રીઓને તમને મહત્ત્વની પ્રવાહ સાથે, ફિલ્ટર જે દિશામાં મૂલ્યાંકન કરે છે તે દિશામાં સરખાવો.

એપ્લિકેશન સર્વરને પરવાનગી આપતું ફિલ્ટર મેનેજમેન્ટ વિશે કંઈ કહેતું નથી. એ અલગ પથ પર અલગ નિયમો છે.

એક પરવાનગી અને એક નકાર તપાસો

વપરાશકર્તા જાણ કરે તેની રાહ જોયા વગર નિર્ણય જોવાનો સૌથી ઝડપી રસ્તો Packet-tracer છે. તેને ડિક્રિપ્ટ બાજુનો પ્રવાહ આપો અને તે પસાર થતા ACL, NAT અને નિરીક્ષણ તબક્કાઓને નામ આપવા દો.

1. packet-tracer input outside tcp 10.20.30.10 49152 10.0.5.20 443 detailed
2. પરિણામ લાઇન વાંચો: તે તે ACLનું નામ આપે છે જેણે પેકેટને પરવાનગી આપી અથવા કાઢી નાખ્યું.
3. inside ઇન્ટરફેસ પર વ્યવસ્થાપન ગંતવ્ય સાથે પુનરાવર્તન કરો અને નકારની ખાતરી કરો.
4. કોઈપણ ફેરફાર પછી ફરી એક વાર પુનરાવર્તન કરો, જેથી પહેલાંની અને પછીની બંને સ્થિતિ નોંધાયેલી રહે.

પછી વાસ્તવિક ટ્રાફિક સાથે ચકાસો: બ્રાંચમાંથી એક સફળ એપ્લિકેશન વિનંતી અને ASA તરફ એક નિષ્ફળ SSH પ્રયાસ. Packet-tracer પથનું મોડેલ બનાવે છે; જીવંત પ્રવાહ સાબિત કરે છે કે મોડેલ મેળ ખાધું.

જે ફેરફારે તેને કામ કરતું કર્યું તે પાછો ફેરવો

જો ઉપાય ACL બાયપાસ બંધ કરવો અથવા ફિલ્ટર પહોળું કરવું હતો, તો અગાઉનું રૂપરેખાંકન રાખો. ફેરફાર પહેલા સાચવેલ અસરગ્રસ્ત ઑબ્જેક્ટ્સનું show run કૅપ્ચર તેમને પુનઃસ્થાપિત કરવા માટે પૂરતું છે; ASA રૂપરેખાંકન લાઇન-લક્ષી છે, તેથી પાછું ફેરવવાનો અર્થ જૂની લાઇનો ફરી દાખલ કરવી, ફાઇલ પુનઃસ્થાપિત કરવી નહીં.

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