இரண்டு uplink கொண்ட ASA-வில் failback என்பது failover-இன் எதிர்மாறு அல்ல. peer-க்கான பாதை மாறுகிறது, பின்னர் தளம் மூன்று தனித்தனி நிலை இயந்திரங்களை ஒருங்கிணைக்க வேண்டும்: பாதை அட்டவணை, IKE மற்றும் IPsec பாதுகாப்பு இணைப்புகள், இணைப்பு அட்டவணை. ஒவ்வொன்றும் மற்றவற்றை விடப் பின்தங்கலாம், அந்தத் தாமதத்தையே பெரும்பாலானோர் திரும்பி வராத டன்னல் என்கின்றனர்.

failback உண்மையில் என்ன மாற்றுகிறது

பாதைத் தேடல் தெரியும் பகுதி. கண்காணிக்கப்படும் பொருள் மீளும்போது peer-இன் வெளிப்புற முகவரிக்கான கண்காணிப்புப் பாதை திரும்பி வருகிறது, ASA அனுப்பும் அடுத்த பொதி மீண்டும் முதன்மை இணைப்பைப் பின்பற்றுகிறது. அதற்குப் பிறகு அனைத்தும் இருக்கும் நிலை புதிய வழியுடன் ஒத்துப்போகிறதா என்பதைப் பொறுத்தது.

ARP மற்றும் NAT அமைதியான சார்புகள். புதிய next hop-க்கு தீர்க்கக்கூடிய நுழைவாயில் மற்றும் தொலை முனையுடன் இன்னும் பொருந்தும் மொழிபெயர்ப்பு தேவை, இல்லையெனில் failback-க்குப் பின் முதல் பொதிகள் எங்கும் போகாது, எதுவும் வேலை செய்யாதபோது பாதை சரியாகத் தெரியும்.

ஒரே காலக்கோட்டில் நான்கு பார்வைகள்

மாற்றத்திற்கு முன், இடையில், பின் அதே நான்கு விஷயங்களைப் பதிவு செய்யுங்கள், ஏனெனில் ஒரு படம் எந்த அடுக்கு நகர்ந்தது என்று சொல்ல முடியாது.

ViewWhat to record
Uplink and routeInterface state, the tracked object result, the route selected for the outer peer address
IKE and IPsecThe live peer, IKE version, security associations, protected-traffic counters
Connection tableInterface and endpoint pair for old flows and for flows created after the change
ApplicationOne 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 மற்றும் peer முகவரியை மிதக்கவிடாமல் நிலைநிறுத்தும் வடிவமைப்புகளுக்கான வாதம்.

crypto-map மற்றும் VTI வடிவமைப்புகள் இங்கே வேறுவிதமாக நடந்துகொள்கின்றன, மேலும் Cisco-வின் 9.24 VTI ஆவணம் பாதை அடிப்படையிலான விருப்பத்தை விவரிக்கிறது. ASA பாதை அடிப்படையிலான VPN-களை இயக்க முடியாது என்ற பழைய பொதுக் கூற்று ஆதரவு பெற்ற வெளியீடுகளுக்குப் பொருந்தாது.

சான்றுகளை இந்த வரிசையில் படிக்கவும்

கட்டுப்பாட்டுத் தளத்தில் தொடங்குங்கள்: தேர்ந்தெடுத்த பாதைக்கு show route, இணைப்பு நிலைக்கு show interface, கண்காணிக்கப்படும் பொருளுக்கு SLA கண்காணிப்பியின் எண்ணிகள். பிறகு எந்த peer உயிருடன் உள்ளது எனப் பார்க்க show crypto ikev2 sa, அல்லது IKEv1-இன் சமமானதைப் படியுங்கள், தொடர்ந்து பாதுகாக்கப்பட்ட ஓட்டங்களுக்கு show crypto ipsec sa. பின்னர் show conn address <host> மூலம் இணைப்பு அட்டவணையைச் சுருக்கி பழைய மற்றும் புதிய பதிவுகளில் இடைமுக நிரலை ஒப்பிடுங்கள். வெளியீடுகளை நேர முத்திரைகளுடன் எழுதுங்கள், ஏனெனில் அவற்றின் வரிசையே கண்டறிதல்.

பயன்பாட்டுச் சோதனையுடன் முடியுங்கள்: ஏற்கனவே இருந்த ஒரு ஓட்டம் மற்றும் பாதை திரும்பிய பின் உருவாக்கப்பட்ட இன்னொன்று. பழைய ஓட்டம் தோல்வியடைந்து புதியது வேலை செய்தால், உங்களிடம் இணைப்பு நிலையின் கதை உள்ளது. இரண்டும் தோல்வியடைந்தால் டன்னல் அல்லது கொள்கை தவறு, இணைப்பு அட்டவணை கவனத்தைத் திசைதிருப்புவது.

அந்தப் பதிவை மூன்று கட்டங்களிலும் ஒரே வடிவில் வைத்து துல்லியமான வெளியீட்டைக் குறிப்பிடுங்கள். காலக்கோடு ஒரே மாற்றத்தைத் தொடர்ந்து சுட்டிக்காட்டினால், பிழை ID-ஐ ஊகிப்பதற்குப் பதிலாகப் பதிவை ஆதரவுக்கு அனுப்புங்கள்.

தொடர்புடைய கட்டுரைகள்