Cloud VPN ਤੋਂ Cisco ASA: ਪ੍ਰਸਤਾਵ ਦੇ ਅੰਤਰ ਤੋਂ ਬਾਅਦ ਮੁੜ ਉਸਾਰੀ

Cloud VPN ਪ੍ਰਸਤਾਵ ਨੂੰ ਟਨਲ ਆਬਜੈਕਟ ਵਿੱਚ ਪਾ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ASA ਨਾਲ ਅੰਤਰ ਦਾ ਮਤਲਬ ਹੈ ਉਸਨੂੰ ਮੁੜ ਬਣਾਉਣਾ। ਸਿਲੈਕਟਰ ਲਿਖੋ, ਦੋਵੇਂ ਫੇਜ਼ ਮਿਲਾਓ, ਪੁਰਾਣੇ SA ਸਾਫ਼ ਕਰੋ।

ਦੂਜੇ ਸਿਰੇ 'ਤੇ Cisco ASA ਵਾਲੇ Cloud VPN ਟਨਲ 'ਤੇ NEGOTIATION_FAILURE ਲਗਭਗ ਹਮੇਸ਼ਾ ਪ੍ਰਸਤਾਵ ਜਾਂ ਸਿਲੈਕਟਰ ਦਾ ਅੰਤਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਪਹਿਲੀ ਕੰਮ ਦੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਕੋਈ ਸੰਪਾਦਨ ਇਸਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰੇਗਾ। Cloud VPN ਟਨਲ ਆਬਜੈਕਟ ਬਣਦੇ ਸਮੇਂ IKE ਪ੍ਰਸਤਾਵ ਤੈਅ ਕਰ ਦਿੰਦਾ ਹੈ। ਜਗ੍ਹਾ 'ਤੇ ਐਲਗੋਰਿਦਮ ਬਦਲਣ ਲਈ ਕੋਈ ਫੀਲਡ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਮੁਰੰਮਤ ਦਾ ਮਤਲਬ ਹੈ ਮਿਟਾਉਣਾ ਅਤੇ ਦਰਜ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਨਾਲ ਮੁੜ ਬਣਾਉਣਾ। ਇਸਨੂੰ ਮੁੜ ਉਸਾਰੀ ਮੰਨੋ, ਫਿਰ ਕੰਮ ਅੰਦਾਜ਼ਿਆਂ ਭਰੀ ਦੁਪਹਿਰ ਦੀ ਥਾਂ ਇੱਕ ਚੈੱਕਲਿਸਟ ਬਣ ਜਾਂਦਾ ਹੈ।

ਕੁਝ ਵੀ ਮਿਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸਫਲਤਾ ਪੜ੍ਹੋ

ਗੱਲਬਾਤ ਦੀ ਅਸਫਲਤਾ ਇੱਕ ਫੇਜ਼ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਪੀਅਰ ਲਾਗ ਆਮ ਤੌਰ 'ਤੇ ਫੇਜ਼ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ। ਫੇਜ਼ 1 ਅਸਫਲ ਹੋਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਦੋਵੇਂ ਸਿਰੇ ਪ੍ਰਸਤਾਵ 'ਤੇ ਸਹਿਮਤ ਨਹੀਂ ਹੋ ਸਕੇ ਜਾਂ ਇੱਕ ਦੂਜੇ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਕਰ ਸਕੇ। ਫੇਜ਼ 2 ਅਸਫਲ ਹੋਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਟਨਲ ਉੱਪਰ ਆਇਆ ਪਰ ਸੁਰੱਖਿਅਤ ਸਿਲੈਕਟਰ ਨਹੀਂ ਮਿਲੇ। ਇਹ ਵੱਖਰੀਆਂ ਮੁਰੰਮਤਾਂ ਹਨ, ਅਤੇ ਕਿਸੇ ਦੇ ਸੰਰਚਨਾ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਲਾਗ ਦੀ ਲਾਈਨ ਕੱਢ ਲੈਣੀ ਚਾਹੀਦੀ ਹੈ।

