GCE VPN ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸੀਰੀਅਲ ਰਿਕਵਰੀ ਮਾਰਗ ਤਿਆਰ ਕਰੋ

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

ਕਦਮ 1: ਕਲਾਊਡ-ਪਾਸੇ ਦੀ ਇਜਾਜ਼ਤ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

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

ਕਦਮ 2: ਤੁਸੀਂ ਆਉਟਪੁੱਟ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਇਹ ਸਾਬਤ ਕਰੋ

ਸੀਰੀਅਲ ਆਉਟਪੁੱਟ ਪੜ੍ਹਨਾ ਸਭ ਤੋਂ ਸਸਤੀ ਜਾਂਚ ਹੈ, ਅਤੇ ਇਹ ਮਹਿਮਾਨ ਦੇ ਲੌਗਇਨ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਟਰਾਂਸਪੋਰਟ ਦਾ ਅਭਿਆਸ ਕਰਦੀ ਹੈ:

gcloud compute instances get-serial-port-output VM_NAME \
    --project PROJECT_ID --zone ZONE --port 1

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

ਕਦਮ 3: ਤੁਸੀਂ ਇੰਟਰੈਕਟਿਵ ਲੌਗਇਨ ਲੈ ਸਕਦੇ ਹੋ ਇਹ ਸਾਬਤ ਕਰੋ

ਕਨੈਕਸ਼ਨ ਕਮਾਂਡ ਝਲਕ ਨਹੀਂ, ਅਸਲ ਸੈਸ਼ਨ ਖੋਲ੍ਹਦੀ ਹੈ:

gcloud compute connect-to-serial-port VM_NAME \
    --project PROJECT_ID --zone ZONE --port 1

ਇਸਨੂੰ ਜੀਵਤ ਕੰਸੋਲ ਸਮਝੋ। ਪ੍ਰਮਾਣ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਅੰਤ ਬਿੰਦੂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਕਿਉਂਕਿ ਹਰ ਕੀਸਟ੍ਰੋਕ ਇੰਸਟੈਂਸ ’ਤੇ ਪੈਂਦਾ ਹੈ।

ਇੱਥੇ ਹੀ ਪੂਰੀ ਦਿਸਦੀ ਯੋਜਨਾ ਢਹਿ ਜਾਂਦੀ ਹੈ। ਕਲਾਊਡ ਇਜਾਜ਼ਤ ਇੱਕ ਸੀਮਾ ਹੈ ਅਤੇ Linux ਲੌਗਇਨ ਪ੍ਰੋਂਪਟ ਦੂਜੀ, ਅਤੇ ਪਹਿਲੀ ਪਾਰ ਕਰਨਾ ਦੂਜੀ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ।

ਕਦਮ 4: ਮਹਿਮਾਨ ਜੋ ਪ੍ਰਮਾਣ ਸਵੀਕਾਰ ਕਰੇਗਾ ਉਹ ਤਿਆਰ ਕਰੋ

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

ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਰਿਕਵਰੀ ਖਾਤਾ, ਜਾਂ ਤੁਹਾਡੇ ਡਿਪਲੌਇਮੈਂਟ ਵੱਲੋਂ ਵਰਤੀ ਜਾਂਦੀ ਕੋਈ ਵੀ ਦਸਤਾਵੇਜ਼ੀ ਮਹਿਮਾਨ-ਲੌਗਇਨ ਵਿਧੀ, ਮੌਜੂਦ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਪਰਖੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਨੈੱਟਵਰਕ ਰਾਹੀਂ ਕੰਮ ਕਰਨ ਵਾਲੀ SSH ਕੁੰਜੀ ਆਪਣੇ ਆਪ ਕੰਸੋਲ ਪਾਸਵਰਡ ਪ੍ਰੋਂਪਟ ਪੂਰਾ ਨਹੀਂ ਕਰਦੀ, ਇਸ ਲਈ ਇਹ ਮੰਨਣ ਦੀ ਥਾਂ ਕਿ ਇਹ ਇਸ ਕੇਸ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ, ਅਸਲ OS Login ਅਤੇ ਕੁੰਜੀ ਪ੍ਰਬੰਧ ਜਾਂਚੋ।

ਰਿਕਵਰੀ ਪ੍ਰਮਾਣ ਨਿੱਜੀ ਰੱਖੋ। ਜਨਤਕ startup-script ਉਦਾਹਰਨ ਵਿੱਚ ਚਿਪਕਾਇਆ root ਪਾਸਵਰਡ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਦੀ ਦੂਜੀ ਘਟਨਾ ਹੈ।

ਕਦਮ 5: ਮਾਲਕ ਅਤੇ ਰੋਲਬੈਕ ਦਰਜ ਕਰੋ

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

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

ਕਦਮ 6: ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਪੁਸ਼ਟੀ ਕਰੋ

ਮੌਜੂਦਾ SSH ਸੈਸ਼ਨ ਨਵੇਂ ਨੂੰ ਰੋਕਣ ਵਾਲੀ ਨੀਤੀ ਤੋਂ ਵੀ ਬਚ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਨਵੇਂ ਆਮ ਪ੍ਰਸ਼ਾਸਨਿਕ ਸੈਸ਼ਨ ਨਾਲ ਜਾਂਚ ਕਰੋ। ਫਿਰ ਤੁਸੀਂ ਬਦਲੇ VPN ਵਿਵਹਾਰ ਦੀ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਜਾਂਚ ਕਰੋ।

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