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

ਪੂਰੀ ਗੱਲ ਨੂੰ ਪੰਜ ਜਾਂਚ ਬਿੰਦੂਆਂ ਵਾਲਾ ਇੱਕ ਲੈਣ-ਦੇਣ ਮੰਨੋ, ਅਤੇ ਹਰ ਜਾਂਚ ਬਿੰਦੂ ਨੂੰ ਆਪਣੇ ਆਪ ਅੱਗੇ ਵਧਣ ਤੋਂ ਇਨਕਾਰ ਕਰਨ ਦਿਓ।

ਫਾਈਲ ਸਿਸਟਮ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਇਨਪੁਟ ਠੀਕ ਕਰੋ

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

ਖਾਲੀ ਵੇਰੀਏਬਲ ਜਲਦੀ ਰੱਦ ਕਰੋ। ਕਿਸੇ ਚੀਜ਼ ਵਿੱਚ ਨਾ ਫੈਲਣ ਵਾਲਾ ਅਣਸੈੱਟ $DEVICE install -m 400 $KEY /etc/openvpn/client/ ਹੁਕਮ ਨੂੰ ਡਾਇਰੈਕਟਰੀ ਵੱਲ ਨਿਸ਼ਾਨਾ ਬਣਾਈ ਨਕਲ ਬਣਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਅਸਫਲਤਾ ਬਾਅਦ ਵਿੱਚ ਆਪਣੀ ਕੁੰਜੀ ਪੜ੍ਹ ਨਾ ਸਕਣ ਵਾਲੀ ਸੇਵਾ ਵਜੋਂ ਆਉਂਦੀ ਹੈ।

ਸਟੇਜਿੰਗ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਪ੍ਰੋਫਾਈਲ ਸੈੱਟ ਇਕੱਠਾ ਕਰੋ

ਪਹਿਲਾਂ ਪੂਰਾ ਸੈੱਟ ਨਿੱਜੀ ਥਾਂ 'ਤੇ ਬਣਾਓ: ਪ੍ਰੋਫਾਈਲ, CA, ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ, ਕੁੰਜੀ ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਦੁਆਰਾ ਬੁਲਾਇਆ ਕੋਈ ਵੀ ਸਹਾਇਕ। install -m 400 -o root -g root ਨਾਲ ਨਕਲ ਕਰੋ ਤਾਂ ਜੋ ਇਜਾਜ਼ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਨਹੀਂ, ਬਣਾਉਣ ਵੇਲੇ ਹੀ ਸੈੱਟ ਹੋਣ। ਫਿਰ ਪ੍ਰੋਫਾਈਲ ਦੇ ਅੰਦਰਲੇ ਹਵਾਲੇ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਸਾਪੇਖ ca ਜਾਂ key ਲਾਈਨ ਸੇਵਾ ਸ਼ੁਰੂ ਹੋਣ ਸਾਰ ਯੂਨਿਟ ਦੀ ਕੰਮਕਾਜੀ ਡਾਇਰੈਕਟਰੀ ਦੇ ਹਵਾਲੇ ਨਾਲ ਹੱਲ ਹੁੰਦੀ ਹੈ। ਪੂਰਾ ਸੈੱਟ ਜਾਇਜ਼ ਨਾ ਹੋਣ ਤੱਕ ਸਰਗਰਮ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਲਿਖਣਾ ਚਾਹੀਦਾ।

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

ਪਰਮਾਣੂ ਰੂਪ ਵਿੱਚ ਬਦਲੋ ਅਤੇ ਪਿਛਲਾ ਸੈੱਟ ਰੱਖੋ

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

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

ਇੱਕ ਮਾਲਕ ਸਰਗਰਮ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਸਾਬਤ ਕਰੋ

ਇੱਕ ਸਰਗਰਮ ਕਰਨ ਦਾ ਰਾਹ ਚੁਣੋ, ਜਾਂ ਤਾਂ systemd ਇੰਸਟੈਂਸ ਜਾਂ NetworkManager, ਅਤੇ ਇਸਨੂੰ ਲਗਾਤਾਰ ਵਰਤੋ। ਸਰਗਰਮ ਯੂਨਿਟ ਦੇ ਕੋਲ ਅਣ-ਪ੍ਰਬੰਧਿਤ openvpn ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰਨ ਨਾਲ ਦੋ ਟਨਲ, ਮੁਕਾਬਲਾ ਕਰਦੇ DNS ਅੱਪਡੇਟ ਅਤੇ ਇਹ ਸਪਸ਼ਟ ਜਵਾਬ ਨਹੀਂ ਮਿਲਦਾ ਕਿ ਰੋਕਣ ਵਾਲਾ ਹੁਕਮ ਕਿਸਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦਾ ਹੈ। ਸਰਗਰਮ ਕਰਨ ਤੋਂ ਬਾਅਦ systemctl is-active openvpn-client@office ਜਾਂਚੋ, ਫਿਰ ਦੂਰਲੇ ਪ੍ਰੀਫਿਕਸ ਦਾ ਰੂਟ, ਫਿਰ ਟਨਲ ਵੱਲੋਂ ਸਥਾਪਿਤ ਰਿਜ਼ੌਲਵਰ ਲਈ resolvectl status ਜਾਂਚੋ। ਟਨਲ ਜਿਸ ਇੱਕ ਸਰੋਤ ਲਈ ਹੈ ਉਸ ਤੱਕ ਪਹੁੰਚ ਕੇ ਸਮਾਪਤ ਕਰੋ।

ਚੱਲ ਰਹੀ ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਹਰੀ ਟਰੇ ਆਈਕਨ ਪ੍ਰਕਿਰਿਆ ਦੇ ਤੱਥ ਹਨ, ਪਛਾਣ ਅਤੇ ਟ੍ਰੈਫਿਕ ਨੀਤੀ ਹੈਂਡਓਵਰ ਤੋਂ ਬਚੇ ਇਸਦਾ ਸਬੂਤ ਨਹੀਂ।

ਮੁੜ-ਦੌੜ ਅਤੇ ਸੇਵਾਮੁਕਤੀ ਵੱਖਰੇ ਵਰਕਫਲੋ ਹਨ

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

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

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

ਸੰਬੰਧਿਤ ਲੇਖ