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 ਮਾਨੀਟਰ ਦੇ ਕਾਊਂਟਰ। ਫਿਰ show crypto ikev2 sa, ਜਾਂ IKEv1 ਦੇ ਬਰਾਬਰ, ਪੜ੍ਹੋ ਕਿ ਕਿਹੜਾ peer ਜੀਵਤ ਹੈ, ਉਸ ਤੋਂ ਬਾਅਦ ਸੁਰੱਖਿਅਤ ਫਲੋ ਲਈ show crypto ipsec sa। ਫਿਰ show conn address <host> ਨਾਲ ਕਨੈਕਸ਼ਨ ਟੇਬਲ ਸੰਕੁਚਿਤ ਕਰੋ ਅਤੇ ਪੁਰਾਣੀਆਂ ਤੇ ਨਵੀਆਂ ਐਂਟਰੀਆਂ ਵਿੱਚ ਇੰਟਰਫੇਸ ਕਾਲਮ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਆਉਟਪੁੱਟ ਸਮਾਂ-ਛਾਪ ਨਾਲ ਲਿਖੋ, ਕਿਉਂਕਿ ਉਹਨਾਂ ਦਾ ਕ੍ਰਮ ਹੀ ਨਿਦਾਨ ਹੈ।
ਐਪਲੀਕੇਸ਼ਨ ਟੈਸਟ ਨਾਲ ਮੁਕੰਮਲ ਕਰੋ: ਇੱਕ ਫਲੋ ਜੋ ਪਹਿਲਾਂ ਹੀ ਸੀ ਅਤੇ ਇੱਕ ਜੋ ਰੂਟ ਵਾਪਸ ਆਉਣ ਤੋਂ ਬਾਅਦ ਬਣਿਆ। ਜੇ ਪੁਰਾਣਾ ਫਲੋ ਫੇਲ ਹੋਵੇ ਅਤੇ ਨਵਾਂ ਕੰਮ ਕਰੇ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਕਨੈਕਸ਼ਨ-ਸਥਿਤੀ ਦੀ ਕਹਾਣੀ ਹੈ। ਜੇ ਦੋਵੇਂ ਫੇਲ ਹੋਣ, ਤਾਂ ਟਨਲ ਜਾਂ ਨੀਤੀ ਗਲਤ ਹੈ ਅਤੇ ਕਨੈਕਸ਼ਨ ਟੇਬਲ ਧਿਆਨ ਭਟਕਾਉਣ ਵਾਲੀ ਚੀਜ਼ ਹੈ।
ਉਹ ਰਿਕਾਰਡ ਤਿੰਨੇ ਪੜਾਵਾਂ ਵਿੱਚ ਇੱਕੋ ਆਕਾਰ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਸਹੀ ਰਿਲੀਜ਼ ਲਿਖੋ। ਜਦੋਂ ਸਮਾਂ-ਰੇਖਾ ਲਗਾਤਾਰ ਇੱਕੋ ਤਬਦੀਲੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੇ, ਤਾਂ ਬਗ ID ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਬਜਾਏ ਰਿਕਾਰਡ ਸਪੋਰਟ ਨੂੰ ਭੇਜੋ।