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 ಆಗಿ ನಿಲ್ಲಿಸುವುದು ಅತಿಥಿಯ ಮಾರ್ಗವನ್ನೂ ಅಲ್ಲ, ಕಾಣೆಯಾದ ರುಜುವಾತುಗಳನ್ನೂ ಅಲ್ಲ ಸರಿಪಡಿಸುವುದಿಲ್ಲ.