VPN ટ્રાફિક માટે ASA identity NAT વિરુદ્ધ IOS NAT બાકાત

એક શાખા એક જ Cisco ગેટવે પર ઇન્ટરનેટ PAT અને સાઇટ-થી-સાઇટ VPN રાખે છે, અને NAT ઉમેરતાં જ VPN કામ કરવાનું બંધ કરે છે. ટનલની અંદરના સરનામાં હવે crypto ACL જે સુરક્ષિત કરે છે તેની સાથે મેળ ખાતા નથી, અથવા સામેનો પક્ષ એવા અનુવાદિત સરનામાં જુએ છે જેના માટે તેની પાસે કોઈ માર્ગ નથી. Cisco આને બે જગ્યાએ ઉકેલે છે: ASA એવો NAT નિયમ પસંદ કરે છે જે સરનામાને તેના પોતા સાથે મેપ કરે છે, જ્યારે IOS ACL deny દ્વારા ફ્લોને અનુવાદ નિયમની બહાર રાખે છે. બંને મૂળ સરનામાં જાળવે છે, અને એક પણ NAT પ્રક્રિયાને બાયપાસ કરતું નથી.

નિયમ પસંદ કરતા પહેલાં ફ્લો નોંધો

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

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

ASA identity NAT એ નિયમ છે, બાયપાસ નહીં

ASA પર, identity NAT એ NAT નિયમ છે જેનું અનુવાદિત સરનામું મૂળ સરનામા જેટલું જ છે. તે અન્ય કોઈપણ નિયમની જેમ પસંદ થાય છે અને હજી પણ અનુવાદ એન્ટ્રી સ્થાપિત કરે છે, તેથી પેકેટ NAT પ્રક્રિયા છોડતું નથી. જે બદલાય છે તે એ છે કે વાયર પરના સરનામાં સરખા રહે છે, અને IPsec નીતિને એ જ જોઈએ છે.

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

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

ASA પોતાનું સંચાલન પ્રવેશ અલગ કિસ્સો છે. જો તમે સંચાલન ટ્રાફિક માટે identity NAT વાપરો છો, તો આવૃત્તિ-વિશિષ્ટ route-lookup જરૂરિયાત લાગુ પડે છે, અને VPN ઉદાહરણમાંથી કોપી કરેલી વ્યાપક બાકાત SSH સુધારશે નહીં.

IOS NAT ACL deny એટલે અહીં પસંદ થયું નથી

IOS પર, ઇન્ટરનેટ NAT સ્રોત યાદી દ્વારા ચાલે છે, અને તે ACL ફિલ્ટર નહીં, ક્લાસિફાયર છે. Permit લાઇન અનુવાદ માટે ટ્રાફિક પસંદ કરે છે; deny લાઇન એટલે પેકેટ અહીં પસંદ થયું નથી. તે deny ઇન્ટરફેસ ACL ના deny જેવું પેકેટ ફેંકી દેવાનો આદેશ નથી.

અહીં પસંદ ન થવું એ ક્યાંય પણ અનુવાદ ન થવા કરતાં સાંકડું પણ છે. બીજો NAT નિયમ, બીજું ઇન્ટરફેસ કે route-map હજી ફ્લોનું અનુવાદ કરી શકે છે, તેથી આખું NAT ટેબલ વાંચવું પડે. પેકેટને હજી પણ માર્ગ, મેળ ખાતું crypto ACL અને ખરેખરા એક્સેસ-કંટ્રોલ સીમાઓ પર પરવાનગી જોઈએ.

ન્યૂનતમ IOS ગોઠવણી deny ને એ જ યાદીમાં permit ની ઉપર મૂકે છે અને overload નિયમને તે યાદી તરફ નિર્દેશ કરે છે. પછી crypto ACL એ જ જોડીને સુરક્ષિત કરે છે જે deny અનુવાદમાંથી બાકાત રાખે છે.

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

બંને મોડેલ માટે એક ચકાસી શકાય તેવો પ્રશ્ન

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

ASA પર nat detail અને અનુવાદ ટેબલ દર્શાવો; IOS પર ip nat translations અને અનુરૂપ ACL કાઉન્ટર દર્શાવો. જે નિયમ ક્યારેય વધતો નથી તે ક્યારેય પસંદ થયો નથી, અને તે crypto ગોઠવણી નહીં પણ ક્રમ, ઇન્ટરફેસ કે દિશા તરફ સંકેત કરે છે.

ગોઠવણી સામાન્ય રીતે ક્યાં ખોટી જાય છે

સામાન્ય નિષ્ફળતાઓ યાંત્રિક છે. deny permit ની નીચે બેસે છે અને ક્યારેય મેળ ખાતું નથી. ક્લાસિફાયર ખોટી દિશામાં લાગુ થાય છે, તેથી પરત ફ્લોનું અનુવાદ થાય છે. identity નિયમ યોગ્ય સરનામાં પણ ખોટી ઇન્ટરફેસ જોડી આવરે છે. crypto ACL એવી સબનેટ સુરક્ષિત કરે છે જે હવે NAT નિયમ જે રજૂ કરે છે તેની સાથે મેળ ખાતી નથી.

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