strongSwan send_cert: IKE ਸਰਟੀਫਿਕੇਟ ਕਦੋਂ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ

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

send_cert ਅਸਲ ਵਿੱਚ ਕੀ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ

ਸਰਟੀਫਿਕੇਟ ਰਾਹੀਂ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਲਾਜ਼ਮੀ ਹੈ ਕਿ peer ਦਾ ਅੰਤਿਮ-ਇਕਾਈ ਸਰਟੀਫਿਕੇਟ IKE ਅਦਾਨ-ਪ੍ਰਦਾਨ ਜਾਂ ਪਹਿਲਾਂ ਤੋਂ ਤਿਆਰੀ ਰਾਹੀਂ ਦੂਜੇ ਪਾਸੇ ਪਹੁੰਚੇ। swanctl ਵਿੱਚ ਕਨੈਕਸ਼ਨ ਸੈਟਿੰਗ send_cert ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਇਹ ਅੰਤਿਮ ਬਿੰਦੂ ਆਪਣਾ ਸਰਟੀਫਿਕੇਟ ਪੇਲੋਡ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ: ਕਦੇ ਨਹੀਂ, ਹਮੇਸ਼ਾ ਜਾਂ ifasked। ਡਿਫਾਲਟ ifasked ਇਸ ਨੂੰ peer ਵੱਲੋਂ ਆਈ ਸਰਟੀਫਿਕੇਟ ਬੇਨਤੀ ਦੇ ਜਵਾਬ ਵਿੱਚ ਭੇਜਦਾ ਹੈ। ਸਰਟੀਫਿਕੇਟ ਮੰਗਣਾ ਵੱਖਰੀ ਸੈਟਿੰਗ ਹੈ, ਕਿਉਂਕਿ ਦੂਜੇ ਪਾਸਿਓਂ ਉਸ ਦਾ ਸਰਟੀਫਿਕੇਟ ਮੰਗਣਾ ਆਪਣਾ ਪੇਸ਼ ਕਰਨ ਦੇ ਬਰਾਬਰ ਨਹੀਂ।

ਪੁਰਾਣੀਆਂ ipsec.conf ਤੈਨਾਤੀਆਂ leftsendcert ਅਤੇ rightsendcert ਵਰਤਦੀਆਂ ਸਨ, ਅਤੇ ਇਹ ਨਾਮ ਸਥਾਨਕ ਤੇ ਦੂਰਸਥ ਭੂਮਿਕਾਵਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਸਿੱਧਾ swanctl ਨਾਲ ਨਹੀਂ।

ਕਨੈਕਸ਼ਨ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਕੋਸ਼ਿਸ਼ ਪੜ੍ਹੋ

ਇੱਕ ਨਿਯੰਤਰਿਤ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਨਿਦਾਨ ਕਰੋ, ਸਰਟੀਫਿਕੇਟ ਸ਼ਾਮਲ ਹਨ ਇਸ ਆਮ ਧਾਰਨਾ ਤੋਂ ਨਹੀਂ। ਨੀਤੀ ਅਤੇ ਸਰਗਰਮ ਸੰਬੰਧ ਦੋਵੇਂ ਵੇਖੇ ਜਾ ਸਕਦੇ ਹਨ।

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

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

ਪ੍ਰਾਪਤਕਰਤਾ ਦਾ ਭਰੋਸਾ ਵੱਖਰਾ ਫੈਸਲਾ ਹੈ

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

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

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

ਭੇਜਣ ਵਾਲਾ ਸਿਰਫ਼ ਸਬੂਤ ਨਾਲ ਬਦਲੋ

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

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