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

ਇਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤੇ ਟੁੱਟਣ ਲਈ ਦੋ ਵਿਧੀਆਂ ਜ਼ਿੰਮੇਵਾਰ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਵੱਖ ਕਰਨਾ ਹੀ ਕੰਮ ਹੈ।

ਤੁਹਾਡੇ ਹੇਠਾਂ ਗੱਲਬਾਤ ਵਿੱਚ ਕੀ ਬਦਲਿਆ

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

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

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

ਪ੍ਰੋਫਾਈਲ ਪਾਰਸ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਕੁਝ ਹੋਰ ਅਰਥ ਰੱਖ ਸਕਦੀ ਹੈ

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

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

openvpn --version | head -n 2
openvpn --show-ciphers | head -n 10
grep -nE '^(cipher|data-ciphers|ncp-|tls-)' office.ovpn

ਪਲੇਟਫਾਰਮ ਵੀ ਉਸੇ ਸਮੇਂ ਹਿੱਲਿਆ

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

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

ਜਿਸ ਘਟਨਾ ਨੇ ਰਿਪੋਰਟ ਸ਼ੁਰੂ ਕੀਤੀ ਉਸਨੂੰ ਦੁਬਾਰਾ ਜਾਂਚੋ

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

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

ਸੰਬੰਧਿਤ ਲੇਖ