ਇਹ ਅਸਫਲਤਾ ਕੁਝ ਚੀਜ਼ਾਂ ਨੂੰ ਬਾਹਰ ਵੀ ਕਰ ਦਿੰਦੀ ਹੈ। ਇਹ VPC ਰੂਟ ਨਹੀਂ, ਟਨਲ ਇੰਟਰਫੇਸ 'ਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਨਹੀਂ, ਅਤੇ ਨੈੱਟਵਰਕ ਅੰਦਰ ਨਾਮ-ਹੱਲ ਦੀ ਖਰਾਬੀ ਨਹੀਂ। ਇਹਨਾਂ ਪਿੱਛੇ ਭੱਜਣ ਨਾਲ ਭਰੋਸੇਵਾਨ ਬਦਲਾਅ ਹੁੰਦੇ ਹਨ ਜੋ ਨਤੀਜਾ ਨਹੀਂ ਬਦਲ ਸਕਦੇ, ਅਤੇ ਅੰਤਿਮ ਸੁਧਾਰ ਨੂੰ ਕਿਸ ਦੇ ਨਾਮ ਲਿਖਣਾ ਹੈ ਇਹ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ।

ਦੋਵੇਂ ਸੰਰਚਨਾਵਾਂ ਅਜੇ ਮੌਜੂਦ ਹੋਣ ਤੱਕ ਲਿਖ ਲਵੋ

ਟਨਲ ਮਿਟਾਉਣ ਵਿੱਚ ਅੱਧਾ ਮਿੰਟ ਲੱਗਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ਼ ਸੀ ਇੱਕੋ ਸਬੂਤ ਨਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ। ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਸਥਾਨਕ ਅਤੇ ਦੂਰ ਦੇ ਸਿਲੈਕਟਰ, ਪੀਅਰ ਦਾ ਪਤਾ, ਸਾਂਝਾ ਭੇਤ ਕਿਸ ਕੋਲ਼ ਹੈ, ਅਤੇ ASA ਦਾ crypto map ਜਾਂ IKEv2 ਪਰੋਫਾਈਲ ਲਿਖ ਲਵੋ। ASA ਦੋ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕੀ ਸੰਰਚਿਤ ਹੈ ਅਤੇ ਇਸ ਵੇਲੇ ਕੀ ਉੱਪਰ ਹੈ:

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

Google ਵੱਲ ਕੰਸੋਲ ਸਾਰ ਦੀ ਥਾਂ ਟਨਲ ਆਬਜੈਕਟ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਪੀਅਰ ਦਾ ਪਤਾ ਅਤੇ ਸਿਲੈਕਟਰ ਫੀਲਡ ਹੀ ਉਹ ਮੁੱਲ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਬਿਲਕੁਲ ਦੁਹਰਾਉਣੇ ਹਨ:

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

ਉਹ ਮੁੱਲ ਪਹਿਲੀ ਵਾਰ ਮਿਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਟਿਕਟ ਵਿੱਚ ਪਾਓ। ਹੇਠਾਂ ਦਿੱਤੀ ਮੁੜ ਉਸਾਰੀ ਸਿਰਫ਼ ਇਸ ਲਈ ਕੰਮ ਕਰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਉਹੀ ਆਬਜੈਕਟ ਇੱਕ ਜਾਣ-ਬੁੱਝ ਕੇ ਕੀਤੇ ਅੰਤਰ ਨਾਲ ਮੁੜ ਬਣਾ ਸਕਦੇ ਹੋ।

ਜਿਨ੍ਹਾਂ ਐਲਗੋਰਿਦਮਾਂ 'ਤੇ ਇੱਕ ਪਾਸਾ ਗੱਲਬਾਤ ਨੂੰ ਨਾਂਹ ਕਹਿੰਦਾ ਹੈ

