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

ਜੋ ਅਜੇ ਵੀ ਤੁਹਾਡੇ ਕੋਲ ਹੈ, ਉਸ ਦੀ ਸਮੀਖਿਆ ਕਰੋ

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

PathDepends onUsually fails when
Provider consoleAccount access and the provider's own APICredentials live in a wiki only reachable over the tunnel
Management subnetA second interface and its own routingThe bad change was a global route or firewall policy
Second tunnelA different listener, port and credentialsBoth listeners were changed in the same edit
Physical or local consoleBeing in the buildingNobody has been in the building for a year

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

ਸੁਤੰਤਰਤਾ ਨਿਰਭਰਤਾਵਾਂ ਦਾ ਸਵਾਲ ਹੈ

ਰਿਕਵਰੀ ਖਾਤਾ ਸੁਤੰਤਰ ਨਹੀਂ ਹੈ ਜੇ ਇਸਦਾ ਪਾਸਵਰਡ ਉਸ ਸੇਵਾ ਵਿੱਚ ਸੰਭਾਲਿਆ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚਦੇ ਹੋ। ਇੱਕੋ ਹੋਸਟ, ਇੱਕੋ ਪੋਰਟ ਅਤੇ ਇੱਕੋ ਫਾਇਰਵਾਲ ਨੀਤੀ ’ਤੇ ਦੂਜਾ VPN ਵੀ ਸੁਤੰਤਰ ਨਹੀਂ, ਕਿਉਂਕਿ ਜਿਸ ਤਬਦੀਲੀ ਨੇ ਪਹਿਲਾ ਤੋੜਿਆ, ਉਹ ਦੋਵੇਂ ਤੋੜਦੀ ਹੈ।

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

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

ਇੱਕ ਨਿਯੰਤਰਿਤ ਤਬਦੀਲੀ ਲਈ ਦੂਜਾ ਰਾਹ ਵਰਤੋ

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

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

ਯਾਦ ਤੋਂ ਨਹੀਂ, ਰਿਕਵਰੀ ਰਾਹ ਤੋਂ ਜਾਂਚੋ

ਅਹਿਮ ਜਾਂਚ ਇਹ ਹੈ ਕਿ ਆਮ ਰਾਹ ਵਾਪਸ ਆਉਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਰਿਕਵਰੀ ਸੈਸ਼ਨ ਹੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਇਸਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹੋ:

systemctl status openvpn-server@server --no-pager
ss -lntup | grep -E ':(1194|443)\b'
nft list ruleset | sed -n '1,40p'
journalctl -u openvpn-server@server --since '-10 min' --no-pager | tail -n 30

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

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

ਜਾਇਦਾਦ ਸੂਚੀ ਨੂੰ ਅਦਿਅਤਨ ਰੱਖੋ

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

ਦਰਜ ਕਰੋ ਕਿ ਕੌਣ ਹਰ ਰਾਹ ਵਰਤ ਸਕਦਾ ਹੈ, ਉਹ ਕੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਅਤੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਕਿਵੇਂ ਘੁਮਾਏ ਜਾਂਦੇ ਹਨ। ਮਾਲਕ ਤੋਂ ਬਿਨਾਂ ਰਿਕਵਰੀ ਰਾਹ ਭੁੱਲਿਆ ਹੋਇਆ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ ਬਣ ਜਾਂਦਾ ਹੈ, ਜੋ ਬਾਹਰ ਬੰਦ ਹੋਣ ਤੋਂ ਵੱਖਰੀ ਕਿਸਮ ਦੀ ਅਸਫਲਤਾ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