8192-ਬਿੱਟ ਕੁੰਜੀਆਂ ਹੈਂਡਸ਼ੇਕ ਰੋਕਦੀਆਂ ਹਨ; 1024-ਬਿੱਟ DH ਰੱਦ ਹੁੰਦਾ ਹੈ
ਵਿਰੋਧੀ ਸੁਧਾਰਾਂ ਵਾਲੀਆਂ ਦੋ ਆਕਾਰ ਗਲਤੀਆਂ: ਬਹੁਤ ਵੱਡੀ ਕੁੰਜੀ ਸਾਹਮਣੇ ਵਾਲੇ ਧਿਰ ਦੀ ਸਮਾਂ-ਸੀਮਾ ਖਤਮ ਹੋਣ ਤੱਕ ਹੈਂਡਸ਼ੇਕ ਦਾ ਸਮਾਂ ਸਾੜਦੀ ਹੈ, ਜਦਕਿ ਛੋਟਾ DH ਗਰੁੱਪ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਰੱਦ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਸਰਵਰ ਵਿੱਚ ਕਲਾਇੰਟ ਥੋੜ੍ਹੀ ਦੇਰ ਅਟਕਦੇ ਹਨ ਅਤੇ ਫਿਰ ਮੁੜ ਜੁੜਦੇ ਹਨ, ਅਤੇ ਦੂਜਾ ਕੁੰਜੀ ਦੇ ਆਕਾਰ ਬਾਰੇ ਸੁਨੇਹੇ ਨਾਲ ਕਨੈਕਸ਼ਨ ਤੁਰੰਤ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਹ ਵੱਖਰੀਆਂ ਬੱਗਾਂ ਵਾਂਗ ਲੱਗਦੀਆਂ ਹਨ ਅਤੇ ਇਹੀ ਬੱਗ ਵਿਰੋਧੀ ਦਿਸ਼ਾਵਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ। ਹੈਂਡਸ਼ੇਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਦਾ ਖਰਚਾ ਪੈਰਾਮੀਟਰ ਦੇ ਆਕਾਰ ਨਾਲ ਵਧਦਾ ਹੈ, ਅਤੇ ਇਸਦੀ ਇੱਕ ਹੇਠਲੀ ਹੱਦ ਵੀ ਹੈ ਜਿਸ ਤੋਂ ਹੇਠਾਂ ਆਧੁਨਿਕ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨਹੀਂ ਜਾਂਦੀਆਂ। ਸਮੱਗਰੀ ਦਾ ਆਕਾਰ ਤੈਅ ਕਰਨਾ ਹੀ ਚੈੱਕਲਿਸਟ ਹੈ, ਅਤੇ ਪਹਿਲਾ ਨੁਕਤਾ ਇਹ ਤੈਅ ਕਰਨਾ ਹੈ ਕਿ ਦੋ ਗਲਤੀਆਂ ਵਿੱਚੋਂ ਕਿਹੜੀ ਸੱਚਮੁੱਚ ਤੁਹਾਡੇ ਕੋਲ ਹੈ।
ਕੁਝ ਵੀ ਮੁੜ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸਫਲਤਾ ਪੜ੍ਹੋ
ਸਮਾਂ ਤੁਹਾਨੂੰ ਇਸਦਾ ਬਹੁਤਾ ਹਿੱਸਾ ਦੱਸ ਦਿੰਦਾ ਹੈ। ਕੁਝ ਸਕਿੰਟ ਲੈ ਕੇ ਫਿਰ ਮਰਨ ਵਾਲਾ ਹੈਂਡਸ਼ੇਕ ਆਮ ਤੌਰ 'ਤੇ ਭਾਵ ਹੈ ਕਿ ਗਣਨਾ ਸਾਹਮਣੇ ਵਾਲੇ ਧਿਰ ਦੇ ਸਬਰ ਤੋਂ ਵੱਧ ਗਈ, ਜੋ ਹਾਰਡਵੇਅਰ ਜਾਂ ਸਮਾਂ-ਸੀਮਾ ਲਈ ਬਹੁਤ ਵੱਡੇ ਪੈਰਾਮੀਟਰਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਕੁੰਜੀ ਜਾਂ ਗਰੁੱਪ ਦਾ ਆਕਾਰ ਦੱਸਣ ਵਾਲਾ ਤੁਰੰਤ ਇਨਕਾਰ ਦੂਜੀ ਦਿਸ਼ਾ ਵੱਲ, ਉਸ ਸਮੱਗਰੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਲਾਇਬ੍ਰੇਰੀ ਬਿਲਕੁਲ ਨਹੀਂ ਸਵੀਕਾਰੇਗੀ।
ਇਹਨਾਂ ਦੋਵਾਂ ਨੂੰ ਵਿਰੋਧੀ ਸੁਧਾਰ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਇੱਥੇ ਹੀ ਬਹੁਤੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਗਲਤ ਹੁੰਦੀਆਂ ਹਨ। ਜਿਸ ਕਲਾਇੰਟ ਨੇ ਪਹਿਲਾਂ ਹੀ ਛੋਟਾ ਗਰੁੱਪ ਰੱਦ ਕੀਤਾ ਹੈ, ਉਸ ਉੱਤੇ 8192-ਬਿੱਟ ਪੈਰਾਮੀਟਰ ਮੁੜ ਬਣਾਉਣਾ ਹੌਲੀ ਕੇਸ ਨੂੰ ਹੋਰ ਮਾੜਾ ਕਰਦਾ ਹੈ ਅਤੇ ਤੇਜ਼ ਕੇਸ ਲਈ ਕੁਝ ਨਹੀਂ ਕਰਦਾ। ਕਿਸੇ ਫਾਈਲ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਲੱਛਣ ਦੇਖਿਆ।
ਫਿਰ ਦੇਖੋ ਕਿ ਸਾਹਮਣੇ ਵਾਲੇ ਧਿਰ ਤੋਂ ਕੀ ਮੰਗਿਆ ਜਾ ਰਿਹਾ ਹੈ। ਵੱਡੇ ਸੀਮਿਤ-ਖੇਤਰ ਗਰੁੱਪ ਲਈ ਸੈੱਟ ਕੀਤਾ ਸਰਵਰ ਹਰ ਕਲਾਇੰਟ ਨੂੰ ਸਿਰਫ਼ ਜੁੜਨ ਵੇਲੇ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਹਰ ਮੁੜ ਗੱਲਬਾਤ ਵੇਲੇ ਵੀ ਉਹੀ CPU ਸਮਾਂ ਖਰਚ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। ਜੇ ਸਮੱਸਿਆ ਸ਼ੁਰੂ ਵਿੱਚ ਨਹੀਂ ਸਗੋਂ ਨਿਯਮਿਤ ਅੰਤਰਾਲ 'ਤੇ ਦਿਖੇ, ਤਾਂ ਉਹ ਅੰਤਰਾਲ ਇਸ ਗੱਲ ਦਾ ਮਜ਼ਬੂਤ ਸੰਕੇਤ ਹੈ ਕਿ ਕਿਹੜੀ ਸੈਟਿੰਗ ਮਹਿੰਗੀ ਹੈ। ਮੁੜ ਗੱਲਬਾਤ ਪੂਰੀ ਗਣਨਾ ਦੁਹਰਾਉਂਦੀ ਹੈ, ਇਸ ਲਈ ਹਰ ਘੰਟੇ ਪਰਤਣ ਵਾਲਾ ਰੁਕਾਵਟ ਆਮ ਤੌਰ 'ਤੇ ਉਹੀ ਖਰਚਾ ਦੁਬਾਰਾ ਭਰਨਾ ਹੈ।
ਹੌਲੀ ਕੇਸ: ਹਾਰਡਵੇਅਰ ਜੋ ਖਰਚ ਨਹੀਂ ਸਕਦਾ
Diffie-Hellman ਅਤੇ RSA ਦਾ ਕੰਮ ਕੁੰਜੀ ਦੇ ਆਕਾਰ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦਾ ਹੈ, ਅਤੇ ਇਹ ਸਭ ਟਨਲ ਵਿੱਚ ਕੋਈ ਟ੍ਰੈਫਿਕ ਵਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਹੁੰਦਾ ਹੈ। ਛੋਟੇ ਰਾਊਟਰ ਜਾਂ ਘੱਟ ਸ਼ਕਤੀ ਵਾਲੇ ਕਲਾਇੰਟ 'ਤੇ ਕਾਫ਼ੀ ਵੱਡਾ ਗਰੁੱਪ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਨੂੰ ਦੂਜੇ ਪਾਸੇ ਦੀ ਸਮਾਂ-ਸੀਮਾ ਤੋਂ ਅੱਗੇ ਧੱਕ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਕਨੈਕਸ਼ਨ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਜਾਂ ਬਿਨਾਂ ਕਿਸੇ ਗਲਤੀ ਦੇ ਬੱਸ ਅਟਕਿਆ ਦਿਖਦਾ ਹੈ।
ਸੁਧਾਰ ਇਹ ਹੈ ਕਿ ਉਸ ਆਕਾਰ 'ਤੇ ਆਓ ਜਿਸਨੂੰ ਹਰ ਧਿਰ ਸਮਰਥਨ ਦਿੰਦੀ ਹੈ ਅਤੇ ਹਰ ਡਿਵਾਈਸ ਆਰਾਮ ਨਾਲ ਗਣਨਾ ਕਰ ਸਕਦੀ ਹੈ। 2048-ਬਿੱਟ RSA ਕੁੰਜੀ ਅਤੇ 2048-ਬਿੱਟ ਗਰੁੱਪ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਅਨੁਕੂਲ ਆਧਾਰ-ਰੇਖਾ ਰਹਿੰਦੇ ਹਨ; ਵੱਡਾ ਕਰਨਾ ਸਿਰਫ਼ ਤਦ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਸਾਰੇ ਧਿਰ ਸਹਿਮਤ ਹੋਣ ਅਤੇ ਪ੍ਰੋਸੈਸਰ ਹਰ ਮੁੜ ਗੱਲਬਾਤ 'ਤੇ ਇਸਦਾ ਖਰਚਾ ਚੁੱਕ ਸਕੇ। ਉਸ ਆਧਾਰ-ਰੇਖਾ ਤੋਂ ਉੱਪਰ ਸਭ ਕੁਝ ਜਾਣ-ਬੁੱਝ ਕੇ ਕੀਤਾ ਸੌਦਾ ਹੈ, ਅਪਗ੍ਰੇਡ ਨਹੀਂ।
ਆਕਾਰ ਕੋਈ ਸਕੋਰ ਨਹੀਂ ਹੈ, ਅਤੇ ਤੁਲਨਾ ਸਾਰਣੀ ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਸੰਖਿਆ ਆਪਣੇ ਆਪ ਸਹੀ ਚੋਣ ਨਹੀਂ ਹੁੰਦੀ। ਤੁਹਾਡੀ ਨੀਤੀ ਜੋ ਸਭ ਤੋਂ ਛੋਟਾ ਮੁੱਲ ਮਨਜ਼ੂਰ ਕਰਦੀ ਹੈ ਅਤੇ ਸਾਰੇ ਧਿਰ ਜੋ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ ਉਹ ਚੁਣੋ, ਫਿਰ ਸੁਧਰਿਆ ਮੰਨਣ ਦੀ ਥਾਂ ਹੈਂਡਸ਼ੇਕ ਮਾਪੋ। ਅਜੇ ਵੀ ਸਮਾਂ-ਸੀਮਾ ਪਾਰ ਕਰਨ ਵਾਲਾ ਛੋਟਾ ਗਰੁੱਪ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਆਕਾਰ ਕਦੇ ਵੀ ਪੂਰੀ ਕਹਾਣੀ ਨਹੀਂ ਸੀ।
ਤੇਜ਼ ਕੇਸ: ਲਾਇਬ੍ਰੇਰੀ ਜੋ ਗਰੁੱਪ ਰੱਦ ਕਰਦੀ ਹੈ
ਆਧੁਨਿਕ OpenSSL ਬਿਲਡ ਸਭ ਤੋਂ ਛੋਟੇ ਸੀਮਿਤ-ਖੇਤਰ ਗਰੁੱਪ ਸਿੱਧੇ ਰੱਦ ਕਰਦੇ ਹਨ, ਅਤੇ ਵਧਾਇਆ ਸੁਰੱਖਿਆ ਪੱਧਰ ਹੇਠਲੀ ਹੱਦ ਨੂੰ ਹੋਰ ਉੱਪਰ ਧੱਕਦਾ ਹੈ। ਦਹਾਕਿਆਂ ਪੁਰਾਣੀ ਪੈਰਾਮੀਟਰ ਫਾਈਲ ਲੈ ਕੇ ਆਉਣ ਵਾਲਾ ਰਾਊਟਰ ਫਰਮਵੇਅਰ ਆਮ ਸਰੋਤ ਹੈ, ਅਤੇ ਲੱਛਣ ਉਹ ਕਨੈਕਸ਼ਨ ਹੈ ਜੋ ਗਰੁੱਪ ਜਾਂ ਕੁੰਜੀ ਦਾ ਆਕਾਰ ਦੱਸਣ ਵਾਲੇ ਸੁਨੇਹੇ ਨਾਲ ਤੁਰੰਤ ਅਸਫਲ ਹੁੰਦਾ ਹੈ। ਉਸ ਅਸਫਲਤਾ ਵਿੱਚ ਕੁਝ ਵੀ ਰੁਕ-ਰੁਕ ਕੇ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਇਹੀ ਇਸਨੂੰ ਪਛਾਣਨਾ ਸੌਖਾ ਬਣਾਉਂਦਾ ਹੈ।
ਜਾਂਚ ਛੱਡਣ ਲਈ ਕੌਨਫਿਗਰੇਸ਼ਨ ਸੋਧਣ ਦੀ ਥਾਂ ਫਾਈਲ ਬਦਲੋ। ਮੌਜੂਦਾ ਗਰੁੱਪ ਬਣਾਓ, ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਇਸਨੂੰ ਉੱਥੇ ਲਗਾਓ ਜਿੱਥੇ ਡੈਮਨ ਸੱਚਮੁੱਚ ਇਸਨੂੰ ਪੜ੍ਹਦਾ ਹੈ। ਪੁਰਾਣੀ ਫਾਈਲ ਉਦੋਂ ਤੱਕ ਰੱਖੋ ਜਦੋਂ ਤੱਕ ਕਲਾਇੰਟ ਨਵੀਂ ਨਾਲ ਸਫਲਤਾਪੂਰਵਕ ਨਾ ਜੁੜ ਜਾਵੇ:
openssl dhparam -out /etc/openvpn/ffdhe2048.pem 2048
openssl dhparam -in /etc/openvpn/ffdhe2048.pem -check -noout
ls -l /etc/openvpn/ffdhe2048.pemਜਾਂਚ ਕਮਾਂਡ ਫਾਈਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ ਅਤੇ ਪਾਸ ਹੋਣ 'ਤੇ ਕੋਈ ਲਾਹੇਵੰਦ ਚੀਜ਼ ਨਹੀਂ ਛਾਪਦੀ; ਸੂਚੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਉਹ ਫਾਈਲ ਬਦਲੀ ਹੈ ਜੋ ਸੇਵਾ ਲੋਡ ਕਰਦੀ ਹੈ, ਨਾ ਕਿ ਨਾਲ ਵਾਲੀ ਪੁਰਾਣੀ ਕਾਪੀ। ਕੌਨਫਿਗਰੇਸ਼ਨ ਨੂੰ ਉਸ ਰਸਤੇ ਵੱਲ ਮੋੜੋ, ਡੈਮਨ ਮੁੜ ਚਾਲੂ ਕਰੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪਹਿਲਾਂ ਅਸਫਲ ਰਿਹਾ ਕਲਾਇੰਟ ਹੁਣ ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਕਰਦਾ ਹੈ।
ਜੇ ਸਰਵਰ ਸੁਰੱਖਿਆ ਪੱਧਰ ਜਾਂ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰੋਫਾਈਲ ਵੀ ਸੈੱਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਗਰੁੱਪ ਨੂੰ ਗਲਤ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਪੜ੍ਹੋ। ਵਧੇਰੇ ਸਖ਼ਤ ਸ਼੍ਰੇਣੀ ਮੰਗਣ ਵਾਲਾ ਪ੍ਰੋਫਾਈਲ ਅਜਿਹੀ ਸਮੱਗਰੀ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸਨੂੰ ਡਿਫਾਲਟ ਸਵੀਕਾਰ ਕਰਦਾ, ਅਤੇ ਉਹ ਸੈਟਿੰਗ ਹਟਾਉਣਾ ਜਾਂਚ ਨੂੰ ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਬੰਦ ਕਰਨ ਨਾਲੋਂ ਸੰਕਰਾ ਬਦਲਾਅ ਹੈ।
ਸਾਹਮਣੇ ਵਾਲੀ ਧਿਰ ਅਤੇ ਹਾਰਡਵੇਅਰ ਲਈ ਆਕਾਰ ਚੁਣੋ
ਕੁਝ ਅਜੀਬ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਕਰੋ ਕਿ ਦੂਰ ਵਾਲਾ ਸਿਰਾ ਕੀ ਸਹਿ ਸਕਦਾ ਹੈ। 2048-ਬਿੱਟ ਗਰੁੱਪ ਲਈ ਬਹੁਤ ਪੁਰਾਣਾ ਡਿਵਾਈਸ ਬਦਲਣ ਯੋਗ ਡਿਵਾਈਸ ਹੈ, ਕਿਉਂਕਿ ਸਰਵਰ ਨੂੰ ਕਮਜ਼ੋਰ ਗਰੁੱਪ ਵੱਲ ਮੋੜਨਾ ਸਿਰਫ਼ ਅਨੁਕੂਲਤਾ ਦੀ ਸ਼ਿਕਾਇਤ ਨੂੰ ਰੁਕਾਵਟ ਵਿੱਚ ਬਦਲਦਾ ਹੈ। ਟਿਕਾਊ ਸੁਧਾਰ ਪੁਰਾਣੇ ਪੈਰਾਮੀਟਰਾਂ ਵੱਲ ਨਹੀਂ, ਨਵੇਂ ਸਾਫਟਵੇਅਰ ਵੱਲ ਵਧਦੇ ਹਨ। ਇਸ ਖੇਤਰ ਦਾ ਹਰ ਅਸਥਾਈ ਅਪਵਾਦ ਸਥਾਈ ਕੌਨਫਿਗਰੇਸ਼ਨ ਬਣਨ ਦਾ ਰਾਹ ਲੱਭ ਲੈਂਦਾ ਹੈ।
ਜਿੱਥੇ ਸਰਵਰ ਦਾ CPU ਹੱਦ ਹੈ, ਉੱਥੇ ਨੀਤੀ ਤੋਂ ਹੇਠਾਂ ਉਤਰਨ ਦੀ ਥਾਂ ਐਲਗੋਰਿਦਮ ਬਦਲੋ। X25519 ਵਰਗਾ ਅੰਡਾਕਾਰ ਵਕਰ ਕੁੰਜੀ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਵੱਡੇ ਸੀਮਿਤ-ਖੇਤਰ ਗਰੁੱਪ ਨਾਲੋਂ ਨਾਟਕੀ ਤੌਰ 'ਤੇ ਸਸਤਾ ਹੈ ਅਤੇ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਸਮਰਥਿਤ ਹੈ, ਜੋ ਇਸਨੂੰ ਛੋਟੇ RSA ਮਾਡਿਊਲਸ ਨਾਲੋਂ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਸ਼ਿਕਾਇਤ ਦਾ ਬਿਹਤਰ ਜਵਾਬ ਬਣਾਉਂਦਾ ਹੈ।
ਤੁਸੀਂ ਜੋ ਵੀ ਚੁਣੋ, ਇੱਕ ਅਸਲੀ ਕਨੈਕਸ਼ਨ ਨਾਲ ਪਰਖੋ ਅਤੇ ਦੇਖੋ ਕਿ ਹੈਂਡਸ਼ੇਕ ਕਿੰਨਾ ਸਮਾਂ ਲੈਂਦਾ ਹੈ, ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਕਿ ਅੰਤ ਵਿੱਚ ਜੁੜਦਾ ਹੈ। ਬਾਰਾਂ ਸਕਿੰਟਾਂ ਵਿੱਚ ਸਫਲ ਹੋਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਦਾ ਮੂਲ ਕਾਰਨ ਪੰਦਰਾਂ ਵਿੱਚ ਅਸਫਲ ਹੋਣ ਵਾਲੇ ਵਰਗਾ ਹੀ ਹੈ।
ਪੁਨਰਨਿਰਮਾਣ ਇਸਨੂੰ ਰੱਦ ਨਾ ਕਰ ਸਕੇ ਇਸ ਲਈ ਚੋਣ ਦਰਜ ਕਰੋ
ਪੈਰਾਮੀਟਰ ਫਾਈਲ ਨੂੰ ਕੌਨਫਿਗਰੇਸ਼ਨ ਪ੍ਰਬੰਧਨ ਹੇਠ ਰੱਖੋ ਅਤੇ ਨਾਲ ਆਕਾਰ, ਕਾਰਨ ਅਤੇ ਤਾਰੀਖ ਲਿਖੋ। ਆਪਣੇ ਡਿਫਾਲਟ ਚੁੱਪਚਾਪ ਬਣਾਉਣ ਵਾਲਾ ਮੁੜ ਬਣਾਇਆ ਸਰਵਰ ਹੀ ਉਹੀ ਗਲਤੀ ਛੇ ਮਹੀਨੇ ਬਾਅਦ ਪਰਤਣ ਦਾ ਰਾਹ ਹੈ, ਅਤੇ ਮੂਲ ਫੈਸਲਾ ਕੋਈ ਨਹੀਂ ਸਮਝਾ ਸਕਦਾ।
ਉਹੀ ਜਾਣਕਾਰੀ ਐਂਡਪੌਇੰਟ ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਦੇ ਨਾਲ ਲਿਖੋ, ਤਾਂ ਜੋ ਸਮੀਖਿਆ ਨੂੰ ਇਸਨੂੰ ਫਾਈਲ ਦੇ ਆਕਾਰ ਤੋਂ ਮੁੜ ਨਾ ਬਣਾਉਣਾ ਪਵੇ। ਅਗਲਾ ਕਨੈਕਸ਼ਨ ਅਟਕਣ 'ਤੇ ਉਹ ਨੋਟ ਪੰਜ ਮਿੰਟ ਦੀ ਜਾਂਚ ਅਤੇ ਨਵੀਂ ਪੜਤਾਲ ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਹੈ। ਇਹ ਅਗਲੇ ਇੰਜੀਨੀਅਰ ਨੂੰ ਤੇਜ਼ ਕੇਸ ਲਈ ਬਣੇ ਸੁਧਾਰ ਨਾਲ ਹੌਲੀ ਕੇਸ ਹੱਲ ਕਰਨ ਤੋਂ ਵੀ ਰੋਕਦਾ ਹੈ।