OpenVPN ਪ੍ਰੋਫਾਈਲ ਵਿੱਚੋਂ key-method ਹਟਾਉਣ ਨਾਲ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ
ਇਹ ਨਿਰਦੇਸ਼ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚੋਂ ਨਹੀਂ, ਪਾਰਸਰ ਵਿੱਚੋਂ ਗਾਇਬ ਹੋਇਆ। ਪ੍ਰੋਫਾਈਲ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਰਾਣੇ ਵਿਕਲਪ ਨੂੰ ਕੁੰਜੀ-ਅਦਲ-ਬਦਲ ਫਾਰਮੈਟ ਤੋਂ ਵੱਖ ਕਰੋ।
ਸਾਲਾਂ ਤੋਂ ਚੱਲ ਰਿਹਾ ਪ੍ਰੋਫਾਈਲ ਅਚਾਨਕ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸੁਨੇਹਾ ਉਸ ਨਿਰਦੇਸ਼ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ ਜਿਸ ਨੂੰ ਕਿਸੇ ਨੂੰ ਵੀ ਜੋੜਨਾ ਯਾਦ ਨਹੀਂ: key-method. ਅਗਲਾ ਖੋਜ ਨਤੀਜਾ ਅਨੁਕੂਲਤਾ ਲਈ key-method 2 ਜੋੜਨ ਦੀ ਸਲਾਹ ਦਿੰਦਾ ਹੈ, ਜੋ ਕਿਸੇ ਹੋਰ ਯੁੱਗ ਦੀ ਸਲਾਹ ਹੈ। ਜਿਸ ਪਾਰਸਰ ਨੇ ਲਾਈਨ ਨੂੰ ਰੱਦ ਕੀਤਾ ਉਹ ਮੌਜੂਦਾ ਹੈ, ਅਤੇ ਉਸ ਵਿੱਚ ਅਜਿਹਾ ਕੋਈ ਵਿਕਲਪ ਹੀ ਨਹੀਂ। ਲਾਈਨ ਹਟਾਉਣ ਨਾਲ ਸ਼ੁਰੂਆਤ ਠੀਕ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਧਿਰਾਂ ਸੈਸ਼ਨ ਦੀ ਰੱਖਿਆ ਕਿਵੇਂ ਕਰਦੀਆਂ ਹਨ, ਇਸ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।
ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਕੀ ਹੈ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ, ਇਹਨਾਂ ਵਿਚਕਾਰਲਾ ਇਹ ਫਾਸਲਾ ਹੀ ਇੱਥੇ ਪੂਰਾ ਵਿਸ਼ਾ ਹੈ, ਅਤੇ ਇਹ ਉਹਨਾਂ ਕਈ ਹੋਰ ਸੋਧਾਂ ਨੂੰ ਵੀ ਸਮਝਾਉਂਦਾ ਹੈ ਜੋ ਲੋਕ ਇੱਕੋ ਸਮੇਂ ਕਰਦੇ ਹਨ। ਇਹ ਇਹ ਵੀ ਸਮਝਾਉਂਦਾ ਹੈ ਕਿ ਉਹ ਸੋਧਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕੋ ਬੰਡਲ ਵਿੱਚ ਕਿਉਂ ਆਉਂਦੀਆਂ ਹਨ।
ਲੱਛਣ ਪਾਰਸ ਤਰੁੱਟੀ ਹੈ, ਹੈਂਡਸ਼ੇਕ ਫੇਲ੍ਹ ਹੋਣਾ ਨਹੀਂ
ਕੋਈ ਵੀ ਪੈਕਟ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਵਿਕਲਪ ਪੜ੍ਹੇ ਜਾਂਦੇ ਹਨ। ਅਣਜਾਣ ਨਿਰਦੇਸ਼ ਵਾਲਾ ਪ੍ਰੋਫਾਈਲ ਉਸ ਪੜਾਅ 'ਤੇ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਪ੍ਰਕਿਰਿਆ ਕਦੇ ਨੈੱਟਵਰਕ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੀ ਅਤੇ ਕਦੇ ਹੈਂਡਸ਼ੇਕ ਤਰੁੱਟੀ ਪੈਦਾ ਨਹੀਂ ਕਰਦੀ। ਸ਼ਬਦਾਵਲੀ ਆਮ ਤੌਰ 'ਤੇ ਵਿਕਲਪ ਅਤੇ ਫਾਈਲ ਦੀ ਪਛਾਣ ਦਿੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਇਹ ਕਾਰਨ ਨਾਲ ਜੋੜਨ ਲਈ ਸਭ ਤੋਂ ਸੌਖੀਆਂ ਫੇਲ੍ਹਤਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਬਣ ਜਾਂਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਕੋਈ ਪੈਕਟ, ਰਸਤਾ ਜਾਂ ਫਾਇਰਵਾਲ ਸ਼ਾਮਲ ਨਹੀਂ।
openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log
ਜੇ ਸੁਨੇਹਾ ਨਿਰਦੇਸ਼ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਨਿਦਾਨ ਪੂਰਾ ਹੋ ਗਿਆ: ਫਾਈਲ ਵਿੱਚ ਕੁਝ ਅਜਿਹਾ ਹੈ ਜੋ ਇਹ ਬਿਲਡ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਦਾ। ਜੇ ਸੁਨੇਹਾ ਇਸ ਦੀ ਥਾਂ ਫਾਈਲ ਪਾਥ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਸਮੱਸਿਆ ਗੁੰਮ include ਜਾਂ ਕੁੰਜੀ ਹੈ, ਜੋ ਉਸੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ ਦਾ ਦੂਜਾ ਭਾਗ ਹੈ।
ਤੁਹਾਨੂੰ ਇਹ ਸਿੱਟਾ ਨਹੀਂ ਕੱਢਣਾ ਚਾਹੀਦਾ ਕਿ ਕਲਾਇੰਟ ਜਾਂ ਸਰਵਰ ਨੂੰ ਪੁਰਾਣੇ ਪ੍ਰੋਟੋਕੋਲ ਮੋਡ ਦੀ ਲੋੜ ਹੈ। ਪਾਰਸ ਫੇਲ੍ਹ ਹੋਣਾ ਤੁਹਾਡੀ ਫਾਈਲ ਅਤੇ ਬਾਈਨਰੀ ਵਿਚਕਾਰ ਸ਼ਬਦ-ਭੰਡਾਰ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਬਾਈਨਰੀ ਨੇ ਆਪਣੇ ਸ਼ਬਦ-ਭੰਡਾਰ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਸ਼ਬਦ ਛੱਡ ਦਿੱਤਾ ਹੈ।
ਨਿਰਦੇਸ਼ ਅਤੇ ਪ੍ਰਸਾਰਨ ਫਾਰਮੈਟ ਦੋ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਹਨ
ਪੁਰਾਣਾ key-method ਵਿਕਲਪ ਚੁਣਦਾ ਸੀ ਕਿ TLS ਕੁੰਜੀ-ਅਦਲ-ਬਦਲ ਕਿਵੇਂ ਫ੍ਰੇਮ ਕੀਤਾ ਜਾਵੇ, ਅਤੇ ਆਧੁਨਿਕ ਅਦਲ-ਬਦਲ ਉਹ ਬਹੁ-ਪੈਕਟ ਢੰਗ ਹੈ ਜੋ ਉਸ ਵਿਕਲਪ ਨੇ ਕਦੇ ਮੰਗਿਆ ਸੀ। ਵਿਕਲਪ ਚਲਾ ਗਿਆ ਕਿਉਂਕਿ ਇਹ ਹੁਣ ਕੁਝ ਵੀ ਨਹੀਂ ਚੁਣਦਾ ਸੀ; ਜਿਸ ਫਾਰਮੈਟ ਦਾ ਇਹ ਨਾਮ ਲੈਂਦਾ ਸੀ ਉਹੀ ਇਕੱਲਾ ਰਹਿ ਗਿਆ। ਇਸ ਲਈ ਲਾਈਨ ਹਟਾਉਣ ਨਾਲ ਸੈਸ਼ਨ ਪਹਿਲਾਂ ਵਾਂਗ ਹੀ ਉਸੇ ਫ੍ਰੇਮਿੰਗ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ। ਟੈਕਸਟ ਸੋਧ ਕਿਸੇ ਵੀ ਦਿਸ਼ਾ ਵਿੱਚ ਇਹ ਨਹੀਂ ਬਦਲ ਸਕਦੀ।
ਇਸੇ ਲਈ “ਢੰਗ 2 ਬਹਾਲ” ਕਰਨ ਲਈ ਪੁਰਾਣੀ ਬਾਈਨਰੀ ਵਾਪਸ ਲਿਆਉਣਾ ਗਲਤ ਮੁਰੰਮਤ ਹੈ। ਇਹ ਪੁਰਾਣੇ ਡਿਫਾਲਟਾਂ ਵਾਲੇ ਪੁਰਾਣੇ ਪਾਰਸਰ ਤੋਂ ਇਲਾਵਾ ਕੁਝ ਬਹਾਲ ਨਹੀਂ ਕਰਦੀ, ਅਤੇ ਇਸ ਤੋਂ ਬਾਅਦ ਆਈਆਂ ਸੋਧਾਂ ਤੁਹਾਡੇ ਤੋਂ ਖੋਹ ਲੈਂਦੀ ਹੈ। ਇਹੀ ਤਰਕ ਸਰਟੀਫਿਕੇਟ ਜਾਂਚ ਜਾਂ ਸਾਈਫਰ ਸੂਚੀ ਨੂੰ ਕਮਜ਼ੋਰ ਕਰਨ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਇਸ ਆਸ ਵਿੱਚ ਕਿ ਕਨੈਕਸ਼ਨ ਵਾਪਸ ਆ ਜਾਵੇਗਾ।
ਲਾਭਦਾਇਕ ਜਾਂਚ ਸੰਸਕਰਣ ਅਤੇ ਪਾਰਸ ਕੀਤੀ ਸੰਰਚਨਾ ਹੈ, ਫਾਈਲ ਵਿੱਚ ਸ਼ਬਦ ਦੀ ਮੌਜੂਦਗੀ ਨਹੀਂ:
openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null
ਕੀ ਹਟਾਉਣਾ ਹੈ, ਅਤੇ ਕਿਹੜੀ ਫਾਈਲ ਤੋਂ
ਚੱਲ ਰਹੀ ਪ੍ਰਕਿਰਿਆ ਅਸਲ ਵਿੱਚ ਜਿਹੜੀ ਫਾਈਲ ਪੜ੍ਹਦੀ ਹੈ, ਸਿਰਫ਼ ਉਹੀ ਸੋਧੋ। ਪੈਕੇਜ ਕੀਤੇ ਸਿਸਟਮਾਂ ਵਿੱਚ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਯੂਨਿਟ ਵੱਲੋਂ ਦੱਸੀ ਕਲਾਇੰਟ ਜਾਂ ਸਰਵਰ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚਲਾ ਪ੍ਰੋਫਾਈਲ ਹੁੰਦਾ ਹੈ, ਤੁਹਾਡੀ ਹੋਮ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਹਵਾਲੇ ਲਈ ਰੱਖੀ ਕਾਪੀ ਨਹੀਂ। ਤਿਆਰ ਕੀਤਾ ਪ੍ਰੋਫਾਈਲ ਟੈਂਪਲੇਟ ਤੋਂ ਦੁਬਾਰਾ ਬਣ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਸਿਰਫ਼ ਤੈਨਾਤ ਕੀਤੀ ਕਾਪੀ ਵਿੱਚ ਕੀਤਾ ਬਦਲਾਅ ਅਗਲੀ ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ ਦੌੜ ਤੋਂ ਬਾਅਦ ਵਾਪਸ ਆ ਜਾਵੇਗਾ।
ਪੁਰਾਣੀ ਲਾਈਨ ਮਿਟਾਓ ਅਤੇ ਐਂਡਪੌਇੰਟ, ਸਰਟੀਫਿਕੇਟ, ਸਾਈਫਰ ਨੀਤੀ ਅਤੇ ਕੰਟਰੋਲ-ਚੈਨਲ ਸੈਟਿੰਗਾਂ ਨੂੰ ਅਛੂਤਾ ਰਹਿਣ ਦਿਓ। ਇਹ ਪ੍ਰਕਿਰਿਆ ਲਈ ਲੋੜੀਂਦੇ ਸਮਰਥਿਤ ਵਿਕਲਪ ਹਨ ਅਤੇ ਪਾਰਸ ਤਰੁੱਟੀ ਨਾਲ ਜੁੜੇ ਨਹੀਂ ਹਨ। ਜੇ ਉਸੇ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਤੁਹਾਡੇ ਲਈ ਅਣਜਾਣ ਹੋਰ ਨਿਰਦੇਸ਼ ਹਨ, ਤਾਂ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਹੋਣ ਤੱਕ ਉਹਨਾਂ ਦਾ ਸਮੂਹ ਮਿਟਾਉਣ ਦੀ ਥਾਂ ਹਰੇਕ ਨੂੰ ਤੁਹਾਡੇ ਚਲਾਏ ਸੰਸਕਰਣ ਨਾਲ ਮਿਲਾਓ।
ਫਿਰ ਇੱਛਤ ਇੰਸਟੈਂਸ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਉਸ ਦਾ ਸ਼ੁਰੂਆਤੀ ਆਉਟਪੁੱਟ ਪੜ੍ਹੋ। ਸਰੋਤਾ ਮੌਜੂਦ ਹੁੰਦਿਆਂ ਸਾਫ਼ ਸ਼ੁਰੂਆਤ ਹੀ ਇਸ ਪੜਾਅ ਦੇ ਪੂਰਾ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਹੈ; ਉਸ ਤੋਂ ਬਾਅਦ ਦੀ ਕਲਾਇੰਟ ਪਰਖ ਕਿਸੇ ਹੋਰ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ।
ਰੱਦ ਕੀਤਾ ਪ੍ਰੋਫਾਈਲ ਅਤੇ ਰੱਦ ਕੀਤਾ ਕਲਾਇੰਟ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ
ਦੋ ਫੇਲ੍ਹਤਾਵਾਂ ਸਮਾਨ ਸਹਾਇਤਾ ਥ੍ਰੈਡ ਬਣਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਵੱਖਰੇ ਸਬੂਤ ਮੰਗਦੀਆਂ ਹਨ। ਆਪਣੀ ਹੀ ਸੰਰਚਨਾ ਰੱਦ ਕਰਨ ਵਾਲਾ ਸਰਵਰ ਕਦੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ ਕੋਈ ਵੀ ਕਲਾਇੰਟ ਉਸ ਨਾਲ ਜੁੜ ਨਹੀਂ ਸਕਦਾ। ਚੰਗੀ ਤਰ੍ਹਾਂ ਸ਼ੁਰੂ ਹੋ ਕੇ ਇੱਕ ਕਲਾਇੰਟ ਨੂੰ ਰੱਦ ਕਰਨ ਵਾਲਾ ਸਰਵਰ ਚੱਲ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਸ ਦੇ ਲਾਗ ਵਿੱਚ ਕਾਰਨ ਹੁੰਦਾ ਹੈ: ਸਰਟੀਫਿਕੇਟ ਦੀ ਸਮੱਸਿਆ, ਕਲਾਇੰਟ ਵੱਲੋਂ ਨਾ-ਸਵੀਕਾਰਿਆ ਧੱਕਿਆ ਵਿਕਲਪ, ਸਾਈਫਰ ਦਾ ਮੇਲ ਨਾ ਖਾਣਾ।
ਹਟਾਇਆ ਵਿਕਲਪ ਦੂਜੇ ਮਾਮਲੇ ਲਈ ਨਿਦਾਨ ਨਹੀਂ ਹੈ, ਅਤੇ ਉਸ ਵੱਲ ਹੱਥ ਵਧਾਉਣਾ ਉਹੀ ਘੰਟਾ ਦੋ ਵਾਰ ਬਰਬਾਦ ਕਰਦਾ ਹੈ। ਜੇ ਕਲਾਇੰਟ ਲਾਗ ਸਰਵਰ ਦਾ ਰੱਦ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਰੱਦ ਪੜ੍ਹੋ; ਜੇ ਸਥਾਨਕ ਤਰੁੱਟੀ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਜਾਂਚਣ ਵਾਲੀ ਫਾਈਲ ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਈਲ ਹੈ। ਹੁਣ ਨਾ ਰਹੇ ਨਿਰਦੇਸ਼ ਵੱਲ ਹੱਥ ਵਧਾਉਣਾ ਦੋਵੇਂ ਜਾਂਚਾਂ ਨੂੰ ਉੱਨਾ ਹੀ ਦੇਰ ਕਰਦਾ ਹੈ।
ਅਨੁਕੂਲਤਾ ਦੇ ਉਹ ਸਵਾਲ ਜਿਹਨਾਂ ਦਾ ਜਵਾਬ ਲਾਈਨ ਨੇ ਕਦੇ ਨਹੀਂ ਦਿੱਤਾ
ਇਸ ਨਿਰਦੇਸ਼ ਨਾਲ ਘੁੰਮਦੇ ਪ੍ਰੋਫਾਈਲ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਖਾਸ ਪਲੇਟਫਾਰਮ ਦੀ ਕਹਾਣੀ ਲੈ ਕੇ ਆਉਂਦੇ ਹਨ, ਅਤੇ ਕਹਾਣੀ ਤਕਨੀਕੀ ਕਾਰਨ ਤੋਂ ਵੱਧ ਚਿਰ ਜਿਉਂਦੀ ਹੈ। ਮੋਬਾਈਲ ਜਾਂ ਡੈਸਕਟਾਪ ਕਲਾਇੰਟ ਨੂੰ ਅਜੇ ਵੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਮਰਥਿਤ ਪ੍ਰੋਫਾਈਲ ਦੀ ਲੋੜ ਹੈ: ਭਰੋਸੇਯੋਗ ਸਰਟੀਫਿਕੇਟ ਚੇਨ, ਦੋਵੇਂ ਸਿਰਿਆਂ ਵੱਲੋਂ ਸਵੀਕਾਰਿਆ ਡੇਟਾ ਸਾਈਫਰ, ਦੋਵੇਂ ਸਿਰਿਆਂ ਵੱਲੋਂ ਲਾਗੂ ਕੀਤਾ ਕੰਟਰੋਲ-ਚੈਨਲ ਮੋਡ, ਅਤੇ ਕਲਾਇੰਟ ਦੇ ਬਿਲਡ ਵੱਲੋਂ ਨਾ-ਰੱਦਿਆ ਕੋਈ ਨਿਰਦੇਸ਼ ਨਾ ਹੋਣਾ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਪੁਰਾਣੀ key-method ਲਾਈਨ ਦੀ ਮੌਜੂਦਗੀ ਜਾਂ ਗੈਰ-ਮੌਜੂਦਗੀ ਨਾਲ ਤੈਅ ਨਹੀਂ ਹੁੰਦਾ।
ਕੰਪ੍ਰੈਸ਼ਨ ਇਸੇ ਸ਼ਕਲ ਦਾ ਵੱਖਰਾ ਨੀਤੀ ਸਵਾਲ ਹੈ। key-method ਲਾਈਨ ਹਟਾਉਣਾ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਤੁਹਾਡੀ ਤੈਨਾਤੀ ਵਿੱਚ ਕੰਪ੍ਰੈਸ਼ਨ ਨਿਰਦੇਸ਼ ਸਮਰਥਿਤ ਹੈ ਜਾਂ ਸਵੀਕਾਰਯੋਗ, ਅਤੇ ਦੋਵੇਂ ਫੈਸਲੇ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਲੈਣੇ ਚਾਹੀਦੇ ਹਨ। ਕੁਝ ਜੁੜਨ ਤੱਕ ਇਕੱਠੇ ਕਈ ਸੁਰੱਖਿਆ-ਸੰਬੰਧੀ ਸੈਟਿੰਗਾਂ ਮਿਟਾਉਣਾ ਹੀ ਉਹ ਢੰਗ ਹੈ ਜਿਸ ਨਾਲ ਚੱਲਦਾ ਪ੍ਰੋਫਾਈਲ ਅਸਪਸ਼ਟ ਪ੍ਰੋਫਾਈਲ ਬਣ ਜਾਂਦਾ ਹੈ।
ਤੁਸੀਂ ਕੀ ਹਟਾਇਆ ਅਤੇ ਕਿਉਂ, ਇਸ ਦਾ ਛੋਟਾ ਰਿਕਾਰਡ ਰੱਖੋ: ਵਿਕਲਪ, ਉਸ ਨੂੰ ਰੱਦ ਕਰਨ ਵਾਲਾ ਸੰਸਕਰਣ, ਅਤੇ ਤਰੁੱਟੀ ਦਿਖਾਉਣ ਵਾਲਾ ਕਮਾਂਡ। ਪ੍ਰੋਫਾਈਲ ਵਿਰਾਸਤ ਵਿੱਚ ਪਾਉਣ ਵਾਲੇ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਠੀਕ ਉਹੀ ਤਿੰਨ ਤੱਥ ਚਾਹੀਦੇ ਹੋਣਗੇ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਹੁਣ ਲਿਖਣਾ ਬਾਅਦ ਵਿੱਚ ਦੁਬਾਰਾ ਬਣਾਉਣ ਨਾਲੋਂ ਸਸਤਾ ਹੈ।