ਤੁਹਾਡਾ IPsec ਟਨਲ ਪਹਿਲੇ CHILD SA ਕੁੰਜੀ ਨਵੀਨੀਕਰਨ ਤੱਕ ਹੀ ਕਿਉਂ ਕੰਮ ਕਰਦਾ ਹੈ

ਟਨਲ ਉੱਪਰ ਆਈ, ping ਨੇ ਜਵਾਬ ਦਿੱਤਾ ਅਤੇ ਸਾਰਿਆਂ ਨੇ ਦਸਤਖਤ ਕੀਤੇ। ਚਾਰ ਘੰਟਿਆਂ ਬਾਅਦ ਸੈਸ਼ਨ ਡਿੱਗ ਜਾਂਦਾ ਹੈ, ਦੋਵੇਂ ਧਿਰਾਂ ਪ੍ਰਸਤਾਵ ਜਾਂ ਕੁੰਜੀ-ਅਦਲ-ਬਦਲ ਦੀ ਗਲਤੀ ਦਰਜ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਪਹਿਲਾ ਅੰਦਾਜ਼ਾ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਨੈੱਟਵਰਕ ’ਤੇ ਕੁਝ ਬਦਲਿਆ ਹੈ। ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ। ਜੋ ਟਨਲ ਟ੍ਰੈਫਿਕ ਢੋਂਦੀ ਹੈ, ਉਸਨੇ ਸਾਬਤ ਕੀਤਾ ਹੈ ਕਿ ਦੋਵੇਂ ਧਿਰਾਂ ਇਸ ਗੱਲ ’ਤੇ ਸਹਿਮਤ ਹਨ ਕਿ ਪ੍ਰਮਾਣਿਕਤਾ ਕਿਵੇਂ ਕਰਨੀ ਹੈ ਅਤੇ ਪਹਿਲੀ ਚਾਈਲਡ ਐਸੋਸੀਏਸ਼ਨ ਕਿਵੇਂ ਸੁਰੱਖਿਅਤ ਰੱਖਣੀ ਹੈ, ਅਤੇ ਇਸਨੇ ਉਸ ਕੁੰਜੀ-ਅਦਲ-ਬਦਲ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕੀਤਾ ਜੋ ਉਹ ਨਵੀਨੀਕਰਨ ਵੇਲੇ ਮੰਗਣਗੀਆਂ। ਅਸੰਗਤੀ ਉਨ੍ਹਾਂ ਦੋ ਘਟਨਾਵਾਂ ਵਿਚਕਾਰਲੇ ਫਾਸਲੇ ਵਿੱਚ ਬੈਠੀ ਹੈ।

ਜੁੜੇ ਹੋਣ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ PFS ਸੈਟਿੰਗਾਂ ਮਿਲਦੀਆਂ ਹਨ

IKEv2 ਨਾਲ, ਪਹਿਲੀ ਚਾਈਲਡ ਐਸੋਸੀਏਸ਼ਨ ਪ੍ਰਮਾਣਿਕਤਾ ਅਦਲ-ਬਦਲ ਦੌਰਾਨ ਬਣਦੀ ਹੈ, ਅਤੇ ਇਸਦੀਆਂ ਕੁੰਜੀਆਂ ਉਸ ਸਮੱਗਰੀ ਤੋਂ ਲਈਆਂ ਜਾਂਦੀਆਂ ਹਨ ਜੋ IKE ਐਸੋਸੀਏਸ਼ਨ ਪਹਿਲਾਂ ਹੀ ਪੈਦਾ ਕਰ ਚੁੱਕੀ ਹੈ। ਉਸ ਚਾਈਲਡ ਲਈ ਵੱਖਰੀ Diffie-Hellman ਅਦਲ-ਬਦਲ ਨਹੀਂ ਹੁੰਦੀ, ਇਸ ਲਈ ਨਵੀਨੀਕਰਨ ਵੇਲੇ ਇਸਦੀ ਮੰਗ ਕਰਨ ਵਾਲੀ ਨੀਤੀ ਉਠਾਉਣ ਵੇਲੇ ਨਹੀਂ ਪਰਖੀ ਜਾਂਦੀ।

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

