Một thay đổi để bảo vệ VPS có thể khiến chính người quản trị không đăng nhập được. Tài liệu Ubuntu cảnh báo cấu hình OpenSSH sai có thể khóa đường truy cập; Docker cũng giải thích vì sao cổng container đã công bố có thể không chịu sự kiểm soát như người dùng UFW mong đợi. Đây là hai điểm khởi đầu cụ thể để bàn về những lỗi khó quên khi lần đầu quản trị VPS.
Bài viết dùng các tình huống giả định để mở thảo luận, không thuật lại sự cố hay lời kể của thành viên thật. Các ví dụ dành cho máy Ubuntu dùng OpenSSH, UFW và, ở phần tương ứng, Docker hoặc PostgreSQL. Hãy đối chiếu môi trường trước khi áp dụng; chuẩn bị quyền quản trị, bản cấu hình trước thay đổi và đường truy cập cứu hộ của nhà cung cấp. Những lệnh dưới đây là hướng dẫn tham khảo, chưa được thực thi trên VPS của bạn.
1. Kiểm tra cấu hình SSH trước khi áp dụng
Tình huống giả định: bạn sửa thiết lập đăng nhập, khởi động lại SSH rồi mới phát hiện không vào được. Theo Ubuntu, lỗi cấu hình có thể khiến dịch vụ từ chối khởi động. Trước khi sửa, hãy lưu riêng bản gốc và ghi rõ từng tệp sẽ thay đổi, kể cả cấu hình bổ sung. Chỉ thay một nhóm thiết lập mỗi lần để việc đối chiếu và khôi phục có phạm vi rõ ràng.
Lệnh kiểm tra trước khi áp dụng: sudo sshd -t
OpenSSH mô tả tùy chọn -t là kiểm tra tính hợp lệ của cấu hình và tính hợp lý của khóa. Nếu có báo lỗi, dừng lại và sửa đúng vị trí được chỉ ra. Kiểm tra này không thay thế thử đăng nhập: sau khi áp dụng, hãy mở một phiên mới bằng tài khoản dự định sử dụng trước khi đóng phiên quản trị hiện có.
Đừng coi việc phiên cũ vẫn hoạt động là bằng chứng cấu hình mới đã đúng. Mốc kiểm tra nên là một lần đăng nhập mới thành công. Nếu thất bại, dùng phiên còn giữ hoặc đường cứu hộ để trả lại đúng các tệp vừa sửa, kiểm tra lại rồi mới áp dụng. Khi chia sẻ sự cố, hãy phân biệt lỗi kiểm tra cấu hình với lỗi xác thực; hai dấu hiệu này dẫn tới những hướng tìm nguyên nhân khác nhau.
2. Cho phép đúng cổng SSH trước khi bật UFW
Tình huống giả định tiếp theo: cấu hình SSH không đổi nhưng kết nối mất ngay sau khi bật tường lửa. Trang hướng dẫn UFW cảnh báo thao tác bật có thể làm rơi kết nối đang tồn tại và cho phép thêm quy tắc trước khi kích hoạt. Vì vậy, trước bước này hãy xác nhận cổng SSH thực tế và quyền truy cập cứu hộ, thay vì mặc định mọi máy đều dùng cùng một cổng.
Ví dụ có điều kiện, chỉ khi SSH thực sự dùng TCP 22:
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status numbered
Ubuntu hướng dẫn dùng UFW để mở cổng và xem quy tắc đánh số. Sau đó, thử một kết nối SSH mới từ nơi bạn sẽ quản trị máy. Nếu dùng cổng khác, phải thay số tương ứng; không sao chép nguyên ví dụ rồi bỏ qua bước kiểm tra.
Nếu bị khóa truy cập, hãy dùng đường cứu hộ để sửa quy tắc theo cấu hình đã ghi. Ubuntu có hướng dẫn sudo ufw disable để vô hiệu hóa UFW, nhưng chỉ nên xem đây là biện pháp cứu hộ tạm thời trong tình huống phù hợp. Mục tiêu khôi phục là trở về bộ quy tắc có kiểm soát, sau đó thử lại kết nối mới trước khi kết thúc phiên xử lý.
3. Rà soát cổng Docker thay vì chỉ nhìn UFW
Tình huống giả định: bạn không cho phép một cổng trong UFW nhưng dịch vụ container vẫn truy cập được từ bên ngoài. Docker giải thích rằng lưu lượng cổng công bố được chuyển hướng trước các chuỗi INPUT và OUTPUT mà UFW sử dụng. Tài liệu công bố cổng cũng cảnh báo việc ánh xạ không chỉ định địa chỉ máy chủ mặc định có thể đưa dịch vụ ra các địa chỉ mạng của máy.
Trước khi triển khai container, hãy ghi rõ cổng nào cần công khai và cổng nào chỉ phục vụ nội bộ. Với dịch vụ không cần truy cập trực tiếp từ Internet, ưu tiên bỏ ánh xạ công khai; nếu cần truy cập từ chính máy chủ, đối chiếu phương án gắn địa chỉ loopback trong tài liệu Docker. Kiểm tra riêng từ máy chủ và từ một máy bên ngoài, đồng thời rà soát cả đường truy cập IPv4 lẫn IPv6 nếu có.
Nếu phát hiện cổng ngoài ý muốn, hãy sửa cấu hình công bố cổng và kiểm tra lại trước khi tiếp tục triển khai. Đừng vội tắt khả năng quản lý tường lửa của Docker để chữa triệu chứng: tài liệu chính thức cảnh báo cách này có thể làm hỏng mạng container. Khi cần quay lui, dùng cấu hình triển khai đã lưu, rồi xác nhận lại phạm vi truy cập mong muốn.
4. Thử phục hồi bản sao lưu trước khi cần cứu dữ liệu
Một tình huống giả định khác: bạn có tệp sao lưu PostgreSQL nhưng chưa biết cách phục hồi. PostgreSQL phân biệt sao lưu bằng SQL dump, sao lưu cấp hệ thống tệp và lưu trữ liên tục. Với SQL dump, định dạng xuất quyết định công cụ phục hồi: bản văn bản dùng psql, còn bản lưu dạng custom có thể dùng pg_restore. Vì vậy, hãy ghi cả cách tạo lẫn cách đọc bản sao lưu.
Ví dụ có điều kiện cho cơ sở dữ liệu PostgreSQL tên appdb, với tài khoản có quyền phù hợp và vị trí lưu được bảo vệ:
pg_dump -Fc -f appdb.dump appdb
Tài liệu pg_dump mô tả -Fc là định dạng custom dành cho pg_restore. Tên appdb chỉ là ví dụ. Trước khi dùng, xác nhận đúng cơ sở dữ liệu, thông tin kết nối và tệp đích; không coi việc tạo được tệp là kết thúc quy trình.
Hãy phục hồi vào môi trường thử tách biệt, đối chiếu dữ liệu và những thao tác ứng dụng quan trọng đã chọn trước. Không dùng cơ sở dữ liệu đang phục vụ người dùng làm nơi thử. PostgreSQL cảnh báo việc phục hồi có thể thực thi mã chứa trong bản sao lưu; chỉ sử dụng nguồn tin cậy. Ghi lại kết quả thực tế và giữ nguyên dữ liệu gốc nếu lần thử thất bại, thay vì tiếp tục ghi đè để tìm cách sửa.
5. Chia sẻ sự cố bằng một mẫu có thể đối chiếu
Để mở thảo luận, bạn có thể dùng mẫu: môi trường đang chạy; mục tiêu thay đổi; thao tác ngay trước sự cố; dấu hiệu quan sát được; cách lấy lại quyền truy cập; phép kiểm tra sau khôi phục; điều sẽ làm khác lần sau. Chỉ điền những gì bạn thực sự biết. Nếu nguyên nhân chưa rõ, hãy ghi là giả thuyết và nêu bằng chứng còn thiếu, thay vì biến suy đoán thành kết luận.
Chẳng hạn, một bài chia sẻ có thể bắt đầu bằng nhãn “tình huống giả định: mất SSH sau khi bật UFW”, rồi hỏi cần kiểm tra cổng thực tế và quy tắc nào. Khi đăng trường hợp thật, hãy bỏ mật khẩu, khóa riêng và dữ liệu người dùng khỏi nội dung. Câu hỏi hữu ích để cộng đồng cùng trả lời là: bước kiểm tra nào đã thiếu, và bằng chứng nào đủ để xác nhận máy đã trở lại trạng thái mong muốn?
