Mac ਉੱਤੇ VPN ਸਰਟੀਫਿਕੇਟ ਲੌਗਇਨ: ਪਛਾਣ, ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਜਾਂ ਗੇਟਵੇ ਉੱਤੇ ਭਰੋਸਾ?
ਸਰਟੀਫਿਕੇਟ ਅਧਾਰਿਤ ਲੌਗਇਨ ਪਿੱਛੇ ਤਿੰਨ ਫੈਸਲੇ ਹਨ: ਕਿਹੜੀ ਪਛਾਣ ਚੁਣੀ ਜਾਂਦੀ ਹੈ, VPN ਹਿੱਸਾ ਆਪਣੀ ਕੁੰਜੀ ਵਰਤ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਗੇਟਵੇ ਉੱਤੇ ਭਰੋਸਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਸਰਟੀਫਿਕੇਟ ਅਧਾਰਿਤ VPN ਲੌਗਇਨ Mac ਤੋਂ ਪਾਸਵਰਡ ਨਾਲੋਂ ਵਧੇਰੇ ਸੰਕੁਚਿਤ ਚੀਜ਼ ਮੰਗਦੇ ਹਨ: ਇਹ ਖਾਸ ਪ੍ਰਾਈਵੇਟ ਕੁੰਜੀ, ਇਸੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸੰਦਰਭ ਵਿੱਚ, ਉਸ ਗੇਟਵੇ ਸਾਮ੍ਹਣੇ ਪਛਾਣ ਸਾਬਤ ਕਰਨ ਲਈ ਵਰਤੋ। ਜਦੋਂ ਇਹ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਸੰਦੇਸ਼ ਆਮ ਤੌਰ ’ਤੇ ਸਿਰਫ਼ ਆਖਰੀ ਗ਼ਲਤ ਹੋਈ ਚੀਜ਼ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਹੀ ਕਾਰਨ ਹੁੰਦੀ ਹੈ ਅਜਿਹਾ ਘੱਟ ਹੀ ਹੁੰਦਾ ਹੈ। ਸਿਸਟਮ ਜਿਸ ਕ੍ਰਮ ਵਿੱਚ ਤਿੰਨੇ ਫੈਸਲੇ ਲੈਂਦਾ ਹੈ, ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਉਨ੍ਹਾਂ ਦੀ ਪੈੜ ਲੈਣ ਨਾਲ ਨਿਦਾਨ ਇਮਾਨਦਾਰ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਸਥਾਨਕ ਇਜਾਜ਼ਤ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਚੇਨ-ਪ੍ਰਮਾਣਿਕਤਾ ਫੇਲ੍ਹ ਹੋਣ ਵਜੋਂ ਲੈਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਲੌਗਇਨ ਨੂੰ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਤੁਰੋ ਜਿਸ ਕ੍ਰਮ ਵਿੱਚ Mac ਤੁਰਦਾ ਹੈ
ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਪਛਾਣ ਚੁਣਦਾ ਹੈ: ਵਰਤੋਂ ਯੋਗ ਪ੍ਰਾਈਵੇਟ ਕੁੰਜੀ ਨਾਲ ਜੋੜਿਆ ਸਰਟੀਫਿਕੇਟ, ਜੋ ਸਮਰਥਿਤ ਸਟੋਰ ਜਾਂ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਤਾ ਰਾਹੀਂ ਉਪਲਬਧ ਹੈ। ਫਿਰ VPN ਹਿੱਸਾ ਉਸ ਕੁੰਜੀ ਨਾਲ ਗੁਪਤ-ਲਿਖਤ ਕਿਰਿਆ ਕਰਨ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਥਾਨਕ ਅਧਿਕਾਰ ਨਮੂਨਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਦੋਵੇਂ ਸਫਲ ਹੋਣ ਮਗਰੋਂ ਹੀ ਦੂਰ ਦਾ ਹੈਂਡਸ਼ੇਕ ਹੁੰਦਾ ਹੈ, ਜਿੱਥੇ Mac ਗੇਟਵੇ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ ਅਤੇ ਗੇਟਵੇ ਕਲਾਇੰਟ ਦੇ ਸਬੂਤ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ।
| Decision | Typical symptom | Where to look |
|---|---|---|
| Identity selection | No valid identity, wrong certificate offered | Profile and which identity the client picked |
| Local key use | Signing or interaction error before any handshake | Execution context and key access rules |
| Remote authentication | Chain, name or client-admission rejection | Gateway identity and what it accepts |
ਸਾਰਣੀ ਨੂੰ ਉੱਪਰ ਤੋਂ ਹੇਠਾਂ ਪੜ੍ਹੋ ਅਤੇ ਪਹਿਲੀ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲੀ ਕਤਾਰ ’ਤੇ ਰੁਕੋ। ਫੇਲ੍ਹ ਹੋਣ ਤੋਂ ਹੇਠਾਂ ਸਭ ਕੁਝ ਅਸਾਬਤ ਹੈ, ਇਸੇ ਲਈ “ਸਰਟੀਫਿਕੇਟ ’ਤੇ ਭਰੋਸਾ ਨਹੀਂ” ਇੰਨਾ ਆਮ ਅਤੇ ਇੰਨਾ ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਣ ਵਾਲਾ ਸਿੱਟਾ ਹੈ।
ਸਥਾਨਕ ਇਜਾਜ਼ਤ ਅਸਲ ਵਿੱਚ ਕੀ ਕਵਰ ਕਰਦੀ ਹੈ
macOS ਕੀਚੇਨ ਨਮੂਨੇ ਵਿੱਚ, ਸੁਰੱਖਿਅਤ ਚੀਜ਼ਾਂ ਨਾਲ ਕਿਰਿਆ-ਖਾਸ ਪਹੁੰਚ ਨਿਯਮ ਅਤੇ ਭਰੋਸੇਯੋਗ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਸੂਚੀ ਹੁੰਦੀ ਹੈ। ਪ੍ਰਾਈਵੇਟ ਕੁੰਜੀ ਨਾਲ ਦਸਤਖ਼ਤ ਕਰਨਾ ਅਜਿਹੀ ਹੀ ਇੱਕ ਕਿਰਿਆ ਹੈ, ਅਤੇ ਨਿਯਮ ਉਸ ਚੱਲਣ ਯੋਗ ਫਾਈਲ ’ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ ਜੋ ਇਹ ਕਰਦੀ ਹੈ, ਦਸਤਾਵੇਜ਼ ਵਜੋਂ ਸਰਟੀਫਿਕੇਟ ’ਤੇ ਨਹੀਂ। Apple ਦਾ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਸੰਦਰਭ ਇਸ ਨਮੂਨੇ ਅਤੇ iCloud ਕੀਚੇਨ ਤੇ ਪਹੁੰਚ-ਸਮੂਹ ਪ੍ਰਬੰਧਾਂ ਵਿਚਕਾਰ ਵੀ ਲਕੀਰ ਖਿੱਚਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਲਈ ਲਿਖੀ ਸਲਾਹ ਦੂਜੇ ’ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀ।
ਇਸ ਤੋਂ ਦੋ ਨਤੀਜੇ ਨਿਕਲਦੇ ਹਨ। ਸੂਚੀ ਵਿੱਚ ਦਿਸਦਾ ਜਨਤਕ ਸਰਟੀਫਿਕੇਟ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ VPN ਦਾ ਪਿਛੋਕੜ ਹਿੱਸਾ ਉਸ ਕੁੰਜੀ ਤੱਕ ਪਹੁੰਚ ਹੀ ਸਕਦਾ ਹੈ। ਅਤੇ ਸਾਹਮਣੇ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਦਿੱਤੀ ਇਜਾਜ਼ਤ ਵੱਖਰੇ ਸਹਾਇਕ ਜਾਂ ਨੈੱਟਵਰਕ ਐਕਸਟੈਂਸ਼ਨ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ, ਕਿਉਂਕਿ ਉਹ ਵੱਖਰੀ ਪਛਾਣ ਵਾਲਾ ਵੱਖਰਾ ਕੋਡ ਹੈ।
ਪੁਰਾਣੇ ਕਲਾਇੰਟ ਵਿੱਚੋਂ ਚੱਲਣ ਯੋਗ ਫਾਈਲ ਦਾ ਰਾਹ ਨਕਲ ਕਰਨ ਦੀ ਥਾਂ ਅਸਲ ਅਮਲ ਅਤੇ ਉਸ ਦੀ ਸਮਰਥਿਤ ਜਾਣਕਾਰੀ-ਸਾਂਝ ਵਿਧੀ ਪਛਾਣੋ। ਪਹਿਲਾਂ ਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਸਿਸਟਮ ਕਿਹੜੀ ਪਛਾਣ ਪੇਸ਼ ਕਰੇਗਾ:
security find-identity -v -p ssl-client
errSecInteractionNotAllowed ਪੜ੍ਹਨਾ
ਉਹ ਸਥਿਤੀ Security Server ਨਾਲ ਹੋਈ ਨਾਮਨਜ਼ੂਰ ਆਪਸੀ ਕਿਰਿਆ ਦੀ ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ, ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਚੇਨਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ। ਇਸ ਨੂੰ ਉਸ ਕਿਰਿਆ ਨਾਲ ਪੜ੍ਹੋ ਜਿਸ ਨੇ ਇਹ ਪੈਦਾ ਕੀਤੀ: ਜਿਸ ਸੰਦਰਭ ਤੋਂ ਪ੍ਰੋਂਪਟ ਨਹੀਂ ਦਿਖਾਇਆ ਜਾ ਸਕਦਾ, ਉੱਥੋਂ ਭੇਜੀ ਦਸਤਖ਼ਤ ਬੇਨਤੀ ਇਸੇ ਤਰ੍ਹਾਂ ਫੇਲ੍ਹ ਹੋਵੇਗੀ, ਭਾਵੇਂ ਕੁੰਜੀ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਦੋਵੇਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੈਧ ਹੋਣ। ਸ਼ੁਰੂਆਤ ਉਸ ਕਿਰਿਆ ਤੋਂ ਕਰੋ ਜਿਸ ਨੇ ਇਹ ਦਰਜ ਕੀਤੀ, ਸਰਟੀਫਿਕੇਟ ਸਟੋਰ ਤੋਂ ਨਹੀਂ। ਭਰੋਸਾ ਐਂਕਰਾਂ ਬਾਰੇ ਤੁਸੀਂ ਜੋ ਵੀ ਬਦਲੋਗੇ, ਗ਼ਲਤੀ ਨੂੰ ਠੀਕ ਉੱਥੇ ਹੀ ਛੱਡ ਦੇਵੇਗਾ ਜਿੱਥੇ ਉਹ ਸੀ।
ਇਸ ਲਈ ਕੋਡ ਨੂੰ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸੰਦਰਭ ਅਤੇ ਅਧਿਕਾਰ ਦੀ ਜਾਂਚ ਦੇ ਕਾਰਨ ਵਜੋਂ ਲਵੋ। ਇਸ ਨੂੰ ਇਸ ਸਬੂਤ ਵਜੋਂ ਲੈਣਾ ਕਿ ਗੇਟਵੇ ਦਾ CA ਭਰੋਸੇਯੋਗ ਨਹੀਂ, ਤੁਹਾਨੂੰ ਸਮੱਸਿਆ ਦੇ ਗ਼ਲਤ ਅੱਧ ਵੱਲ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਉੱਥੇ ਕੀਤਾ ਬਦਲਾਅ ਗ਼ਲਤੀ ’ਤੇ ਬਿਲਕੁਲ ਅਸਰ ਨਹੀਂ ਕਰੇਗਾ।
ਸੰਕੁਚਿਤ ਢੰਗ ਨਾਲ ਠੀਕ ਕਰੋ, ਖੁੱਲ੍ਹੇ ਢੰਗ ਨਾਲ ਨਹੀਂ
ਕਨੈਕਸ਼ਨ ਦੇ ਮਾਲਕ ਦੀਆਂ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਜਾਂ ਆਯਾਤ ਹਦਾਇਤਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਕਲਾਇੰਟ ਵਰਜਨ, ਪ੍ਰੋਫਾਈਲ ਦਾ ਦਾਇਰਾ, ਚੁਣੀ ਪਛਾਣ ਅਤੇ ਪਹਿਲੀ ਸੰਬੰਧਿਤ ਸਥਾਨਕ ਗ਼ਲਤੀ ਦਰਜ ਕਰੋ, ਕਿਉਂਕਿ ਇਹ ਚਾਰ ਤੱਥ ਹੀ ਸਹਾਇਤਾ ਹੈਂਡਓਫ਼ ਨੂੰ ਲੋੜੀਂਦੇ ਹਨ ਅਤੇ ਬਾਅਦ ਦੀ ਤੁਲਨਾ ਇਨ੍ਹਾਂ ’ਤੇ ਨਿਰਭਰ ਹੈ। ਪ੍ਰਬੰਧਿਤ ਪ੍ਰੋਫਾਈਲ ਜਾਂ ਹਾਰਡਵੇਅਰ-ਆਧਾਰਿਤ ਪਛਾਣ ਲਈ ਪ੍ਰਸ਼ਾਸਕ ਜਾਂ ਪ੍ਰਦਾਤਾ ਨੂੰ ਹੈਂਡਓਫ਼ ਠੀਕ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਥਾਨਕ ਕਲਿੱਕਾਂ ਦੀ ਕੋਈ ਵੀ ਮਾਤਰਾ ਉਸ ਦਾ ਬਦਲ ਨਹੀਂ ਹੈ।
ਜਿੱਥੇ ਉਤਪਾਦ ਵਰਤੋਂਕਾਰ ਦੀ ਮਨਜ਼ੂਰੀ ਦੀ ਆਸ ਰੱਖਦਾ ਹੈ, ਉੱਥੇ ਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਕਿਹੜਾ ਹਿੱਸਾ ਮੰਗ ਰਿਹਾ ਹੈ ਅਤੇ ਸਮਰਥਿਤ ਪ੍ਰਵਾਹ ਰਾਹੀਂ ਸਿਰਫ਼ ਉਸੇ ਪਹੁੰਚ ਦੀ ਮਨਜ਼ੂਰੀ ਦਿਓ। ਜਿੱਥੇ ਹਿੱਸੇ ਕੋਲ ਜਿਸ ਸੰਦਰਭ ਵਿੱਚ ਉਹ ਚੱਲਦਾ ਹੈ, ਉੱਥੇ ਪ੍ਰੋਂਪਟ ਉਠਾਉਣ ਦਾ ਕੋਈ ਰਾਹ ਨਹੀਂ, ਉੱਥੇ ਪ੍ਰਬੰਧਨ ਨੂੰ ਵਿਕਰੇਤਾ ਦੇ ਦਸਤਾਵੇਜ਼ੀ ਰਾਹ ਦੀ ਪੈੜ ਲੈਣੀ ਪਵੇਗੀ, ਕਿਸੇ ਹੋਰ ਟਰਮੀਨਲ ਵਿੰਡੋ ਵਿੱਚੋਂ ਖਿੱਚਿਆ ਸੰਵਾਦ ਨਹੀਂ।
ਪੁਰਾਣੀਆਂ ਸਲਾਹਾਂ ਵਿੱਚ ਦੋ ਬਦਲਾਅ ਇਕੱਠੇ ਬੰਨ੍ਹੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਦੋਵੇਂ ਬਹੁਤ ਖੁੱਲ੍ਹੇ ਹਨ। ਹਰ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਪ੍ਰਾਈਵੇਟ ਕੁੰਜੀ ਦੀ ਪਹੁੰਚ ਦੇਣਾ ਸਥਾਨਕ ਕੁੰਜੀ-ਵਰਤੋਂ ਨੂੰ ਲੋੜ ਤੋਂ ਕਾਫ਼ੀ ਅੱਗੇ ਵਧਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਨੂੰ Always Trust ’ਤੇ ਰੱਖਣਾ ਮਸ਼ੀਨ ਦੀ ਹਰ ਚੀਜ਼ ਲਈ ਸਰਟੀਫਿਕੇਟ ਮੁਲਾਂਕਣ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ “ਇਹ ਮਨਜ਼ੂਰਸ਼ੁਦਾ VPN ਅਮਲ, ਇਹੋ ਇਛਿਤ ਪਛਾਣ ਵਰਤਦਿਆਂ” ਨਹੀਂ ਕਹਿੰਦਾ।
ਗੇਟਵੇ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਜਾਂਚੋ
ਸੁਧਾਰ ਤੋਂ ਬਾਅਦ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਥਾਨਕ ਕਿਰਿਆ ਸਫਲ ਹੁੰਦੀ ਹੈ ਦੂਜੇ ਪਾਸਿਓਂ ਆਏ ਕਿਸੇ ਵੀ ਜਵਾਬ ਦੀ ਵਿਆਖਿਆ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ। ਜੇ ਹੁਣ ਦਸਤਖ਼ਤ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਨਾਮ, ਚੇਨ ਜਾਂ ਕਲਾਇੰਟ-ਦਾਖ਼ਲੇ ਦਾ ਨਾਮਨਜ਼ੂਰ ਹੋਣਾ ਨਵਾਂ ਨਤੀਜਾ ਹੈ, ਦੁਹਰਾਉ ਨਹੀਂ, ਅਤੇ ਉਹ ਵੱਖਰੇ ਜ਼ਿੰਮੇਵਾਰ ਵਾਲੇ ਵੱਖਰੇ ਫੈਸਲੇ ਦਾ ਹੈ।
ਲਾਭਦਾਇਕ ਹੈਂਡਓਫ਼ ਦੱਸਦਾ ਹੈ ਕਿ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਫੈਸਲਾ ਫੇਲ੍ਹ ਹੋਇਆ ਅਤੇ ਉੱਥੇ ਹੀ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਕਦੇ ਪ੍ਰਾਈਵੇਟ ਕੁੰਜੀ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਇਹ ਕਦੇ ਵੀ ਸਾਫ਼ ਸਥਿਤੀ ਮਦਦ ਕਰੇਗੀ ਦੀ ਆਸ ਨਾਲ਼ ਅਸੰਬੰਧਿਤ ਕੀਚੇਨ ਚੀਜ਼ਾਂ ਰੀਸੈਟ ਨਹੀਂ ਕਰਦਾ। ਉਹ ਦੋ ਆਦਤਾਂ ਘਟਨਾ ਵੇਲੇ ਨਹੀਂ, ਸਗੋਂ ਪਹਿਲਾਂ ਹੀ ਤੈਅ ਕਰੋ, ਕਿਉਂਕਿ ਸਭ ਕੁਝ ਇਕੱਠਾ ਆਜ਼ਮਾਉਣ ਦਾ ਲਾਲਚ ਤਦੋਂ ਸਭ ਤੋਂ ਪ੍ਰਬਲ ਹੁੰਦਾ ਹੈ। “ਕੀਚੇਨ ਦੁਬਾਰਾ ਬਣਾਇਆ” ਕਹਿਣ ਵਾਲੀ ਟਿਕਟ ਅਗਲੇ ਪਾਠਕ ਨੂੰ ਮੂਲ ਖ਼ਰਾਬੀ ਬਾਰੇ ਲਗਭਗ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ।