IKE ਵਿੱਚ MAC ਦਾ ਮੇਲ ਨਾ ਹੋਣਾ ਭਾਵ ਸਾਂਝੀ ਕੁੰਜੀ ਦੀ ਜਾਂਚ ਫੇਲ੍ਹ ਹੋਈ

ਤੁਹਾਡੇ Cloud VPN ਲੌਗ ਵਿੱਚ ਸਾਂਝੀ ਕੁੰਜੀ ਦੀ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਬਾਅਦ MAC ਦੇ ਮੇਲ ਨਾ ਹੋਣ ਦਾ ਸੁਨੇਹਾ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਪਹਿਲੀ ਸੋਚ ਅਕਸਰ ਪਤੇ ਦੀ ਸਮੱਸਿਆ ਲੱਭਣਾ ਹੁੰਦੀ ਹੈ। ਇਸ ਸ਼ਾਖਾ ਵਿੱਚ MAC ਇੱਕ ਸੁਨੇਹਾ ਪ੍ਰਮਾਣਿਕਤਾ ਕੋਡ ਹੈ: ਤਹਿ ਕੀਤੀ ਕੁੰਜੀ ਨਾਲ ਹੋਈ ਅਦਲ-ਬਦਲ ਉੱਤੇ ਗਿਣਿਆ ਗਿਆ ਮੁੱਲ। ਸਾਥੀ ਨੇ ਆਪਣੀ ਗਿਣਤੀ ਦੀ ਤੁਲਨਾ ਪ੍ਰਾਪਤ ਮੁੱਲ ਨਾਲ ਕੀਤੀ, ਅਤੇ ਦੋਵੇਂ ਵੱਖਰੇ ਸਨ। ਇਸ ਵਿੱਚ ਕੋਈ ਨੈੱਟਵਰਕ ਕਾਰਡ ਸ਼ਾਮਲ ਨਹੀਂ, ਅਤੇ ਕੋਈ ਇੰਟਰਫ਼ੇਸ ਸੈਟਿੰਗ ਉਸ ਤੁਲਨਾ ਨੂੰ ਨਹੀਂ ਬਦਲਦੀ।

ਵਿਵਹਾਰ ਵਿੱਚ ਇਹ ਦੋ ਹਾਲਤਾਂ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ: ਦੋਵੇਂ ਸਿਰਿਆਂ ਦੇ ਭੇਤ ਇੱਕੋ ਮੁੱਲ ਨਹੀਂ, ਜਾਂ ਭੇਤ ਚੁਣਨ ਲਈ ਵਰਤੀਆਂ ਪਛਾਣਾਂ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀਆਂ। ਕਿਹੜੀ ਹੈ, ਇਹ ਇੱਕ ਟਨਲ ਨਹੀਂ, ਦੋਵੇਂ ਸਿਰੇ ਪੜ੍ਹ ਕੇ ਤੈਅ ਕਰੋ।

ਇਹ ਪੜਾਅ ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ

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

ਪਹਿਲਾਂ ਦੀ ਸਫਲਤਾ ਇਸ ਜਾਂਚ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦੀ। ਪੂਰਾ ਹੋਇਆ IKE_SA_INIT, ਜਾਂ NAT ਖੋਜ ਪੇਲੋਡ ਜਿਸਨੇ ਉਮੀਦ ਕੀਤੇ ਮੁੱਲ ਵਾਪਸ ਕੀਤੇ, ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਸਾਥੀ ਗੱਲ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਸਾਬਤ ਕਰਦਾ ਕਿ ਉਹ ਭੇਤ ਸਾਂਝਾ ਕਰਦੇ ਹਨ ਜਾਂ ਨਹੀਂ।

ਦੋ ਸੰਰਚਨਾ ਗਲਤੀਆਂ, ਇੱਕ ਸੁਨੇਹਾ

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

ਕਿਸੇ ਵੀ ਭੇਤ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਸਿਰਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਟਨਲ, ਸਾਥੀ ਦਾ ਐਂਡਪੌਇੰਟ, ਸਮਾਂ ਵਿੰਡੋ ਅਤੇ ਦੂਰ ਦੀ ਸੰਰਚਨਾ ਮਿਲਾਓ, ਕਿਉਂਕਿ ਦੋ ਵਾਧੂ ਟਨਲਾਂ ਵਿੱਚ ਵੱਖਰੇ ਭੇਤ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਦੀ ਸਕਰੀਨ ਫੇਲ੍ਹ ਹੋਇਆ ਵਾਲੀ ਨਾ ਹੋਵੇ।

NAT ਖੋਜ ਇੱਕ ਵੱਖਰਾ ਪੜਾਅ ਹੈ

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

ਇੱਕ ਵਿਕਰੇਤਾ ਰਿਲੀਜ਼ ਬਾਰੇ ਪੁਰਾਣਾ ਬਿਆਨ ਮੌਜੂਦਾ ਡਿਪਲੌਇਮੈਂਟ ਵਿੱਚ ਨਾ ਲਿਆਓ। ਤੁਹਾਡੇ ਰਿਲੀਜ਼ ਵਿੱਚ NAT ਲੰਘਣ ਲਈ ਕੀ ਚਾਹੀਦਾ ਹੈ, ਉਹ ਉਸਦੇ ਆਪਣੇ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਹੈ, ਅਤੇ MAC ਦਾ ਮੇਲ ਨਾ ਹੋਣਾ ਵਾਕ ਇਸਦੇ ਹੱਕ ਜਾਂ ਵਿਰੁੱਧ ਸਬੂਤ ਨਹੀਂ।

