ਟੋਕਨ ਲਈ OpenConnect ਨੂੰ ਕਿਹੜਾ PKCS#11 URI ਚਾਹੀਦਾ ਹੈ?
OpenConnect ਉਹ PKCS#11 URI ਚਾਹੁੰਦਾ ਹੈ ਜੋ ਟੋਕਨ ਦਾ ਸਰਟੀਫਿਕੇਟ ਤੇ ਕੁੰਜੀ ਨਾਮ ਦੇਵੇ, ਨਿਰਯਾਤ ਕੀਤਾ PEM ਨਹੀਂ। ਦਰਜ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਵਸਤੂ ਲੱਭੋ ਤੇ ਉਸ ਨੂੰ ਹਵਾਲਾ ਕਰੋ।
ਜਿਸ ਸਮਾਰਟ ਕਾਰਡ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਸਹੀ ਕੁੰਜੀ ਹੈ, ਉਸ ਨੂੰ ਵੀ ਦੱਸਣਾ ਪੈਂਦਾ ਹੈ ਕਿ ਉਸ ਉੱਤੇ ਕਿਹੜੀ ਵਸਤੂ ਵਰਤਣੀ ਹੈ। ਉਸ ਹਾਲਤ ਵਿੱਚ OpenConnect ਕਾਪੀ ਕੀਤੀ .key ਫਾਈਲ ਨਹੀਂ ਚਾਹੁੰਦਾ; ਉਹ PKCS#11 URI ਚਾਹੁੰਦਾ ਹੈ ਜੋ ਸਰਟੀਫਿਕੇਟ ਦਾ ਨਾਮ ਦੇਵੇ ਅਤੇ ਜਦੋਂ ਆਪਣੇ-ਆਪ ਖੋਜ ਕੰਮ ਪੂਰਾ ਨਾ ਕਰ ਸਕੇ ਤਾਂ ਨਾਲ ਵਾਲੀ ਨਿੱਜੀ ਕੁੰਜੀ ਦਾ ਵੀ। ਔਖੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਵਿਆਕਰਨ ਪੱਖੋਂ ਸਹੀ URI ਕੁਝ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਇਸ ਨੇ ਕਾਰਡ ਦੀ ਖੋਲ੍ਹਣ ਲਈ ਤਿਆਰ ਵਸਤੂ ਨਹੀਂ, ਉਸ ਦਰਜ ਦਾ ਨਾਮ ਦੇਣਾ ਹੈ ਜਿਸ ਉੱਤੇ ਗੇਟਵੇ ਪਹਿਲਾਂ ਹੀ ਭਰੋਸਾ ਕਰਦਾ ਹੈ।
ਨਿਰਯਾਤ ਕੀਤੀ ਕੁੰਜੀ ਦੀ ਥਾਂ ਕਲਾਇੰਟ ਕੀ ਚਾਹੁੰਦਾ ਹੈ
-c ਚੋਣ ਆਮ ਤੌਰ ਉੱਤੇ ਫਾਈਲ ਮਾਰਗ ਲੈਂਦੀ ਹੈ, ਪਰ ਜਦੋਂ ਮੁੱਲ PKCS#11 URI ਵਜੋਂ ਪਾਰਸ ਹੁੰਦਾ ਹੈ ਤਾਂ OpenConnect ਇਸ ਨੂੰ ਡਿਸਕ ਦੀ ਫਾਈਲ ਨਹੀਂ, ਟੋਕਨ ਅੰਦਰਲੀ ਵਸਤੂ ਦਾ ਹਵਾਲਾ ਮੰਨਦਾ ਹੈ। -k ਚੋਣ ਨਿੱਜੀ ਕੁੰਜੀ ਲਈ ਇਸੇ ਤਰ੍ਹਾਂ ਵਿਹਾਰ ਕਰਦੀ ਹੈ। ਕੁਝ ਵੀ ਨਿਰਯਾਤ ਨਹੀਂ ਹੁੰਦਾ ਅਤੇ ਕੁੰਜੀ ਕਾਰਡ ਵੱਲੋਂ ਦਿੱਤੀ ਸੁਰੱਖਿਆ ਕਦੇ ਨਹੀਂ ਛੱਡਦੀ। ਕਲਾਇੰਟ ਨੂੰ ਤੁਹਾਡੇ ਤੋਂ ਉਹ ਨਾਮ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਉੱਤੇ ਟੋਕਨ ਮਾਡਿਊਲ, ਸਰਟੀਫਿਕੇਟ ਭੰਡਾਰ ਅਤੇ ਗੇਟਵੇ ਦਰਜ ਸਹਿਮਤ ਹੋਣ।
ਬਹੁਤੇ ਯਤਨ ਇਸੇ ਆਖਰੀ ਪਾਬੰਦੀ ਉੱਤੇ ਰੁਕਦੇ ਹਨ। URI ਪੂਰੀ ਤਰ੍ਹਾਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਬਣਿਆ ਹੋਇਆ ਵੀ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਅਜਿਹਾ ਸਰਟੀਫਿਕੇਟ ਚੁਣ ਸਕਦਾ ਹੈ ਜਿਸ ਨੂੰ ਗੇਟਵੇ ਨਾਂਹ ਕਰੇਗਾ, ਕਿਉਂਕਿ ਵੈਧਤਾ ਤੇ ਸੰਬੰਧਤਾ ਵੱਖਰੇ ਸਵਾਲ ਹਨ। ਕਰਨ ਯੋਗ ਜਾਂਚ ਦਰਜ ਰਿਕਾਰਡ ਨਾਲ ਤੁਲਨਾ ਹੈ, ਨਾ ਕਿ ਸੰਜੋਗ ਨਾਲ ਖੁੱਲ੍ਹਣ ਵਾਲੀ ਪਹਿਲੀ ਵਸਤੂ ਦੀ ਖੋਜ।
ਦੋ URI, ਦੋ ਵੱਖਰੇ ਕੰਮ
ਸਰਟੀਫਿਕੇਟ ਦਾ URI ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਹੜੀ ਪਛਾਣ ਦਾ ਦਾਅਵਾ ਕਰ ਰਹੇ ਹੋ। ਇਹ ਉਸ ਸਰਟੀਫਿਕੇਟ ਵਸਤੂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ ਜਿਸ ਦੀ ਜਨਤਕ ਕੁੰਜੀ ਤੇ ਵਿਸ਼ਾ ਲਾਈਨ VPN ਪ੍ਰਬੰਧਕ ਵੱਲੋਂ ਜਾਰੀ ਖਾਤੇ ਜਾਂ ਡਿਵਾਈਸ ਪਰੋਫਾਈਲ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ। ਉਹੀ ਸਰਟੀਫਿਕੇਟ ਆਮ ਤੌਰ ਉੱਤੇ ਨਾਲ ਰੱਖੀ ਨਿੱਜੀ ਕੁੰਜੀ ਵਸਤੂ ਨਾਲ ਆਉਂਦਾ ਹੈ, ਅਤੇ TLS ਹੈਂਡਸ਼ੇਕ ਨੂੰ ਅਸਲ ਵਿੱਚ ਇਹੀ ਜੋੜੀ ਚਾਹੀਦੀ ਹੈ।
ਕੁੰਜੀ ਦਾ URI ਦੱਸਦਾ ਹੈ ਕਿ ਜਦੋਂ OpenConnect ਅੰਦਾਜ਼ਾ ਨਾ ਲਾ ਸਕੇ ਤਾਂ ਮੇਲ ਖਾਂਦਾ ਨਿੱਜੀ ਸਾਮਾਨ ਕਿੱਥੇ ਹੈ। ਸਿਰਫ਼ -c ਸੈੱਟ ਹੋਣ ਉੱਤੇ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਦੇ ਗੁਣਾਂ ਤੋਂ ਕੁੰਜੀ-ਖੋਜ ਬਣਾਉਂਦਾ ਹੈ; -k ਦੇਣ ਨਾਲ ਅੰਦਾਜ਼ੇ ਦੀ ਥਾਂ ਸਪਸ਼ਟ ਵਸਤੂ ਹਵਾਲਾ ਆ ਜਾਂਦਾ ਹੈ। ਟੋਕਨ ਦਾ PIN ਤੀਜਾ, ਅਸੰਬੰਧਿਤ ਇਨਪੁਟ ਹੈ: ਇਹ ਕਾਰਵਾਈ ਲਈ ਕਾਰਡ ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ ਕਦੇ ਵੀ ਵਸਤੂ ਦੀ ਪਛਾਣ ਨਹੀਂ ਕਰਦਾ।
openconnect --protocol=anyconnect \
-c 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=1a2b3c4d;id=%01' \
vpn.example.net
ਉਸ ਹਵਾਲਾ-ਬੱਧ ਸਤਰ ਵਿੱਚ ਸਭ ਕੁਝ ਡਾਟਾ ਹੈ। ਅੱਧ-ਵਿਰਾਮ URI ਦੇ ਗੁਣ ਵੱਖਰੇ ਕਰਦੇ ਹਨ ਅਤੇ ਪ੍ਰਤੀਸ਼ਤ-ਐਸਕੇਪ ਉਹ ਅੱਖਰ ਕੋਡ ਕਰਦੇ ਹਨ ਜੋ ਨਹੀਂ ਤਾਂ ਪਾਰਸਿੰਗ ਤੋੜ ਦੇਣਗੇ, ਇਸ ਲਈ ਪੂਰੀ ਦਲੀਲ ਨੇ ਸ਼ੈੱਲ ਵਿੱਚੋਂ ਅਖੰਡ ਲੰਘਣਾ ਹੈ।
ਤੁਹਾਡੇ ਦਰਜ ਨਾਲ ਮੇਲ ਖਾਂਦਾ URI ਲੱਭਣਾ
GnuTLS ਨਾਲ p11tool ਆਉਂਦਾ ਹੈ, ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਮੌਜੂਦਾ ਵਰਤੋਂਕਾਰ p11-kit ਰਾਹੀਂ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। p11tool --list-tokens ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਤੁਹਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਟੋਕਨ ਉੱਤੇ ਸਰਟੀਫਿਕੇਟ ਵਸਤੂਆਂ ਦੀ ਸੂਚੀ ਬਣਾਓ। ਜੇ ਵਸਤੂਆਂ ਸਿਰਫ਼ PIN ਤੋਂ ਬਾਅਦ ਦਿਸਣ ਤਾਂ --login ਸ਼ਾਮਲ ਕਰੋ, ਅਤੇ ਪਹਿਲਾਂ ਦਿਸਣ ਵਾਲੀ ਚੁਣਨ ਦੀ ਥਾਂ ਵਿਸ਼ਾ ਤੇ ਜਾਰੀਕਰਤਾ ਦੀ ਦਰਜ ਰਿਕਾਰਡ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
ਜੇ ਟੋਕਨ ਬਿਲਕੁਲ ਨਾ ਦਿਸੇ ਤਾਂ ਸਮੱਸਿਆ OpenConnect ਹੇਠਾਂ ਹੈ: p11-kit ਵਿੱਚ ਉਸ ਮਿਡਲਵੇਅਰ ਲਈ ਕੋਈ ਦਰਜ ਮਾਡਿਊਲ ਨਹੀਂ, ਜਾਂ ਮਾਡਿਊਲ ਕਿਸੇ ਹੋਰ ਖਾਤੇ ਲਈ ਦਰਜ ਹੈ। ਸਿਸਟਮ-ਵਿਆਪੀ ਦਰਜ /etc/pkcs11/modules ਹੇਠਾਂ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਪ੍ਰਤੀ-ਵਰਤੋਂਕਾਰ ਡਾਇਰੈਕਟਰੀ ਸਿਸਟਮ ਕਾਪੀ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਉਹੀ ਰੱਖ ਸਕਦੀ ਹੈ। ਜਾਂਚੋ ਕਿ ਮਾਡਿਊਲ ਫਾਈਲ ਵਿੱਚ ਪ੍ਰਦਾਤਾ ਮਾਰਗ ਉਸ ਲਾਇਬ੍ਰੇਰੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ ਜੋ ਰੀਡਰ ਦੇ ਸਾਫ਼ਟਵੇਅਰ ਨੇ ਅਸਲ ਵਿੱਚ ਸਥਾਪਿਤ ਕੀਤੀ ਹੈ।
ਸੂਚੀ ਵਿੱਚੋਂ URI ਕਾਪੀ ਕਰਦਿਆਂ ਉਸ ਦੁਆਲੇ ਦੇ ਹਵਾਲਾ ਚਿੰਨ੍ਹ ਰੱਖੋ। ਬਿਨਾਂ ਹਵਾਲਾ ਚਿੰਨ੍ਹਾਂ ਵਾਲੇ ਅੱਧ-ਵਿਰਾਮ ਦਲੀਲ ਨੂੰ ਪਹਿਲੇ ਗੁਣ ਉੱਤੇ ਕੱਟ ਦਿੰਦੇ ਹਨ ਅਤੇ ਕਲਾਇੰਟ ਫਿਰ ਨਾ ਲੱਭਣ ਵਾਲੀ ਵਸਤੂ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ।
ਜਦੋਂ ਆਪਣੇ-ਆਪ ਕੁੰਜੀ-ਖੋਜ ਹਾਰ ਮੰਨ ਲਵੇ
OpenConnect ਸਰਟੀਫਿਕੇਟ ਦੇ URI ਤੋਂ ਕੁੰਜੀ-ਖੋਜ ਕੱਢ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਜੋ ਸਟੀਕ ਮਿਲਾਨ ਕਰਦਾ ਹੈ ਉਹ ਸੰਸਕਰਣ ਉੱਤੇ ਨਿਰਭਰ ਹੈ, ਅਤੇ ਵਸਤੂ ਕਿਸਮ ਤੇ ਲੇਬਲ ਦਾ ਵਿਹਾਰ ਸਮੇਂ ਨਾਲ ਬਦਲਿਆ ਹੈ। ਜਦੋਂ ਤੱਕ ਕੰਮ ਨਾ ਕਰੇ URI ਛੋਟਾ ਕਰੋ, ਇਹ ਸਲਾਹ ਪੁਰਾਣਾ ਉਪਾਅ ਦੱਸਦੀ ਹੈ, ਲੋੜ ਨਹੀਂ। ਜੇ ਕੱਢੀ ਖੋਜ ਫੇਲ੍ਹ ਹੋਵੇ ਤਾਂ ਸਰਟੀਫਿਕੇਟ ਦੇ URI ਨੂੰ ਹੋਰ ਧੁੰਦਲਾ ਬਣਾਉਣ ਦੀ ਥਾਂ -k ਨਾਲ ਕੁੰਜੀ ਦਾ ਨਾਮ ਸਪਸ਼ਟ ਦਿਓ।
ਕਲਾਇੰਟ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕੁੰਜੀ ਮੌਜੂਦ ਹੈ ਅਤੇ p11tool --list-keys ਨਾਲ ਦਿਸਦੀ ਹੈ। ਫਿਰ ਜਾਂਚੋ ਕਿ ਵਸਤੂ ਦਸਤਖ਼ਤ ਜਾਂ ਡੀਕ੍ਰਿਪਸ਼ਨ ਲਈ ਵਰਤੋਂਯੋਗ ਵਜੋਂ ਨਿਸ਼ਾਨਿਤ ਹੈ, ਕਿਉਂਕਿ ਗਲਤ ਗੁਣਾਂ ਨਾਲ ਬਣੀ ਕੁੰਜੀ URI ਕਿੰਨਾ ਵੀ ਸਹੀ ਹੋਵੇ ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦੀ। OpenVPN ਪਰੋਫਾਈਲ ਦਾ ਕ੍ਰਮਬੱਧ pkcs11-id ਮੁੱਲ OpenConnect ਚੋਣ ਵਿੱਚ ਨਾ ਪਾਓ; ਇੱਕੋ ਕਾਰਡ ਨਾਲ ਗੱਲ ਕਰਦਿਆਂ ਵੀ ਦੋਵੇਂ ਕਲਾਇੰਟ ਵੱਖਰੇ ਪਛਾਣਕਰਤਾ ਫਾਰਮੈਟ ਵਰਤਦੇ ਹਨ।
ਜੇ URI ਹੱਲ ਹੋ ਜਾਵੇ ਅਤੇ PIN ਸਵੀਕਾਰ ਹੋ ਜਾਵੇ ਪਰ ਪ੍ਰਮਾਣਿਕਤਾ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ URI ਟਿਊਨ ਕਰਨਾ ਬੰਦ ਕਰੋ। ਗੇਟਵੇ ਦੀ ਆਪਣੀ ਗਲਤੀ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਅਗਲੀ ਅਸਫਲਤਾ ਟੋਕਨ ਤੋਂ ਉੱਤੇ ਹੈ।
ਸਿਰਫ਼ URI ਸਮੱਸਿਆਵਾਂ ਵਰਗੀਆਂ ਲੱਗਣ ਵਾਲੀਆਂ ਅਸਫਲਤਾਵਾਂ
ਹੋਰ ਪ੍ਰੋਟੋਕੋਲ ਬੋਲਣ ਵਾਲਾ ਗੇਟਵੇ ਤੁਹਾਡਾ URI ਸਹੀ ਹੋਵੇ ਜਾਂ ਗਲਤ, ਇੱਕੋ ਜਿਹਾ ਫੇਲ੍ਹ ਹੋਵੇਗਾ। OpenConnect ਨੇ ਪੁਰਾਣਾ vpnc ਕਲਾਇੰਟ ਕਿਸੇ ਕਾਰਨ ਬਦਲਿਆ, ਅਤੇ ਕਾਰਡ ਸਮਰਥਨ ਅਸੰਗਤ ਗੇਟਵੇ ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਸੰਗਤ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਵਸਤੂ ਦੇ ਗੁਣਾਂ ਉੱਤੇ ਇੱਕ ਹੋਰ ਘੰਟਾ ਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰਵਰ ਦਾ ਲੋੜੀਂਦਾ ਪ੍ਰੋਟੋਕੋਲ ਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਦਾ ਪ੍ਰਬੰਧ ਪੁਸ਼ਟ ਕਰੋ।
ਸਰਵਰ ਦੀ ਪਛਾਣ ਦੀ ਪੁਸ਼ਟੀ ਵੀ ਵੱਖਰੀ ਪਰਤ ਹੈ। ਕਲਾਇੰਟ ਗੇਟਵੇ ਦੇ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਆਪਣੇ ਭਰੋਸਾ ਭੰਡਾਰ ਨਾਲ ਜਾਂਚਦਾ ਹੈ, ਅਤੇ ਉਹ ਜਾਂਚ ਕਾਰਡ ਆਪਣਾ ਹਿੱਸਾ ਪੂਰਾ ਕਰਨ ਤੋਂ ਬਾਅਦ ਚੱਲਦੀ ਹੈ। ਰੀਡਰ ਦੀਆਂ ਇਜਾਜ਼ਤਾਂ ਤੇ ਬੰਦ pcscd ਸੇਵਾ ਇੱਕੋ ਬਾਹਰੀ ਲੱਛਣ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ, ਨਾ ਪੜ੍ਹਿਆ ਜਾ ਸਕਣ ਵਾਲਾ ਟੋਕਨ, ਪਰ ਹੱਲ ਕਿਤੇ ਸੌਖਾ ਹੈ।
ਵਸਤੂ ਤੋਂ ਬਾਹਰ ਵੱਲ ਕੰਮ ਕਰੋ: p11tool ਟੋਕਨ ਦੇਖਦਾ ਹੈ ਕਿ ਨਹੀਂ, ਸਰਟੀਫਿਕੇਟ ਤੇ ਕੁੰਜੀ ਦੇਖਦਾ ਹੈ ਕਿ ਨਹੀਂ, OpenConnect URI ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਕਿ ਨਹੀਂ, ਅਤੇ ਫਿਰ ਹੀ ਪੁੱਛੋ ਕਿ ਗੇਟਵੇ ਪਛਾਣ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਕਿ ਨਹੀਂ। ਹਰ ਕਦਮ ਦਾ ਆਪਣਾ ਗਲਤੀ ਸੁਨੇਹਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਅਗਲੇ ਨਾਲੋਂ ਜਾਂਚਣਾ ਸਸਤਾ ਹੈ।