ਸਰਟੀਫਿਕੇਟ ਬਦਲਣ ਤੋਂ ਬਾਅਦ OpenConnect ਗੇਟਵੇ ਨੂੰ ਕਿਉਂ ਰੱਦ ਕਰਦਾ ਹੈ?
ਗੇਟਵੇ ਦਾ ਸਰਟੀਫਿਕੇਟ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਤਸਦੀਕ ਦੀ ਅਸਫਲਤਾ ਭਰੋਸੇ ਦਾ ਫੈਸਲਾ ਹੈ, ਟੁੱਟੀ ਸੁਰੰਗ ਨਹੀਂ। ਜਾਰੀ ਕਰਨ ਵਾਲੀ CA ਅਤੇ ਇੱਕ ਹੀ ਕੁੰਜੀ ਨੂੰ ਪਿੰਨ ਕਰਨ ਵਿਚਕਾਰ ਚੁਣੋ।
ਗੇਟਵੇ ਸਰਟੀਫਿਕੇਟ ਬਦਲਦੇ ਹਨ, ਅਤੇ ਕੱਲ੍ਹ ਤੱਕ ਜੁੜਿਆ ਕਲਾਇੰਟ ਪਹਿਲੇ TLS ਵਟਾਂਦਰੇ 'ਤੇ ਰੁਕਣ ਲੱਗਦਾ ਹੈ। ਸੁਨੇਹਾ ਨੈੱਟਵਰਕ ਖਰਾਬੀ ਨਹੀਂ ਸਗੋਂ ਤਸਦੀਕ ਦਾ ਕਾਰਨ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਮਸ਼ੀਨ ਆਪ ਨਹੀਂ ਬਦਲੀ, ਇਹੀ ਲਾਹੇਵੰਦ ਸੁਰਾਗ ਹੈ। ਜੋ ਟੁੱਟਿਆ ਹੈ ਉਹ ਹੁਣ ਪੇਸ਼ ਕੀਤੇ ਜਾ ਰਹੇ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਉਨ੍ਹਾਂ ਜੜ੍ਹਾਂ ਵਿਚਕਾਰ ਦਾ ਸੰਬੰਧ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਲਾਇੰਟ ਵਿਚਾਰਨ ਲਈ ਤਿਆਰ ਹੈ। ਇਸਨੂੰ ਠੀਕ ਕਰਨਾ ਭਰੋਸੇ ਦਾ ਫੈਸਲਾ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਵਿਕਲਪ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਫੈਸਲਾ ਲਵੋ।
ਕੋਈ ਵੀ ਭਰੋਸਾ ਸੈਟਿੰਗ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸਫਲਤਾ ਪੜ੍ਹੋ
ਗੈਰਹਾਜ਼ਰ ਦਸਤਖਤਕਰਤਾ ਵਰਗੀ ਗਲਤੀ ਦਾ ਅਰਥ ਹੈ ਕਿ ਲੜੀ ਕਿਸੇ ਅਜਿਹੀ ਚੀਜ਼ 'ਤੇ ਖਤਮ ਹੁੰਦੀ ਹੈ ਜੋ ਕਲਾਇੰਟ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਅੰਦਰੂਨੀ ਅਥਾਰਟੀ ਦਾ ਨਵੀਨੀਕ੍ਰਿਤ ਸਰਟੀਫਿਕੇਟ, ਕਿਸੇ ਜਨਤਕ ਅਥਾਰਟੀ ਦਾ ਬਦਲ, ਜਾਂ ਵਿਚਕਾਰਲਾ ਜੰਤਰ ਆਪਣਾ ਸਰਟੀਫਿਕੇਟ ਪੇਸ਼ ਕਰ ਰਿਹਾ ਹੋ ਸਕਦਾ ਹੈ। ਸਿਰਫ ਸ਼ਬਦਾਵਲੀ ਉਨ੍ਹਾਂ ਮਾਮਲਿਆਂ ਨੂੰ ਵੱਖ ਨਹੀਂ ਕਰ ਸਕਦੀ, ਇਸ ਲਈ ਫੈਸਲਾ ਲੈਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਰੀਕਰਤਾ ਵੱਲ ਦੇਖੋ।
ਕਨੈਕਸ਼ਨ ਇੱਕ ਵਾਰ ਅਗਲੇ ਭਾਗ ਵਿੱਚ ਚਲਾਓ ਅਤੇ ਅਸਫਲ ਹੋਣ ਦਿਓ, ਕਿਉਂਕਿ ਇੰਟਰਐਕਟਿਵ ਆਉਟਪੁੱਟ ਵਿੱਚ ਸਰਵਰ ਦਾ ਨਾਮ, ਜਾਰੀਕਰਤਾ ਲੜੀ ਅਤੇ ਕਲਾਇੰਟ ਵੱਲੋਂ ਗਿਣਿਆ ਫਿੰਗਰਪ੍ਰਿੰਟ ਹੁੰਦਾ ਹੈ। ਉਸ ਜਾਰੀਕਰਤਾ ਦੀ ਤੁਲਨਾ ਉਸ ਅਥਾਰਟੀ ਨਾਲ ਕਰੋ ਜੋ ਤੁਹਾਡੀ ਸੰਸਥਾ ਸੱਚਮੁੱਚ ਚਲਾਉਂਦੀ ਹੈ। ਜੇ ਫਿੰਗਰਪ੍ਰਿੰਟ ਬਦਲਿਆ ਪਰ ਜਾਰੀਕਰਤਾ ਨਹੀਂ, ਤਾਂ ਇਸਨੂੰ ਸ਼ੱਕੀ ਮੰਨੋ ਜਦ ਤੱਕ ਤੁਹਾਡੇ ਪਹਿਲਾਂ ਤੋਂ ਭਰੋਸੇਯੋਗ ਕਿਸੇ ਮਾਧਿਅਮ ਰਾਹੀਂ ਨਵੀਨੀਕਰਨ ਦੀ ਪੁਸ਼ਟੀ ਨਾ ਹੋ ਜਾਵੇ। ਇਸ ਪੜਾਅ 'ਤੇ ਅੰਦਾਜ਼ਾ ਲਾਉਣਾ ਹੀ ਉਹ ਰਾਹ ਹੈ ਜਿਸ ਨਾਲ ਕੋਈ ਅਖੀਰ ਵਿਚਕਾਰ ਆਉਣ ਵਾਲੇ ਦੀ ਕੁੰਜੀ ਪਿੰਨ ਕਰ ਦਿੰਦਾ ਹੈ।
ਉਸੇ ਨੋਟ ਵਿੱਚ ਕਲਾਇੰਟ ਸੰਸਕਰਣ ਲਿਖੋ। ਭਰੋਸੇ ਦੀ ਸਮੱਸਿਆ ਵਰਗੀਆਂ ਦਿਖਣ ਵਾਲੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਅਸਫਲਤਾਵਾਂ ਪੁਰਾਣੇ ਕਲਾਇੰਟ ਦੇ ਨਵੇਂ ਗੇਟਵੇ ਵਟਾਂਦਰੇ ਨਾਲ ਟਕਰਾਉਣ ਕਾਰਨ ਆਉਂਦੀਆਂ ਹਨ।
ਜਾਰੀਕਰਤਾ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਅਤੇ ਇੱਕ ਕੁੰਜੀ ਪਿੰਨ ਕਰਨ ਵਿਚਕਾਰ ਚੁਣੋ
ਦੋਵੇਂ ਵਿਕਲਪ ਕਨੈਕਸ਼ਨ ਨੂੰ ਸਫਲ ਬਣਾਉਂਦੇ ਹਨ। ਉਹ ਬਾਅਦ ਵਿੱਚ ਉਲਟ ਤਰੀਕਿਆਂ ਨਾਲ ਟੁੱਟਦੇ ਹਨ, ਇਸ ਲਈ ਚੋਣ ਉਸ ਅਸਫਲਤਾ ਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਸਹਿ ਸਕਦੇ ਹੋ।
| Approach | Good fit | What breaks it |
|---|---|---|
Trust the issuing CA with --cafile | Internal PKI you can obtain over an already trusted channel | CA rotation, or a client that still falls back to public roots |
Pin one key with --servercert | No CA relationship, or exactly one key should ever be accepted | Any reissue that generates a new key pair |
CA ਫਾਈਲ ਵੱਲ ਜਾਓ ਜਦੋਂ ਸਰਟੀਫਿਕੇਟ ਉਸ ਅਥਾਰਟੀ ਤੋਂ ਆਉਂਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਆਜ਼ਾਦ ਤੌਰ 'ਤੇ ਤਸਦੀਕ ਕਰ ਸਕਦੇ ਹੋ, ਕਿਉਂਕਿ ਫਿਰ ਨਵੀਨੀਕਰਨ ਕਲਾਇੰਟ ਆਰਗਿਊਮੈਂਟ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਕੰਮ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ। ਇਸਨੂੰ ਉਸ ਸਵਿੱਚ ਨਾਲ ਜੋੜੋ ਜੋ ਸਿਸਟਮ ਜੜ੍ਹਾਂ ਨੂੰ ਅਸਮਰੱਥ ਕਰਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਕੋਈ ਜਨਤਕ ਅਥਾਰਟੀ ਤੁਹਾਡੀ ਥਾਂ ਤਸਦੀਕ ਪੂਰੀ ਕਰ ਸਕਦੀ ਹੈ। ਇਸਦੀ ਥਾਂ ਪਿੰਨ ਕਰੋ ਜਦੋਂ ਗੇਟਵੇ ਕੋਲ ਪ੍ਰਾਪਤ ਕਰਨ ਯੋਗ CA ਨਾ ਹੋਵੇ ਜਾਂ ਜਦੋਂ ਸਭ ਤੋਂ ਸੰਕੀਰਣ ਸੰਭਵ ਅਪਵਾਦ ਟੀਚਾ ਹੋਵੇ। ਕੋਈ ਵੀ ਰਾਹ ਅਮੂਰਤ ਰੂਪ ਵਿੱਚ ਵਧੇਰੇ ਸੁਰੱਖਿਅਤ ਨਹੀਂ: CA ਨਵੀਨੀਕਰਨਾਂ ਵਿੱਚ ਫੈਲਦੀ ਹੈ, ਪਿੰਨ ਦੀ ਸਮੀਖਿਆ ਸੌਖੀ ਹੈ।
ਤੁਸੀਂ ਜੋ ਵੀ ਚੁਣੋ, ਭਰੋਸੇਯੋਗ ਮੁੱਲ ਉਸ ਮਾਧਿਅਮ ਰਾਹੀਂ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਭਰੋਸੇਯੋਗ ਸੀ। ਪ੍ਰਬੰਧਕ, ਗੇਟਵੇ 'ਤੇ ਕਨਸੋਲ ਸੈਸ਼ਨ, ਜਾਂ ਪਹਿਲਾਂ ਲਈ ਗਈ ਨਕਲ—ਸਭ ਯੋਗ ਹਨ। ਪ੍ਰੋਂਪਟ ਜੋ ਵੀ ਫਿੰਗਰਪ੍ਰਿੰਟ ਦਿਖਾਏ ਉਸਦੀ ਨਕਲ ਕਰਨਾ ਸੁਵਿਧਾਜਨਕ ਹੈ ਅਤੇ ਠੀਕ ਉਹੀ ਹੈ ਜਿਸਦੀ ਵਿਚਕਾਰ ਆਉਣ ਵਾਲਾ ਆਸ ਕਰਦਾ ਹੈ।
ਮੁੱਲ ਉਸੇ ਕਮਾਂਡ ਵਿੱਚ ਰੱਖੋ ਜੋ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ
ਪਿੰਨ ਇੱਕ ਸਰਵਰ-ਸਰਟੀਫਿਕੇਟ ਵਿਕਲਪ ਵਿੱਚ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸਦਾ ਅਗੇਤਰ ਐਨਕੋਡਿੰਗ ਤੈਅ ਕਰਦਾ ਹੈ: sha1 ਜਾਂ sha256 ਅਧੀਨ ਹੈਕਸਾਡੈਸੀਮਲ ਜਨਤਕ-ਕੁੰਜੀ ਡਾਈਜੈਸਟ, ਅਤੇ pin-sha256 ਅਧੀਨ base64 ਕੁੰਜੀ ਪਿੰਨ। ਇਸਨੂੰ ਦੇਣ ਨਾਲ ਉਸ ਰਨ ਲਈ ਸਿਸਟਮ ਭਰੋਸਾ ਵੀ ਅਸਮਰੱਥ ਹੋ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਪਿੰਨ ਕੀਤੀ ਕੁੰਜੀ ਹੀ ਪੂਰਾ ਫੈਸਲਾ ਬਣ ਜਾਂਦੀ ਹੈ।
sudo openconnect --protocol=gp vpn.example.com --user alice \
--servercert pin-sha256:AbCdEf... # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trustਕਲਾਇੰਟ ਕੱਟਿਆ ਡਾਈਜੈਸਟ ਮਿਲਾਉਂਦਾ ਹੈ, ਅਗੇਤਰ ਤੋਂ ਬਾਅਦ ਸਿਰਫ ਚਾਰ ਅੱਖਰ ਵੀ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਜੋ ਸੁਵਿਧਾ ਨਹੀਂ ਸਗੋਂ ਜਾਲ ਹੈ। ਛੋਟਾ ਕੀਤਾ ਮੁੱਲ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਪਾਸ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਤੁਹਾਡੇ ਲੋੜੀਂਦੇ ਗੇਟਵੇ ਦੀ ਪਛਾਣ ਨਹੀਂ ਕਰਦਾ। ਸੁਨੇਹੇ ਤੋਂ ਦੁਬਾਰਾ ਟਾਈਪ ਕਰਨ ਦੀ ਥਾਂ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਕਲਾਇੰਟ ਵੱਲੋਂ ਛਾਪੀ ਪੂਰੀ ਸਤਰ ਨਕਲ ਕਰੋ। ਫਿਰ ਤਿਆਰ ਵਿਕਲਪ ਨੂੰ ਉਸ ਰੈਪਰ ਸਕ੍ਰਿਪਟ, ਯੂਨਿਟ ਫਾਈਲ ਜਾਂ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਲਿਜਾਓ ਜੋ ਕਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ, ਤਾਂ ਜੋ ਭਰੋਸੇ ਦਾ ਫੈਸਲਾ ਸਮੀਖਿਆਯੋਗ ਰਹੇ ਅਤੇ ਬਾਅਦ ਦੀਆਂ ਸੋਧਾਂ ਜਾਣਬੁੱਝ ਕੇ ਹੋਣ।
ਡੈਸਕਟਾਪ ਲਾਂਚਰ ਅਤੇ NetworkManager ਪਲੱਗਇਨ ਕਨੈਕਸ਼ਨ ਆਰਗਿਊਮੈਂਟ ਦੀ ਆਪਣੀ ਨਕਲ ਰੱਖਦੇ ਹਨ। ਡਿਸਕ 'ਤੇ ਸੋਧੀ ਸਕ੍ਰਿਪਟ ਪਹਿਲਾਂ ਆਯਾਤ ਕੀਤੀ ਪ੍ਰੋਫਾਈਲ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੀ, ਇਸ ਲਈ ਸੰਭਾਲਿਆ ਮੁੱਲ ਜਿੱਤਦਾ ਰਹਿੰਦਾ ਹੈ।
ਆਪਣੇ ਆਪ ਨੂੰ ਬਾਹਰ ਤਾਲਾ ਲਗਾਏ ਬਿਨਾਂ ਬਦਲੀ ਸੰਭਾਲੋ
ਵਿਕਲਪ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਯੋਜਨਾਬੱਧ ਬਦਲਾਅ ਬਾਹਰ ਜਾਣ ਵਾਲੀ ਅਤੇ ਅੰਦਰ ਆਉਣ ਵਾਲੀ ਕੁੰਜੀ ਇਕੱਠੀਆਂ ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ। ਗੇਟਵੇ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਨਵਾਂ ਪਿੰਨ ਜੋੜੋ, ਸੈਸ਼ਨ ਸਥਾਨਾਂਤਰਿਤ ਹੁੰਦੇ ਰਹਿਣ ਤੱਕ ਦੋਵੇਂ ਸੂਚੀਬੱਧ ਰੱਖੋ, ਅਤੇ ਪੁਰਾਣੀ ਕੁੰਜੀ ਜਾਣ 'ਤੇ ਸੇਵਾਮੁਕਤ ਨੂੰ ਹਟਾ ਦਿਓ। ਉਸ ਵਿੰਡੋ ਲਈ ਮਾਲਕ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਭੁੱਲਿਆ ਦੋਹਰਾ ਪਿੰਨ ਕੁੰਜੀ ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਨਿਗਰਾਨੀ ਦੇ ਭਰੋਸੇਯੋਗ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਨਵੀਂ ਕੁੰਜੀ-ਜੋੜੀ ਬਣਾਉਣ ਵਾਲਾ ਮੁੜਨਿਰਮਾਣ ਸ਼ੁੱਧ ਪਿੰਨ ਤੋੜਦਾ ਹੈ, ਅਤੇ ਮੁੜ ਪ੍ਰਾਪਤੀ ਉਲਟ ਦਿਸ਼ਾ ਵਿੱਚ ਉਹੀ ਪ੍ਰਕਿਰਿਆ ਹੈ।
ਪਿੰਨ ਦੇ ਕੋਲ ਬਦਲਾਅ ਦੀ ਤਾਰੀਖ ਲਿਖੋ। ਸਮੀਖਿਆ ਤਾਰੀਖ ਤੋਂ ਬਿਨਾਂ ਪਿੰਨ ਉਲਝਾਉਣ ਵਾਲਾ ਗਲਤੀ ਸੁਨੇਹਾ ਲੈ ਕੇ ਆਉਣ ਵਾਲੀ ਭਵਿੱਖ ਦੀ ਰੁਕਾਵਟ ਹੈ।
ਭਰੋਸਾ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਸੰਸਕਰਣ ਨੂੰ ਬਾਹਰ ਰੱਖੋ
ਪੁਰਾਣਾ ਕਲਾਇੰਟ ਗੇਟਵੇ ਵੱਲੋਂ ਬਾਅਦ ਵਿੱਚ ਬਦਲੇ ਪ੍ਰਮਾਣੀਕਰਨ ਜਵਾਬ ਨੂੰ ਪਾਰਸ ਕਰਦਿਆਂ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਤਹੀ ਸੁਨੇਹਾ ਅਜੇ ਵੀ ਪਾਰਸਰ ਦੀ ਥਾਂ ਕਨੈਕਸ਼ਨ ਦੀ ਗੱਲ ਕਰਦਾ ਹੈ। ਸਥਾਪਿਤ ਸੰਸਕਰਣ ਦੀ ਤੁਲਨਾ ਉਸ ਨਾਲ ਕਰੋ ਜੋ ਗੇਟਵੇ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਭਰੋਸਾ ਸੈਟਿੰਗ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਪੈਕੇਜ ਨੂੰ ਇੱਕ ਵਾਰ ਦੀ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਪਰਖੋ।
openconnect --versionਮੁਰੰਮਤ ਤੋਂ ਬਾਅਦ ਇੱਕ ਨਹੀਂ ਸਗੋਂ ਦੋ ਚੀਜ਼ਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: ਪੋਰਟਲ ਸੁਰੰਗ ਰਾਹੀਂ ਲੋਡ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਆਮ ਅੰਦਰੂਨੀ ਪਤਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਪੂਰਾ ਹੋਇਆ ਹੈਂਡਸ਼ੇਕ ਸਿਰਫ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਭਰੋਸੇ ਦਾ ਫੈਸਲਾ ਸਵੀਕਾਰ ਹੋਇਆ।