ਪ੍ਰਸਤਾਵ ਸਟ੍ਰਿੰਗ ਵਿੱਚ ਅਸੰਗਤੀ ਕਿੱਥੇ ਲੁਕੀ ਹੋਈ ਹੈ

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

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

ਨਾਕਾਮੀ ਪੜ੍ਹੋ, ਤੁਹਾਡੇ ਵੱਲੋਂ ਸੋਧੀ ਫਾਈਲ ਨਹੀਂ

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

ਡਿਸਕ ’ਤੇ ਪਈ ਨਹੀਂ, ਚੱਲ ਰਹੀ ਕਨਫਿਗਰੇਸ਼ਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਸੰਭਾਲੀ ਪਰ ਲੋਡ ਨਾ ਹੋਈ ਫਾਈਲ, ਜਾਂ ਕਿਸੇ ਹੋਰ include ਤੋਂ ਮੁੜ ਪੜ੍ਹਿਆ ਕਨੈਕਸ਼ਨ, ਐਸੀ ਅਸੰਗਤੀ ਪੈਦਾ ਕਰੇਗਾ ਜੋ ਦਿਸਦੀ ਫਾਈਲ ਨੂੰ ਕਿੰਨਾ ਵੀ ਸੋਧਣ ਨਾਲ ਠੀਕ ਨਹੀਂ ਹੋਵੇਗਾ।

ਤਿੰਨ ਘਟਨਾਵਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਾਰੇ ਕੁੰਜੀ ਨਵੀਨੀਕਰਨ ਕਹਿੰਦੇ ਹਨ

IKE ਐਸੋਸੀਏਸ਼ਨ ਦੀ ਕੁੰਜੀ ਨਵੀਨੀਕਰਨ, IKE ਮੁੜ-ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਚਾਈਲਡ ਐਸੋਸੀਏਸ਼ਨ ਦੀ ਕੁੰਜੀ ਨਵੀਨੀਕਰਨ ਵੱਖਰੇ ਪ੍ਰਸਤਾਵ ਨਿਯਮਾਂ ਵਾਲੀਆਂ ਵੱਖਰੀਆਂ ਕਾਰਵਾਈਆਂ ਹਨ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਦਰਜ ਨਾਕਾਮੀ ਬਾਕੀਆਂ ਬਾਰੇ ਸਿੱਧਾ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ, ਅਤੇ ਜੋ ਲੌਗ ਇਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾਉਂਦਾ ਹੈ ਉਹ ਤਿੰਨ ਹੋਣ ’ਤੇ ਵੀ ਇੱਕ ਦੁਹਰਾਉਂਦੀ ਖਰਾਬੀ ਵਾਂਗ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ।

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

ਨਵੀਨੀਕਰਨ ਬੰਦ ਕਰਨਾ ਹੱਲ ਨਹੀਂ ਹੈ

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

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

ਇਸਨੂੰ ਉਸ ਅਦਲ-ਬਦਲ ਨਾਲ ਸਾਬਤ ਕਰੋ ਜੋ ਫੇਲ੍ਹ ਹੋਈ

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

ਬਾਅਦ ਵਿੱਚ ਆਮ ਆਯੁ ਬਹਾਲ ਕਰੋ ਅਤੇ ਦੋਵੇਂ ਘਟਨਾ ਰਿਕਾਰਡ ਰੱਖੋ, ਨਾਕਾਮ ਅਤੇ ਸਫਲ। ਤੁਸੀਂ ਜੋ ਸਬੂਤ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਇਹ ਹੈ ਕਿ ਕਨੈਕਸ਼ਨ ਆਪਣਾ ਜੀਵਨ-ਚੱਕਰ ਟਿਕਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਇਸਨੇ ping ਝੱਲਿਆ।