ASA packet-tracer સાથે VPN પ્રવાહ કેવી રીતે મોડેલ કરવો

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

નીચેની મુલાકાત ધારે છે કે ACL, NAT નિયમ અને tunnel-group સંદર્ભ તમારી સામે છે। તેમના વિના આઉટપુટ એવી નીતિ વર્ણવે છે જે તમે ચકાસી શકતા નથી।

પગલું 1: આંતરિક પ્રવાહ સરળ શબ્દોમાં લખો

કંઈપણ લખતા પહેલા એપ્લિકેશનનું વર્ણન કરો। અંદરનો હોસ્ટ જે દૂરના ગેટવે પાછળના સર્વર સાથે SSH ખોલે છે તે ચોક્કસ સ્રોત પોર્ટ સાથેનો એક આંતરિક TCP પ્રવાહ છે। એ જ પ્રવાહ છે જે ACL અને VPN ફિલ્ટર મૂલ્યાંકન કરે છે, તેથી એ જ પ્રવાહ તમે લખો છો।

તેને એક વાક્ય તરીકે લખો, પછી ક્ષેત્ર દર ક્ષેત્ર અનુવાદ કરો:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

પગલું 2: ઇનગ્રેસ અને દિશા પસંદ કરો

ઇનગ્રેસ એ ઇન્ટરફેસ છે જેના પર પેકેટ આવે છે, જેમાંથી તે નીકળે છે તે નહીં। શરૂ કરતા LAN હોસ્ટ માટે તે inside ઇન્ટરફેસ છે। સમાન સત્રના પરત પેકેટ માટે તે outside ઇન્ટરફેસ છે, અને ટ્યુપલ ઊલટું થાય છે। ગંતવ્યને સ્રોત તરીકે લખવું એ વિશ્વાસપાત્ર પણ અપ્રસ્તુત ALLOW મેળવવાનો બીજો સૌથી સામાન્ય રસ્તો છે।

પોર્ટ પણ દિશાવાળા છે। શરૂ કરેલી વિનંતીમાં સેવા પોર્ટ ગંતવ્ય ક્ષેત્રમાં આવે છે, અને ક્લાયન્ટનો અલ્પજીવી પોર્ટ સ્રોત ક્ષેત્રમાં આવે છે। TCP ગંતવ્ય 500 ધરાવતું મોડેલ 500 પર સાંભળતી TCP એપ્લિકેશનનું વર્ણન કરે છે; આદેશમાં સંખ્યા દેખાય એટલે તે IKE પરીક્ષણ બનતું નથી।

પગલું 3: તબક્કા ક્રમમાં વાંચો

આઉટપુટમાંનો દરેક તબક્કો માલિક ધરાવતો નિર્ણય છે: રૂટ શોધ, ACL, NAT, પછી VPN કે ટનલ પસંદગી। છાપેલા ક્રમમાં તેમને વાંચો અને ડિઝાઇન સાથે ન મળતા પ્રથમ તબક્કે થોભો।

NAT લોકોને ભૂલમાં નાખે છે। જો અનુવાદિત સ્રોત ટનલ માટે ટ્રાફિક પસંદ કરતા crypto ACL ની બહાર પડે, તો પ્રવાહ મંજૂર થઈ શકે છે અને કદી એન્કેપ્સ્યુલેટ ન થાય। ટ્રેસ અનુવાદિત સરનામું છાપે છે, તેથી તેને મૂળ સરનામા સાથે નહીં, ટનલના રસપ્રદ ટ્રાફિક સાથે સરખાવો।

પગલું 4: તમે કયા બાયપાસ પસંદ કર્યા તે ચકાસો

detailed સ્વરૂપ એવા વિકલ્પો લે છે જે ચકાસણી છોડી દે છે, અને Cisco bypass-checks વિકલ્પનું દસ્તાવેજીકરણ કરે છે જે ACL, VPN ફિલ્ટર, uRPF અને IPsec સ્પૂફ ચકાસણી આવરે છે। તેમને છોડીને મેળવેલ ALLOW કહે છે કે રૂટ અને NAT કામ કરશે, એ નહીં કે નીતિ વાસ્તવિક પેકેટ સ્વીકારશે। પરિણામની બાજુમાં વિકલ્પો નોંધો।

જો તમને નીતિનો જવાબ જોઈએ, તો બાયપાસ વિના ચલાવો। જો તમે રૂટિંગ પ્રશ્ન અલગ કરો છો, તો તેમની સાથે ચલાવો અને પરિણામને રૂટિંગ જવાબ તરીકે લેબલ કરો।

પગલું 5: વાસ્તવિક વિનિમય સાથે અંતર બંધ કરો

સિમ્યુલેટેડ પરવાનગી ASA પર અટકે છે। દૂરના ગેટવેએ પેકેટ ડિક્રિપ્ટ કર્યું કે નહીં, સર્વરે કનેક્શન સ્વીકાર્યું કે નહીં અને જવાબ પાછો આવ્યો કે નહીં, એ અલગ અવલોકનો છે। એન્ડપોઇન્ટ કાઉન્ટર વાપરો અથવા મંજૂર માર્ગ પર સાંકડું કેપ્ચર।

કેટલાક trace અને replay વિકલ્પો પેકેટ મોકલે છે અથવા સ્થિતિ જાળવે છે। દરેક પ્રકારને ફક્ત-વાંચન શોધ તરીકે ગણવાને બદલે તમારી આવૃત્તિ અને મંજૂર નિદાન પ્રક્રિયા માટેના દસ્તાવેજી વર્તનનું પાલન કરો।

ટ્રેસ હજુ પણ તમને શું કહી શકતું નથી

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

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