opt-verify ਜੋੜਨ ਨਾਲ ਤੁਹਾਡੀ OpenVPN ਸਾਈਫਰ ਗਲਤੀ ਕਿਉਂ ਠੀਕ ਨਹੀਂ ਹੋਵੇਗੀ

ਤੁਹਾਨੂੰ opt-verify ਜੋੜਨ ਦਾ ਸੁਝਾਅ ਮਿਲਦਾ ਹੈ, ਤੁਸੀਂ ਲਾਈਨ ਜੋੜਦੇ ਹੋ, ਅਤੇ ਸਾਈਫਰ ਗਲਤੀ ਠੀਕ ਉੱਥੇ ਹੀ ਰਹਿੰਦੀ ਹੈ ਜਿੱਥੇ ਸੀ। ਇਹ ਨਤੀਜਾ ਅਨੁਮਾਨਿਤ ਹੈ, ਕਿਉਂਕਿ ਵਿਕਲਪ ਨੇ ਕਦੇ ਸਾਈਫਰ ਬਾਰੇ ਗੱਲਬਾਤ ਨਹੀਂ ਕੀਤੀ। ਇਹ ਵਿਕਲਪ-ਸੰਗਤੀ ਦੀ ਜਾਂਚ ਸੀ, 2.6 ਵਿੱਚ ਪੁਰਾਣੀ ਹੋਈ ਅਤੇ 2.7 ਵਿੱਚ ਹਟਾਈ ਗਈ, ਅਤੇ ਇਸ ਨਾਲ ਅਜੇ ਵੀ ਪਾਰਸ ਹੋਣ ਵਾਲੇ ਪ੍ਰੋਫਾਈਲ ਨੇ ਇਸ ਨਾਲ ਕੁਝ ਵੀ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ।

ਲਾਈਨ ਪਹਿਲਾਂ ਕੀ ਕਰਦੀ ਸੀ ਇਹ ਜਾਣਨਾ ਮਦਦਗਾਰ ਹੈ, ਇਹੀ ਗੁੰਮ ਹਿੱਸਾ ਹੈ ਅਜਿਹਾ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ। ਇਤਿਹਾਸ ਇਹ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ ਹੁਣ ਇਹ ਮਦਦ ਕਿਉਂ ਨਹੀਂ ਕਰ ਸਕਦੀ।

ਵਿਕਲਪ ਪਹਿਲਾਂ ਕੀ ਲਾਗੂ ਕਰਦਾ ਸੀ

2.6 ਦਾ ਦਸਤਾਵੇਜ਼ opt-verify ਨੂੰ ਪੁਰਾਣਾ ਦੱਸਦਾ ਹੈ ਅਤੇ ਪਹਿਲਾਂ ਦਾ ਵਿਵਹਾਰ ਬਿਆਨ ਕਰਦਾ ਹੈ: ਸਰਵਰ ਉਹਨਾਂ ਕਲਾਇੰਟਾਂ ਨੂੰ ਕੱਢ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੇ ਐਲਾਨੇ ਵਿਕਲਪ ਉਸਦੇ ਆਪਣੇ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ, ਡਿਵਾਈਸ ਦੀ ਕਿਸਮ ਅਤੇ MTU ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦਾ ਹੈ। ਉਹ ਜਾਂਚ ਵਿਕਲਪ-ਸੰਗਤੀ ਦੀ ਜਾਂਚ ਚਾਲੂ ਰਹਿਣ 'ਤੇ ਵੀ ਨਿਰਭਰ ਹੈ, ਇਸ ਲਈ disable-occ ਨਾਲ ਚੱਲਣ ਵਾਲੇ ਸਰਵਰ ਕੋਲ ਇਹ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਨਹੀਂ ਸੀ। ਧਿਆਨ ਦਿਓ ਕਿ ਤੁਲਨਾ ਕਿਸ ਤੋਂ ਬਣੀ ਹੈ: ਸਾਹਮਣੇ ਵਾਲੇ ਧਿਰ ਦੀ ਸੰਰਚਨਾ ਦਾ ਵਰਣਨ ਕਰਨ ਵਾਲਾ ਪਾਠ। ਇਹ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਡੇਟਾ ਚੈਨਲ ਕਿਹੜਾ ਸਾਈਫਰ ਵਰਤੇਗਾ।

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

2.7 ਲਾਈਨ ਦੇਖ ਕੇ ਕੀ ਕਰਦਾ ਹੈ

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

ਇਸ ਲਈ ਪਾਰਸ ਹੋਣ ਵਾਲਾ ਪ੍ਰੋਫਾਈਲ ਕਿਸੇ ਪ੍ਰਵੇਸ਼ ਜਾਂਚ ਦੇ ਹੋਣ ਦਾ ਸਬੂਤ ਨਹੀਂ। ਜੇ ਤੁਹਾਡਾ ਇੱਕੋ ਸੰਕੇਤ ਇਹ ਹੈ ਕਿ ਕਲਾਇੰਟ ਜੁੜਿਆ, ਤਾਂ ਤੁਸੀਂ ਜਾਣਿਆ ਕਿ ਵਾਕ-ਰਚਨਾ ਸਵੀਕਾਰ ਹੋਈ।

ਅਸਫਲਤਾ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ

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

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

ਸਿਰਫ਼ ਲਾਈਨ ਨਹੀਂ, ਇਰਾਦਾ ਬਦਲੋ

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

ਸਾਰੇ ਸਾਈਫਰ ਬੰਦ ਹਨ ਇਸ ਪੁਰਾਣੇ ਸੁਝਾਅ ਦਾ ਜਵਾਬ ਹਰ ਇਤਿਹਾਸਕ ਐਲਗੋਰਿਦਮ ਚਾਲੂ ਕਰਕੇ ਨਾ ਦਿਓ।

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

ਲਕਸ਼ ਸਮਰਥਿਤ ਪਾਬੰਦੀ ਅਤੇ ਕੰਮ ਕਰਨ ਵਾਲਾ ਪ੍ਰਮਾਣਿਤ ਰਾਹ ਹੈ, ਅਜੇ ਵੀ ਪਾਰਸ ਹੋਣ ਵਾਲਾ ਪੁਰਾਣਾ ਫਲੈਗ ਨਹੀਂ।