IKEv2 NO_PROPOSAL_CHOSEN: ਕਿਹੜੇ ਪੜਾਅ ਨੇ ਸੂਟ ਨੂੰ ਰੱਦ ਕੀਤਾ?

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

ਪਹਿਲਾਂ: ਕਿਹੜਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਰੱਦ ਹੋਇਆ

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

ਕੇਵਲ ਸੂਚਨਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਦੀ ਪਛਾਣ ਨਹੀਂ ਕਰਦੀ। ਇਸ ਦੇ ਉੱਪਰਲੀ ਲਾਈਨ ਗੱਲਬਾਤ ਹੋ ਰਹੇ SA ਦਾ ਨਾਂ ਦੱਸਦੀ ਹੈ, ਅਤੇ ਉਹ ਨਾਂ ਜਾਂਚਣ ਵਾਲੀ ਪ੍ਰਸਤਾਵ-ਸੂਚੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।

ਪੂਰੇ ਸੂਟਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਵੱਖਰੇ ਕੀਵਰਡਾਂ ਦੀ ਨਹੀਂ

ਪ੍ਰਸਤਾਵ ਇੱਕ ਸੰਯੋਜਨ ਹੈ: ਇਨਕ੍ਰਿਪਸ਼ਨ ਐਲਗੋਰਿਦਮ, ਇੰਟੀਗ੍ਰਿਟੀ ਜਾਂ AEAD, ਕੁੰਜੀ-ਬਦਲੀ ਸਮੂਹ, ਅਤੇ ਕੋਈ ਵੀ ਸਿਊਡੋ-ਰੈਂਡਮ ਫੰਕਸ਼ਨ। ਕੇਵਲ ਇਨਕ੍ਰਿਪਸ਼ਨ ਦਾ ਨਾਂ ਤੁਲਨਾ ਕਰਨਾ ਆਮ ਗਲਤੀ ਹੈ, ਕਿਉਂਕਿ ਦੋ ਸਾਥੀ AES-256 'ਤੇ ਸਹਿਮਤ ਹੋ ਕੇ ਵੀ SHA-1 ਅਤੇ SHA-256 'ਤੇ ਅਸਹਿਮਤ ਰਹਿ ਸਕਦੇ ਹਨ। ਅਸਫਲ ਪੜਾਅ 'ਤੇ ਪ੍ਰਸਤਾਵਿਤ ਅਤੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਸੂਟ ਨਾਲ-ਨਾਲ ਲਿਖੋ, ਫਿਰ ਖਾਲੀ ਕਟੌਤੀ ਲੱਭੋ।

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

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

IKE ਸੂਟ ਅਤੇ ESP ਸੂਟ ਵੱਖਰੀਆਂ ਵਸਤੂਆਂ ਹਨ

IKE ਪ੍ਰਸਤਾਵ ਸੰਪਾਦਿਤ ਕਰਨ ਨਾਲ ਰੱਦ ਹੋਇਆ CHILD ਪ੍ਰਸਤਾਵ ਠੀਕ ਨਹੀਂ ਹੋਵੇਗਾ, ਅਤੇ ਉਲਟਾ ਵੀ ਸੱਚ ਹੈ। strongSwan ਵਿੱਚ ਇਹ ਵੱਖਰੀਆਂ ਸੈਟਿੰਗਾਂ ਹਨ, ਲਗਭਗ IKE SA ਲਈ proposals = aes256-sha256-modp2048 ਅਤੇ CHILD SA ਲਈ ਵੱਖਰੀ ESP ਸੂਚੀ। ਅਸਫਲ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਸੂਚੀ ਬਦਲੋ, ਫਿਰ ਸੁਧਾਰ ਕੰਮ ਕਰ ਗਿਆ ਮੰਨ ਕੇ ਨਹੀਂ, ਲੌਗ ਦੁਬਾਰਾ ਪੜ੍ਹੋ।

CHILD SA ਲਈ ਸੰਬੰਧਿਤ ਸੈਟਿੰਗ ESP ਪ੍ਰਸਤਾਵ-ਸੂਚੀ ਹੈ, IKE ਸੂਚੀ ਨਹੀਂ। ਇਸ ਵਿੱਚ IKE ਲਾਈਨ ਕਾਪੀ ਕਰਨ ਨਾਲ ਅਜਿਹੀ ਸੰਰਚਨਾ ਬਣਦੀ ਹੈ ਜੋ ਪਾਰਸ ਹੁੰਦੀ ਹੈ ਪਰ ਗਲਤ ਵਸਤੂ 'ਤੇ ਗੱਲਬਾਤ ਕਰਦੀ ਹੈ।

ਕੰਮ ਕਰਦਾ ਟਨਲ ਜੋ ਕੁੰਜੀ-ਨਵੀਨੀਕਰਨ 'ਤੇ ਅਸਫਲ ਹੁੰਦਾ ਹੈ

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

ipsec statusall ਹਰੇਕ ਸੰਗਠਨ ਅਤੇ ਅਸਲ ਵਿੱਚ ਸਹਿਮਤ ਐਲਗੋਰਿਦਮ ਦਿਖਾਉਂਦਾ ਹੈ। ਉਹ ਆਉਟਪੁੱਟ ਕਿਹੜੀ ਸੂਚੀ ਵਰਤੀ ਗਈ ਇਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ, ਅਤੇ ਇਹ ਸੰਰਚਨਾ ਗਲਤੀ ਨੂੰ ਕਦੇ ਵੀ ਦੁਬਾਰਾ ਗੱਲਬਾਤ ਨਾ ਹੋਏ ਪੁਰਾਣੇ ਟਨਲ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ।

ipsec statusall | grep -E "IKE:|ESP:"

ਇੱਕ ਕਟੌਤੀ ਚੁਣੋ, ਫਿਰ ਦੋਵੇਂ ਪੜਾਅ ਪੁਸ਼ਟ ਕਰੋ

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

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