Cloud VPN ਰਵਾਇਤੀ ਪੀਅਰ ਵਾਂਗ IKEv1 ਐਲਗੋਰਿਦਮਾਂ ਦੀ ਸ਼੍ਰੇਣੀ ਵਿੱਚੋਂ ਨਹੀਂ ਚੁਣਦਾ। ਇਹ ਜਿਨ੍ਹਾਂ ਪੀਅਰ ਸੈਟਿੰਗਾਂ ਦੀ ਆਸ ਰੱਖਦਾ ਹੈ ਉਹ ਸਥਿਰ ਹਨ: ਐਨਕ੍ਰਿਪਸ਼ਨ ਲਈ aes-cbc-128, ਇੰਟੀਗ੍ਰਿਟੀ ਅਤੇ PRF ਦੋਵਾਂ ਲਈ sha1-96, Diffie-Hellman ਗਰੁੱਪ 2, ਫੇਜ਼ 1 ਲਈ 36,600 ਸਕਿੰਟ ਅਤੇ ਫੇਜ਼ 2 ਲਈ 10,800 ਸਕਿੰਟ। ASA ਨੀਤੀ ਨੂੰ ਬਿਲਕੁਲ ਇਹੀ ਸਮੂਹ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ASA 'ਤੇ ਦੂਜਾ ਪ੍ਰਸਤਾਵ ਨੁਕਸਾਨਦੇਹ ਨਹੀਂ, ਜੇ ਮਿਲਦਾ ਪ੍ਰਸਤਾਵ ਵੀ ਸੂਚੀ ਵਿੱਚ ਹੋਵੇ।

IKEv2 ਦੋਵੇਂ ਪਾਸਿਆਂ ਨੂੰ ਵੱਧ ਥਾਂ ਦਿੰਦਾ ਹੈ, ਪਰ ਨਿਯਮ ਉਹੀ ਆਕਾਰ ਰੱਖਦੇ ਹਨ: PFS ਚਾਲੂ ਕਰੋ, ਉਹ DH ਗਰੁੱਪ ਚੁਣੋ ਜਿਸਨੂੰ ਟਨਲ ਸਹਾਇਤਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਪ੍ਰਸਤਾਵਾਂ ਦੀ ਸੂਚੀ ਨੂੰ ਐਨੀ ਛੋਟੀ ਰੱਖੋ ਕਿ ਅੰਤਰ ਸਪਸ਼ਟ ਹੋਵੇ। Cloud VPN 'ਤੇ ASA ਪੀਅਰ ਦਾ ਮਤਲਬ ਸਥਿਰ ਰੂਟਿੰਗ ਵੀ ਹੈ, ਇਸ ਲਈ ਸੁਰੱਖਿਅਤ ਪ੍ਰੀਫਿਕਸ BGP ਨੂੰ ਛੱਡਣ ਦੀ ਥਾਂ ਯੋਜਨਾ ਬਣਾ ਕੇ ਸੂਚੀਬੱਧ ਕਰਨੇ ਪੈਂਦੇ ਹਨ।

ਕਿਸੇ ਹੋਰ ਨਿਰਮਾਤਾ ਦੇ ਟੈਂਪਲੇਟ ਤੋਂ ਕਾਪੀ ਕੀਤੀ ਉਮਰ ਇੱਥੇ ਆਮ ਗਲਤ ਮੋੜ ਹੈ। Google ਇਹ ਮੁੱਲ ਲਾਜ਼ਮੀ ਪੀਅਰ ਸੈਟਿੰਗਾਂ ਵਜੋਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਇਹਨਾਂ ਨੂੰ ਸੈੱਟ ਕਰੋ; ਛੋਟਾ ਮੁੱਲ ASA ਜੋ ਚਾਹੁੰਦਾ ਹੈ ਉਸ ਤੱਕ ਉੱਪਰ ਗੱਲਬਾਤ ਨਹੀਂ ਹੁੰਦਾ।

ਮਿਟਾਓ, ਮੁੜ ਬਣਾਓ ਅਤੇ ਪੁਰਾਣੀ ਸਥਿਤੀ ਸਾਫ਼ ਕਰੋ