ਸਕਰੀਨ ਨਹੀਂ, ਦੋਵੇਂ ਸਿਰਿਆਂ ਤੋਂ ਫੈਸਲਾ ਕਰੋ

ਭੇਤ ਲੁਕਾ ਕੇ ਦੋਵੇਂ ਸੰਰਚਨਾਵਾਂ ਨੂੰ ਨਾਲ-ਨਾਲ ਪੜ੍ਹੋ, ਫਿਰ ਤਿੰਨ ਸਵਾਲ ਪੁੱਛੋ। ਕੀ ਹਰ ਪਾਸੇ ਦੀ ਪਛਾਣ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜਿਸਦੀ ਦੂਜਾ ਪਾਸਾ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਅੱਖਰ ਦਰ ਅੱਖਰ? ਕੀ ਦੋਵੇਂ ਸਿਰੇ ਇੱਕੋ IKE ਵਰਜ਼ਨ ਅਤੇ ਇੱਕੋ ਪ੍ਰਮਾਣਿਕਤਾ ਢੰਗ ਵਰਤਦੇ ਹਨ? ਕੀ ਫੇਲ੍ਹ ਹੋ ਰਿਹਾ ਟਨਲ ਉਸ ਸੰਰਚਨਾ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਪੜ੍ਹ ਰਹੇ ਹੋ? ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਦਾ ਵੀ ਨਾਂਹ ਹੋਣਾ ਭੇਤ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਮੁਰੰਮਤ ਤੈਅ ਕਰ ਦਿੰਦਾ ਹੈ।

ਜੇ ਤਿੰਨੇ ਸਾਫ਼ ਹਨ, ਤਾਂ ਆਲੇ-ਦੁਆਲੇ ਸੋਧਣ ਦੀ ਥਾਂ ਪ੍ਰਵਾਨਿਤ ਵਰਕਫਲੋ ਰਾਹੀਂ ਭੇਤ ਬਦਲੋ।

ਸਾਥੀ ਦੇ ਪ੍ਰਮਾਣਿਕ ਹੋਣ ਤੋਂ ਬਾਅਦ

ਪ੍ਰਮਾਣਿਕਤਾ ਸਫਲ ਹੁੰਦੀ ਹੀ, ਅਗਲੀ ਫੇਲ੍ਹ ਸਤ੍ਹਾ ਚਾਈਲਡ ਸੁਰੱਖਿਆ ਸੰਗਠਨ ਹੈ: ਪ੍ਰਸਤਾਵ ਅਤੇ ਟ੍ਰੈਫ਼ਿਕ ਚੋਣਕਾਰ। ਪਹਿਲਾਂ ਹੀ ਮੰਨੇ ਗਏ ਭੇਤ ਨੂੰ ਘੁਮਾਉਣਾ ਚਾਈਲਡ ਦੀ ਫੇਲ੍ਹ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਰੁਕਾਵਟ ਨੂੰ ਲੰਮਾ ਕਰਦਾ ਹੈ। ਚਾਈਲਡ ਦੀ ਹਾਲਤ ਪੜ੍ਹੋ, ਫਿਰ ਦੋਵੇਂ ਪਾਸਿਆਂ ਦੇ ਚੋਣਕਾਰ ਅਤੇ ਸੁਰੱਖਿਅਤ ਰੇਂਜਾਂ ਪੜ੍ਹੋ, ਅਤੇ Cloud VPN ਸਮੱਸਿਆ ਹੱਲ ਦੀ ਸੇਧ ਨੂੰ ਅਸਲ ਫੇਲ੍ਹ ਹੋਏ ਪੜਾਅ ਨਾਲ ਮਿਲਾਓ।

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

ਕੀ ਨਤੀਜਾ ਨਾ ਕੱਢੋ

ਸੁਨੇਹੇ ਨੂੰ MAC ਪਤੇ ਬਦਲਣ ਦੀ ਮੰਗ ਨਾ ਸਮਝੋ, ਅਤੇ ਮਦਦ ਮੰਗਦਿਆਂ ਸਾਂਝਾ ਭੇਤ ਪ੍ਰਕਾਸ਼ਿਤ ਨਾ ਕਰੋ; ਕੁੰਜੀ ਵਾਲੇ ਹਿੱਸੇ ਵਿੱਚੋਂ ਕੁੰਜੀ ਹਟਾਉਣੀ ਚਾਹੀਦੀ ਹੈ, ਲੌਗ ਰੱਖਣਾ ਨਹੀਂ। ਰੂਟਿੰਗ ਦੀ ਗਲਤੀ ਵੀ ਨਾ ਮੰਨੋ, ਕਿਉਂਕਿ ਜਿਹੜੇ ਸਾਥੀ ਇੱਕ-ਦੂਜੇ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੇ ਉਹ ਕੋਈ ਪ੍ਰਮਾਣਿਕਤਾ ਤੁਲਨਾ ਨਹੀਂ ਬਣਾਉਂਦੇ। ਅਤੇ ਇੱਕ ਉਤਪਾਦ ਪਰਿਵਾਰ ਦੀ ਦਸਤਾਵੇਜ਼ੀ ਸੀਮਾ ਨੂੰ ਹਰ IPsec ਲਾਗੂਕਰਨ ਉੱਤੇ ਨਾ ਲਾਓ।

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