Chuẩn bị đường khôi phục qua cổng nối tiếp trước khi đổi VPN trên GCE

Cửa sổ SSH thứ hai trên cùng giao diện không phải đường khôi phục. Nó dùng chung tuyến, quy tắc tường lửa và daemon mà bạn sắp thay đổi, nên nó hỏng đúng vào lúc bạn cần nhất. Trước khi sửa tuyến VPN trên VM Compute Engine, hãy chứng minh ba điều riêng biệt: bạn được dùng bảng điều khiển nối tiếp, bạn đọc được đầu ra của nó, và khách thực sự sẽ cho bạn đăng nhập. Các kiểm tra dưới đây chạy theo thứ tự đó, rẻ nhất trước, để quyền còn thiếu được phát hiện trước khi nó thành vấn đề.

Bước 1: xác nhận quyền phía đám mây

Nêu chính xác VM, dự án và vùng, sau đó kiểm tra chính sách truy cập nối tiếp đã được tổ chức phê duyệt. Quản trị viên cần quyền liên quan, và truy cập nối tiếp tương tác phải được bật cho phiên bản đó theo các kiểm soát dự án và tổ chức đang có hiệu lực.

Đừng làm suy yếu chính sách của tổ chức hay bật truy cập bảng điều khiển cho cả dự án chỉ để chuẩn bị một máy. Hãy đề nghị chủ sở hữu thu xếp cơ chế được phép trước thử nghiệm, không phải trong lúc sự cố.

Bước 2: chứng minh bạn đọc được đầu ra

Đọc đầu ra nối tiếp là kiểm tra rẻ nhất, và nó luyện đường truyền mà không chạm vào đăng nhập của khách:

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

Thay các định danh và dùng cổng được phép. Thông báo khởi động và tiếng ồn của bảng điều khiển cho bạn biết kênh hoạt động. Chúng không chứng minh bạn lấy được shell. Đó là lý do bước này tách khỏi bước sau.

Bước 3: chứng minh bạn lấy được đăng nhập tương tác

Lệnh kết nối mở một phiên thật, không phải bản xem trước:

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

Hãy coi nó như bảng điều khiển trực tiếp. Xác nhận điểm cuối trước khi gõ thông tin đăng nhập, vì mọi lần gõ phím đều rơi xuống phiên bản.

Đây là chỗ một kế hoạch trông hoàn chỉnh sụp đổ. Quyền trên đám mây là một ranh giới và lời nhắc đăng nhập của Linux là một ranh giới khác, và vượt qua cái đầu không nói gì về cái sau.

Bước 4: chuẩn bị thông tin đăng nhập mà khách sẽ chấp nhận

Các ảnh Linux do Google cung cấp không bật đăng nhập cục bộ bằng mật khẩu theo mặc định. Vì vậy một phiên nối tiếp có thể đến lời nhắc đăng nhập và dừng ở đó, chờ thông tin đăng nhập mà không ai đặt.

Một tài khoản khôi phục đã được phê duyệt, hoặc bất kỳ phương thức đăng nhập khách có tài liệu nào mà triển khai của bạn dùng, phải tồn tại và đã được kiểm thử. Khóa SSH hoạt động qua mạng không tự động đáp ứng lời nhắc mật khẩu của bảng điều khiển, nên hãy kiểm tra cách bố trí OS Login và khóa thực tế thay vì giả định nó bao phủ trường hợp này.

Giữ thông tin khôi phục ở chế độ riêng tư. Mật khẩu root dán vào một ví dụ startup-script công khai là sự cố thứ hai đang chờ xảy ra.

Bước 5: ghi lại chủ sở hữu và việc hoàn tác

Trước khi thay đổi bất cứ điều gì, hãy giữ lại cấu hình mạng đang hoạt động và ghi rõ ai quản lý nó, dịch vụ VPN nào liên quan và hoàn tác được thực hiện thế nào. Từ một phiên đang hoạt động, hãy ghi lại các tuyến, quy tắc và trạng thái dịch vụ hiện tại.

Chính bản ghi đó biến một kênh khôi phục thành sửa chữa, vì bảng điều khiển chỉ cho bạn một lời nhắc. Hãy viết nó trước khi thay đổi, không phải sau đó từ trí nhớ. Một bản hoàn tác sao chép từ wiki không phải là hoàn tác. Đó là phỏng đoán kèm số phiên bản.

Bước 6: xác minh sau khi thay đổi

Một phiên SSH sẵn có có thể sống sót qua chính sách chặn phiên mới, nên hãy kiểm tra bằng một phiên quản trị thông thường mới. Sau đó kiểm tra riêng hành vi VPN mà bạn đã thay đổi.

Giữ kênh khôi phục mở cho đến khi cả hai kiểm tra đều đạt, rồi đóng nó theo chính sách truy cập. Nếu SSH đã mất và chưa chuẩn bị đăng nhập qua bảng điều khiển, hãy ngừng coi truy cập nối tiếp là lưới an toàn và bắt đầu quy trình khôi phục tài khoản hoặc sửa chữa phiên bản đã được cấp phép. Dựng một VM khác làm jump host không sửa được cả đường của khách lẫn thông tin đăng nhập còn thiếu.