ਗੇਟਵੇ ਨਹੀਂ, ਟਨਲ ਮਿਟਾਓ, ਅਤੇ Cloud VPN ਬਦਲ ਨੂੰ ਜੋ ਨਾਮ ਦਿੰਦਾ ਹੈ ਉਹ ਲਿਖ ਲਵੋ, ਕਿਉਂਕਿ ਨਾਮ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ, ਦੁਬਾਰਾ ਵਰਤੇ ਨਹੀਂ ਜਾਂਦੇ। ਦਰਜ ਕੀਤੇ ਮੁੱਲਾਂ ਅਤੇ ਉਸੇ ਪੀਅਰ ਪਤੇ ਨਾਲ ਇਸਨੂੰ ਮੁੜ ਬਣਾਓ, ਫਿਰ ਮਿਲਦਾ ਪ੍ਰਸਤਾਵ ASA ਨੀਤੀ ਸੂਚੀ ਵਿੱਚ ਜੋੜੋ।

ASA ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਅਤੇ ਨਤੀਜਾ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੱਖਿਆ ਸਹਿਯੋਗ ਸਾਫ਼ ਕਰੋ। ਮੌਜੂਦਾ SA ਖ਼ਤਮ ਹੋਣ ਤੱਕ ASA ਪੁਰਾਣੀ ਨੀਤੀ ਦਿੰਦਾ ਰਹਿ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਸਹੀ ਸੰਰਚਨਾ ਪੁਰਾਣੀ ਉਮਰ ਭਰ ਟੁੱਟੀ ਦਿਖਦੀ ਹੈ ਅਤੇ ਨਿਰੀਖਕ ਇਹ ਸਿੱਟਾ ਕੱਢਦਾ ਹੈ ਕਿ ਮੁੜ ਉਸਾਰੀ ਅਸਫਲ ਹੋਈ, ਜਦੋਂ ਕਿ ਉਹ ਸ਼ੁਰੂ ਵੀ ਨਹੀਂ ਹੋਈ ਸੀ:

clear crypto ikev2 sa
clear crypto ipsec sa

ਫੇਜ਼ 2 ਵੱਲ ਵੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪੱਕਾ ਕਰੋ ਕਿ ਫੇਜ਼ 1 ਉੱਪਰ ਆਉਂਦਾ ਹੈ। ਜਦੋਂ ਫੇਜ਼ 1 ਹੇਠਾਂ ਹੈ ਤਾਂ ਪ੍ਰਸਤਾਵ ਜਾਂ ਪਹਿਲਾਂ-ਸਾਂਝੀ ਕੁੰਜੀ ਗਲਤ ਹੈ, ਅਤੇ ਸਿਲੈਕਟਰ ਦਾ ਕੰਮ ਇਸਨੂੰ ਨਹੀਂ ਬਦਲੇਗਾ।

ਸਿਲੈਕਟਰ ਸ਼ੀਸ਼ੇ ਵਾਂਗ ਮਿਲਦੇ ਹਨ, ਫਿਰ ਗਿਣਤੀਆਂ ਫੈਸਲਾ ਦਿੰਦੀਆਂ ਹਨ

