ਸੱਠ ਸਕਿੰਟਾਂ ਦਾ TLS ਸਮਾਂ ਸੀਮਾ: ਕਿਹੜਾ ਪਾਸਾ ਅਸਲ ਵਿੱਚ ਰੁਕਿਆ?

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

ਇੱਕ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਅਜਿਹੀ ਪਛਾਣ ਦਿਓ ਜੋ ਤੁਸੀਂ ਖੋਜ ਸਕੋ

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

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

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

ਚਾਰ ਨਿਰੀਖਣ, ਚਾਰ ਵੱਖਰੇ ਅਗਲੇ ਕਦਮ

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

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

ਆਪਣੀਆਂ ਨੋਟਾਂ ਵਿੱਚ ਚਾਰੇ ਨਤੀਜੇ ਵੱਖਰੇ ਰੱਖੋ। ਲਾਲਚ ਇਹ ਹੈ ਕਿ ਇਨ੍ਹਾਂ ਨੂੰ “ਸਰਵਰ ਜਵਾਬ ਨਹੀਂ ਦੇ ਰਿਹਾ” ਵਿੱਚ ਮਿਲਾ ਦਿੱਤਾ ਜਾਵੇ, ਅਤੇ ਜਦੋਂ ਅਸਲ ਸਮੱਸਿਆ ਫਾਇਰਵਾਲ ਨਿਯਮ ਹੁੰਦੀ ਹੈ ਤਾਂ ਲੋਕਾਂ ਨੂੰ ਸਾਈਫਰ ਬਦਲਣ ਭੇਜਣ ਵਾਲਾ ਇਹੀ ਵਾਕ ਹੁੰਦਾ ਹੈ। ਜੋ ਨੋਟ ਸਿਰਫ਼ ਸਮਾਂ ਸੀਮਾ ਸ਼ਬਦ ਦਰਜ ਕਰਦਾ ਹੈ, ਉਸ ਨੇ ਉਹ ਫ਼ਰਕ ਸੁੱਟ ਦਿੱਤਾ ਜਿਸ ਲਈ ਤੁਸੀਂ ਹੁਣੇ ਕੀਮਤ ਦਿੱਤੀ ਸੀ।

ਜਿਸ ਪੜਾਅ ਦਾ ਨਾਮ ਸਬੂਤ ਲੈਂਦੇ ਹਨ, ਉਸ ਨੂੰ ਠੀਕ ਕਰੋ

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

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

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

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

ਵਿੰਡੋ ਵਧਾਉਣ ਨਾਲ ਅਸਲ ਵਿੱਚ ਕੀ ਬਦਲਦਾ ਹੈ

ਸੱਠ ਸਕਿੰਟ ਕਲਾਇੰਟ ਦੀ ਹੈਂਡਸ਼ੇਕ ਵਿੰਡੋ ਹੈ, ਅਤੇ ਕਮਿਊਨਿਟੀ ਕਲਾਇੰਟ ਸੰਦਰਭ ਉਸ ਵਿਕਲਪ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ ਜੋ ਇਸ ਨੂੰ ਸਮਾਯੋਜਿਤ ਕਰਦਾ ਹੈ। ਇਸ ਨੂੰ ਵਧਾਉਣ ਨਾਲ ਕਲਾਇੰਟ ਹਾਰ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਵਧੇਰੇ ਸਮਾਂ ਉਡੀਕਦਾ ਹੈ। ਇਹ ਗੈਰਹਾਜ਼ਰ ਸੇਵਾ ਨੂੰ ਪ੍ਰਗਟ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਇਨਕਾਰ ਕੀਤੇ ਪੈਕੇਟ ਨੂੰ ਸਵੀਕਾਰਯੋਗ ਨਹੀਂ ਬਣਾਉਂਦਾ।

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