ASA માં failback: રૂટ પાછો આવે ત્યારે ખરેખર શું ખસે છે
રૂટ પ્રાઇમરી પર પાછો આવવો એટલે જૂના ફ્લો ખસી ગયા એમ નહીં. અપલિંક, ટનલ, કનેક્શન ટેબલ અને એપનું પરિણામ સાથે જુઓ.
બે અપલિંક ધરાવતા ASA પર, failback એ failoverની ઊલટી પ્રક્રિયા નથી. પીઅર તરફનો રૂટ બદલાય છે, અને પછી પ્લેટફોર્મે ત્રણ અલગ સ્ટેટ મશીન સાથે સુસંગતતા લાવવી પડે છે: રૂટ ટેબલ, IKE અને IPsec સિક્યોરિટી એસોસિએશન, અને કનેક્શન ટેબલ. દરેક બીજા કરતાં પાછળ રહી શકે છે, અને એ જ વિલંબને મોટા ભાગના લોકો એવી ટનલ કહે છે જે પાછી આવતી નથી.
failback ખરેખર શું બદલે છે
રૂટ લુકઅપ દેખાતો ભાગ છે. જ્યારે ટ્રેક કરેલ ઑબ્જેક્ટ સુધરે છે, ત્યારે પીઅરના બહારના સરનામા તરફનો ટ્રેક કરેલ રૂટ પાછો આવે છે, અને ASA મોકલે છે તે આગળનું પેકેટ ફરી પ્રાઇમરી લિંક પર જાય છે. તે પછીનું બધું એના પર આધાર રાખે છે કે હાલની સ્થિતિ નવા માર્ગ સાથે મેળ ખાય છે કે નહીં.
ARP અને NAT એ શાંત આધારો છે. નવા next hop માટે ઉકેલી શકાય એવું ગેટવે અને એવું ટ્રાન્સલેશન જોઈએ જે હજી દૂરના છેડા સાથે મેળ ખાય, નહીં તો failback પછીના પહેલા પેકેટ ક્યાંય જતા નથી અને કંઈ કામ ન કરતું હોવા છતાં રૂટ ઠીક દેખાય છે.
એક જ સમયરેખા પર ચાર દૃશ્યો
એ જ ચાર વસ્તુઓ સંક્રમણ પહેલાં, દરમિયાન અને પછી નોંધો, કારણ કે એક સ્નેપશોટ તમને કહી શકતું નથી કે કયો સ્તર ખસ્યો.
| View | What to record |
|---|---|
| Uplink and route | Interface state, the tracked object result, the route selected for the outer peer address |
| IKE and IPsec | The live peer, IKE version, security associations, protected-traffic counters |
| Connection table | Interface and endpoint pair for old flows and for flows created after the change |
| Application | One pre-existing operation and one fresh request, each marked success, reset, stall or recovered |
જે રૂટ કદી ન બદલાયો અને જે રૂટ બદલાયો જ્યારે જૂના કનેક્શને તેની ફોર્વર્ડિંગ સ્થિતિ જાળવી રાખી, બંને એક જ ફરિયાદ અને સાવ અલગ પુરાવા આપે છે.
જૂના કનેક્શન બેકઅપ માર્ગ પર કેમ રહે છે
રૂટ બદલાયો એટલે ASA ફ્લો તોડી નાખતું નથી. સ્થપાયેલા કનેક્શન જે ફોર્વર્ડિંગ નિર્ણય સાથે બન્યા તે જાળવી રાખે છે, અને પ્લેટફોર્મ તે કેટલો સમય માન્ય છે તે માટે અલગ નિયંત્રણો આપે છે: floating-connection timeout અને connection holddown. Ciscoની ASA 9.24 કનેક્શન સેટિંગ્સ માર્ગદર્શિકા એમને અલગ પ્રશ્નો તરીકે ગણે છે, અને તેમનું વર્તન બરાબર એવું જ છે. એક હાલના ફ્લોની ટકાઉપણું સંભાળે છે; બીજું એ કે નવા ફ્લો ક્યારે પસંદગીના માર્ગનો ઉપયોગ કરી શકે.
બંનેમાંથી કોઈ પણ બદલતા પહેલાં તમારી આવૃત્તિ માટેના અમલી મૂલ્યો વાંચો. એમને ઘટાડવાથી એ સેશન બંધ થાય છે જે લોકો હજી વાપરે છે. એમને વધારવાથી failback એવું લાગે છે કે જાણે કદી થયું જ નહીં, કારણ કે નવા કનેક્શન આખો સમય જૂનો માર્ગ લેતા રહે છે.
રૂટ પાછો આવ્યો એટલે ટનલ ફરીથી કી બનાવતું નથી
IPsec સિક્યોરિટી એસોસિએશન પોતાનું વાટાઘાટ કરેલું આયુષ્ય ધરાવે છે અને જે રૂટ ફેરફાર તેમને લઈ ગયો તેમાંથી પણ બચી જાય છે. તેથી ટનલ failback દરમિયાન ઉપર રહી શકે છે જ્યારે તેનું બહારનું સરનામું હવે વપરાતા માર્ગ સાથે મેળ ખાતું નથી; આ DPD અને પીઅરનું સરનામું તરતું છોડવાને બદલે સ્થિર રાખતી ડિઝાઇનની દલીલ છે.
crypto-map અને VTI ડિઝાઇન અહીં અલગ રીતે વર્તે છે, અને Ciscoનું 9.24 VTI દસ્તાવેજીકરણ રૂટ-આધારિત વિકલ્પ વર્ણવે છે. ASA રૂટ-આધારિત VPN ચલાવી શકતું નથી એ જૂનું સામાન્ય વિધાન સમર્થિત આવૃત્તિઓ માટે લાગુ પડતું નથી.
પુરાવા આ ક્રમમાં વાંચો
કંટ્રોલ પ્લેનથી શરૂ કરો: પસંદ કરેલા માર્ગ માટે show route, લિંક સ્થિતિ માટે show interface, અને ટ્રેક કરેલ ઑબ્જેક્ટ માટે SLA મોનિટરના કાઉન્ટર. પછી show crypto ikev2 sa, અથવા IKEv1 સમકક્ષ, વાંચો કે કયો પીઅર જીવંત છે, ત્યારબાદ સુરક્ષિત ફ્લો માટે show crypto ipsec sa. પછી show conn address <host> વડે કનેક્શન ટેબલ સાંકડું કરો અને જૂની અને નવી એન્ટ્રીમાં ઇન્ટરફેસ કોલમ સરખાવો. આઉટપુટ સમય-છાપ સાથે લખો, કારણ કે તેમનો ક્રમ જ નિદાન છે.
એપ્લિકેશન પરીક્ષણથી પૂરું કરો: એક ફ્લો જે પહેલેથી હતો, અને એક જે રૂટ પાછો આવ્યા પછી બન્યો. જૂનો ફ્લો નિષ્ફળ જાય અને નવો કામ કરે, તો તમારી પાસે કનેક્શન-સ્થિતિની વાર્તા છે. બંને નિષ્ફળ જાય, તો ટનલ કે પોલિસી ખોટી છે અને કનેક્શન ટેબલ ધ્યાન ભટકાવનારું છે.
તે રેકોર્ડ ત્રણેય તબક્કામાં એક જ આકારમાં રાખો અને સચોટ આવૃત્તિ નોંધો. જ્યારે સમયરેખા વારંવાર એક જ સંક્રમણ તરફ ઇશારો કરે, ત્યારે બગ ID અનુમાન કરવાને બદલે રેકોર્ડ સપોર્ટને મોકલો.