ਫੇਜ਼ 2 ਸਿਰਫ਼ ਤਦ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਦੋਵੇਂ ਸਿਰੇ ਸੁਰੱਖਿਅਤ ਪਤਿਆਂ 'ਤੇ ਸਹਿਮਤ ਹੋਣ, ਅਤੇ ਇਹ ਸਹਿਮਤੀ ਸਾਂਝੀ ਨਹੀਂ ਸਗੋਂ ਸ਼ੀਸ਼ੇ ਵਰਗੀ ਹੁੰਦੀ ਹੈ। Google ਦਾ ਸਥਾਨਕ ਸਿਲੈਕਟਰ ਉਸ ਸਿਲੈਕਟਰ ਨਾਲ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸਨੂੰ ASA ਦੂਰ ਕਹਿੰਦਾ ਹੈ, ਅਤੇ Google ਦਾ ਦੂਰ ਦਾ ਸਿਲੈਕਟਰ ਉਸ ਨਾਲ ਜਿਸਨੂੰ ASA ਸਥਾਨਕ ਕਹਿੰਦਾ ਹੈ। ਇੱਕ ਪਾਸੇ 0.0.0.0/0 ਅਤੇ ਦੂਜੇ ਪਾਸੇ ਇੱਕੋ ਸਬਨੈੱਟ ਵਾਲਾ ਟਨਲ ਫੇਜ਼ 1 ਪਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਉਸੇ ਮੁੱਖ ਗਲਤੀ ਨਾਲ ਫੇਜ਼ 2 ਵਿੱਚ ਅਸਫਲ ਹੁੰਦਾ ਹੈ। ਕੋਈ ਵੀ ਪਾਸਾ ਦੂਜੇ ਦੀ ਸੂਚੀ ਚੌੜੀ ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਨੀਤੀ-ਆਧਾਰਿਤ ਸਿਲੈਕਟਰਾਂ ਲਈ ਹਰ ਪ੍ਰੀਫਿਕਸ ਜੋੜੀ ਸੂਚੀਬੱਧ ਕਰੋ ਅਤੇ ਸੂਚੀ ਟਿਕਟ ਵਿੱਚ ਰੱਖੋ। ਬਾਅਦ ਵਿੱਚ ਸਾਈਟ 'ਤੇ ਜੋੜਿਆ ਸਬਨੈੱਟ ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ ਸੰਪਾਦਨ ਮੰਗਦਾ ਹੈ, ਕਿਉਂਕਿ ASA 'ਤੇ ਨਵਾਂ ਰੂਟ ਕਿਸੇ ਸਿਲੈਕਟਰ ਨੂੰ ਚੌੜਾ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਨਤੀਜਾ ਇੱਕ ਟਨਲ ਹੁੰਦਾ ਹੈ ਜੋ ਉੱਪਰ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਪਹਿਲੇ ਦਿਨ ਮੌਜੂਦ ਪ੍ਰੀਫਿਕਸਾਂ ਲਈ ਟ੍ਰੈਫਿਕ ਲੰਘਾਉਂਦਾ ਹੈ।

ਇੱਕ ਹੋਸਟ-ਤੋਂ-ਹੋਸਟ ਪ੍ਰਵਾਹ ਨਾਲ ਖ਼ਤਮ ਕਰੋ ਅਤੇ ਦੋਵੇਂ ਪਾਸਿਆਂ 'ਤੇ ਬਾਈਟ ਗਿਣਤੀਆਂ ਪੜ੍ਹੋ। ASA 'ਤੇ ਵੱਧਦੀਆਂ ਪਰ Google 'ਤੇ ਸਥਿਰ ਰਹਿਣ ਵਾਲੀਆਂ ਗਿਣਤੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਜਵਾਬ ਕਿਸੇ ਹੋਰ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਨਿਕਲਦਾ ਹੈ, ਜਾਂ ਸਿਲੈਕਟਰ ਵਾਪਸੀ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਨਹੀਂ ਢਕਦਾ। ਐਲਗੋਰਿਦਮ, ਉਮਰ, ਸਿਲੈਕਟਰ ਅਤੇ ਨਵੇਂ ਟਨਲ ਦਾ ਨਾਮ ਲਿਖੋ, ਕਿਉਂਕਿ ਅਗਲਾ ਪ੍ਰਸਤਾਵ ਬਦਲਾਅ ਇਹੀ ਮੁੜ ਉਸਾਰੀ ਦੁਹਰਾਉਂਦਾ ਹੈ ਅਤੇ ਉਹ ਮੁੱਲ ਇਸਨੂੰ ਛੋਟਾ ਕੰਮ ਬਣਾ ਦਿੰਦੇ ਹਨ।

ਸੰਬੰਧਿਤ ਲੇਖ