ਗਲਤ VPN ਕੋਸ਼ਿਸ਼: ਕਿਹੜਾ ਪਛਾਣ-ਪੱਤਰ ਵਰਗ ਸੀਮਾ ਪਾਰ ਕਰ ਗਿਆ?

ਤੁਸੀਂ ਗਲਤ VPN ਨਾਲ ਜੁੜੇ ਅਤੇ ਕਲਾਇੰਟ ਨੇ ਅਸਫਲਤਾ ਦੀ ਰਿਪੋਰਟ ਦਿੱਤੀ। ਇਸ ਦਾ ਮਹੱਤਵ ਸੀ ਜਾਂ ਨਹੀਂ, ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਅਸਫਲਤਾ ਤੋਂ ਪਹਿਲਾਂ ਤਾਰ ਉੱਤੇ ਕੀ ਲੰਘਿਆ, ਅਤੇ ਸ਼ਬਦ ਆਪ ਇਹ ਨਹੀਂ ਦੱਸਦਾ। ਕੁਝ ਹੈਂਡਸ਼ੇਕ ਕੋਈ ਭੇਤ ਹੀ ਨਹੀਂ ਲੈ ਜਾਂਦੇ, ਜਦਕਿ ਹੋਰ ਉਸ ਪਤੇ ਨੂੰ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਹਰ ਵਿਅਕਤੀ ਨੂੰ ਪਾਸਵਰਡ ਦੇ ਦਿੰਦੇ ਹਨ। ਕੁਝ ਵੀ ਰੱਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਇਨ੍ਹਾਂ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੀ ਹੋਇਆ।

ਰੁਕੋ ਅਤੇ ਸਬੂਤ ਸੰਭਾਲੋ

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

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

ਸੀਮਾ ਪਾਰ ਕੀ ਜਾ ਸਕਦਾ ਹੈ

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

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

ਕੁੰਜੀ ਦਾ ਸਬੂਤ ਕੁੰਜੀ ਅੱਪਲੋਡ ਨਹੀਂ

ਆਧੁਨਿਕ TLS ਇਨ੍ਹਾਂ ਦੋ ਧਾਰਨਾਵਾਂ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਵੱਖ ਰੱਖਦਾ ਹੈ। RFC 8446 CertificateVerify ਸੁਨੇਹੇ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਜਿੱਥੇ ਕਲਾਇੰਟ ਆਪਣੇ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਨਿੱਜੀ ਕੁੰਜੀ ਨਾਲ ਚੁਣੌਤੀ ਉੱਤੇ ਦਸਤਖਤ ਕਰਦਾ ਹੈ। ਦਸਤਖਤ ਕੁੰਜੀ ਨੂੰ ਲਿਜਾਏ ਬਿਨਾਂ ਮਾਲਕੀ ਦਰਸਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਕੋਸ਼ਿਸ਼ ਆਪਣੇ ਆਪ ਕੁੰਜੀ ਦਾ ਭੇਦ ਨਹੀਂ ਹੈ।

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

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

ਲਾਗ ਤੋਂ ਕੋਸ਼ਿਸ਼ ਮੁੜ-ਬਣਾਓ

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

ਇਹ ਤੱਥ ਯਾਦ ਤੋਂ ਨਹੀਂ, ਕਲਾਇੰਟ ਦੀ ਆਪਣੀ ਲਾਗ ਤੋਂ ਕੱਢੋ। ਤੰਗ ਫਿਲਟਰ ਨਤੀਜੇ ਨੂੰ ਸੋਧਣ ਅਤੇ ਸਾਂਝਾ ਕਰਨ ਯੋਗ ਛੋਟਾ ਰੱਖਦਾ ਹੈ:

grep -n -i -E 'verify|authentication|certificate|error|timeout' client.log | tail -30

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

ਫੈਸਲਾ ਕਰੋ, ਫਿਰ ਕਾਰਵਾਈ ਕਰੋ

ਫੈਸਲਾ ਕਲਾਕ੍ਰਿਤ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਇਸ ਤੋਂ ਨਹੀਂ ਕਿ ਅਸਫਲਤਾ ਕਿੰਨੀ ਡਰਾਉਣੀ ਲੱਗੀ। ਮੁੜ-ਬਣਾਏ ਤੱਥਾਂ ਦੇ ਸਾਹਮਣੇ ਚਾਰੇ ਲਾਈਨਾਂ ਪੜ੍ਹੋ:

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

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