ASA ನಲ್ಲಿ failback: ಮಾರ್ಗವು ಮರಳಿ ಬಂದಾಗ ನಿಜವಾಗಿ ಏನು ಚಲಿಸುತ್ತದೆ
ಮಾರ್ಗವು ಪ್ರಾಥಮಿಕಕ್ಕೆ ಮರಳಿದರೂ ಹಳೆಯ ಹರಿವುಗಳು ಸರಿದಿವೆ ಎಂದಲ್ಲ. uplink, ಟನೆಲ್, ಸಂಪರ್ಕ ಕೋಷ್ಟಕ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಫಲಿತಾಂಶವನ್ನು ಒಟ್ಟಿಗೆ ನೋಡಿ.
ಎರಡು uplink ಇರುವ ASA ನಲ್ಲಿ failback ಎಂಬುದು failover ನ ತಿರುಗುಮುರುಗಲ್ಲ. peer ನ ಕಡೆಗಿನ ಮಾರ್ಗ ಬದಲಾಗುತ್ತದೆ, ನಂತರ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮೂರು ಪ್ರತ್ಯೇಕ ಸ್ಥಿತಿ ಯಂತ್ರಗಳನ್ನು ಹೊಂದಿಸಬೇಕು: ಮಾರ್ಗ ಕೋಷ್ಟಕ, IKE ಮತ್ತು IPsec ಭದ್ರತಾ ಸಹಯೋಗಗಳು, ಮತ್ತು ಸಂಪರ್ಕ ಕೋಷ್ಟಕ. ಪ್ರತಿಯೊಂದೂ ಇತರರಿಗಿಂತ ಹಿಂದೆ ಬೀಳಬಹುದು, ಮತ್ತು ಆ ವಿಳಂಬವನ್ನೇ ಹೆಚ್ಚಿನ ಜನರು ಮರಳಿ ಬಾರದ ಟನೆಲ್ ಎಂದು ವಿವರಿಸುತ್ತಾರೆ.
failback ನಿಜವಾಗಿ ಏನನ್ನು ಬದಲಿಸುತ್ತದೆ
ಮಾರ್ಗ ಹುಡುಕಾಟವು ಕಾಣುವ ಭಾಗ. ಟ್ರ್ಯಾಕ್ ಮಾಡಿದ ವಸ್ತು ಚೇತರಿಸಿಕೊಂಡಾಗ, peer ನ ಹೊರಗಿನ ವಿಳಾಸಕ್ಕೆ ಇರುವ ಟ್ರ್ಯಾಕ್ ಮಾಡಿದ ಮಾರ್ಗ ಮರಳುತ್ತದೆ, ಮತ್ತು 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 ಮತ್ತು 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 ಊಹಿಸುವ ಬದಲು ದಾಖಲೆಯನ್ನು ಬೆಂಬಲಕ್ಕೆ ಕಳುಹಿಸಿ.