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

ਅਜਿਹਾ ਚੈਕਪੁਆਇੰਟ ਬਣਾਓ ਜੋ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਬਹਾਲ ਕਰ ਸਕੋ

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

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

ਰੱਦ ਕਰਨ ਨੂੰ ਸੰਰਚਨਾ ਤੋਂ ਵੱਖ ਰੱਖੋ

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

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

ਟਨਲ ਫੇਲ੍ਹ ਹੋਣ 'ਤੇ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚੋ

ਮਸ਼ੀਨ ਤੱਕ ਅਜਿਹਾ ਮਾਰਗ ਖੋਲ੍ਹੋ ਜੋ ਬਦਲੇ ਜਾ ਰਹੇ ਹਿੱਸੇ 'ਤੇ ਨਿਰਭਰ ਨਾ ਹੋਵੇ। ਹਾਈਪਰਵਾਈਜ਼ਰ ਕੰਸੋਲ, ਵੱਖਰੇ ਇੰਟਰਫੇਸ 'ਤੇ ਪ੍ਰਬੰਧਨ ਪਤਾ ਜਾਂ ਸੀਰੀਅਲ ਕੰਸੋਲ ਸਭ ਮਾਨਯੋਗ ਹਨ; ਟਨਲ ਰਾਹੀਂ ਲਿਜਾਇਆ SSH ਸੈਸ਼ਨ ਨਹੀਂ। ਜੇ ਦਾਖਲੇ ਦਾ ਇੱਕੋ ਰਾਹ ਉਹ VPN ਹੈ ਜੋ ਤੁਸੀਂ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਵਾਲੇ ਹੋ, ਤਾਂ ਗਲਤ ਮਾਰਗ ਜਾਂ ਫਾਇਰਵਾਲ ਨਿਯਮ ਉਸਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਖੋਹ ਲੈਂਦਾ ਹੈ। ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਵਿਕਲਪਿਕ ਮਾਰਗ ਪਰਖੋ, ਬਾਅਦ ਵਿੱਚ ਨਹੀਂ। ਇਸ ਰਾਹੀਂ ਇੱਕ ਵਾਰ ਲੌਗਇਨ ਕਰੋ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ sudo ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਵਰਤਿਆ ਸਹੀ ਪਤਾ ਲਿਖੋ।

ਪਰਖ ਸਰਲ ਹੈ: ਵਿਕਲਪਿਕ ਮਾਰਗ ਰਾਹੀਂ ਜੁੜੇ ਹੋਏ ਟਨਲ ਹੇਠਾਂ ਉਤਾਰੋ ਅਤੇ ਵੇਖੋ ਕਿ ਸੈਸ਼ਨ ਬਚਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਜੇ ਟੁੱਟ ਜਾਵੇ, ਤਾਂ ਤੁਸੀਂ ਨੁਕਸ ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਲੱਭ ਲਿਆ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਫਸਾ ਸਕੇ।

ਇੱਕ ਸੋਧ ਲਾਗੂ ਕਰੋ ਅਤੇ ਜਾਣੋ ਕਿ ਇਹ ਕਦੋਂ ਪ੍ਰਭਾਵੀ ਹੁੰਦੀ ਹੈ

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

ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਯੂਨਿਟ ਪਰਿਭਾਸ਼ਾ ਜਾਂਚੋ: systemctl show -p ExecReload openvpn@server ਦੱਸਦਾ ਹੈ ਕਿ reload ਹੁੱਕ ਬਿਲਕੁਲ ਹੈ ਜਾਂ ਨਹੀਂ। ਫਿਰ ਸੋਧ ਲਾਗੂ ਕਰੋ ਅਤੇ ਹੋਰ ਕੁਝ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਜਰਨਲ ਵਿੱਚ ਪਹਿਲੀਆਂ ਨਵੀਆਂ ਗਲਤੀਆਂ ਪੜ੍ਹੋ।

ਤਸਦੀਕ ਕਰੋ, ਦਰਜ ਕਰੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਜਾਂਚ ਕਰੋ

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

systemctl status openvpn@server --no-pager
journalctl -u openvpn@server -n 50 --no-pager

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

ਸੰਬੰਧਿਤ ਲੇਖ