SSH từ xa qua VPN: điều mà đường hầm không làm

VPN cho một máy chủ SSH một con đường riêng và loại bỏ nhu cầu về một trình lắng nghe công khai trên cổng 22. Nó không xác thực máy chủ, không cấp quyền cho người dùng và không quyết định tài khoản nào được đăng nhập. Đó vẫn là việc của SSH. VPN có phải là cách đúng để đến máy chủ hay không phụ thuộc vào ba điều kiện, và đường hầm chỉ là một trong những câu trả lời khả dĩ.

Đường hầm thay đổi điều gì và SSH vẫn quyết định điều gì

Đường hầm thay đổi khả năng tiếp cận: những địa chỉ nào có thể đến được và từ đâu. Nó không thay đổi điều xảy ra sau khi kết nối TCP được thiết lập, nơi máy chủ trình bày khóa máy chủ và hỏi danh tính người dùng.

Hãy giữ hai lớp tách biệt trong đầu và trong tài liệu của bạn. Đăng nhập VPN chứng minh ai được dùng mạng. Nó không nói gì về những tài khoản tồn tại trên mục tiêu, và nó không phải quyền đăng nhập vào mọi máy có thể đến được.

Các kiểu thất bại cũng tách biệt, và chính điều đó làm cho việc tách lớp trở nên hữu ích trong một sự cố.

Ba điều kiện quyết định mô hình truy cập

Thứ nhất, máy chủ có cần người ngoài mạng của bạn đến được không? Nếu không, một con đường riêng cộng với bastion hoặc mesh là thiết kế nhỏ hơn. Thứ hai, nhóm người dùng máy khách có thực sự chạy được ứng dụng VPN không, kể cả những người trên thiết bị được quản lý có hạn chế?

Thứ ba, bạn cần kiểm soát theo dịch vụ hay theo người dùng? VPN cấp phạm vi mạng; SSH cấp quyền truy cập tài khoản. Nếu yêu cầu là một nhà thầu đến được một máy chủ và không gì khác, đó là yêu cầu cấp quyền và chỉ đường hầm không thể diễn đạt điều đó.

Trả lời ba câu đó thì mô hình tự chọn. Bỏ qua chúng thì bạn kết thúc bằng việc phơi SSH ra công khai để tránh triển khai máy khách.

Xác nhận con đường riêng trước khi đổ lỗi cho SSH

Kết nối VPN đã được phê duyệt và dùng tên hoặc địa chỉ riêng đã ghi trong tài liệu của mục tiêu. Sau đó kiểm tra tuyến đã chọn, quyền của cổng và đường trở về máy khách. Một tên phân giải đúng không phải bằng chứng rằng địa chỉ đi qua đường hầm dự định, vì các tiền tố cục bộ và từ xa chồng lấn có thể gửi yêu cầu đến nơi hoàn toàn khác. Sự khác biệt đó đáng được ghi vào sổ tay vận hành.

Nếu kết nối không bao giờ được thiết lập, hãy xác nhận máy chủ đang lắng nghe trên giao diện bạn mong đợi và tường lửa của máy chủ cho phép nguồn mà nó thực sự thấy. NAT của cổng có thể viết lại nguồn đó, nên danh sách cho phép viết cho địa chỉ đường hầm của máy khách có thể không bao giờ khớp.

Sự không khớp đó là lỗi SSH tự gây ra phổ biến nhất qua VPN.

Đọc giai đoạn thất bại, không phải lỗi tổng hợp

Ba giai đoạn tạo ra ba thông báo khác nhau, và chỉ một trong số đó là về thông tin đăng nhập.

Dùng đúng lỗi và nhật ký của chính máy chủ thay vì đặt lại cả thông tin đăng nhập VPN và SSH cùng lúc. Đặt lại cả hai là cách một chẩn đoán năm phút trở thành một sự cố danh tính hai ngày.

Đầu ra chi tiết cho thấy bạn đã đến giai đoạn nào:

ssh -vv [email protected]

Giữ nguyên khóa máy chủ và quyền truy cập

Xác thực khóa máy chủ thông qua quy trình tin cậy dự kiến, đặc biệt sau khi thay máy chủ. Cảnh báo khóa thay đổi bất ngờ chính là thông báo bạn không được bỏ qua chỉ vì VPN đã kết nối, vì một đường hầm riêng không làm cho đích đến trở thành chiếc máy bạn nghĩ. Kiểm tra dấu vân tay với một nguồn bạn tin cậy độc lập với kết nối.

Về phía máy chủ, xác nhận rằng tài khoản được cấp quyền và phương thức xác thực bạn đã cấu hình chính là phương thức được đưa ra. Một khóa có mặt nhưng bị bỏ qua thường là vấn đề quyền hoặc cấu hình, không phải mạng.

Giới hạn quyền truy cập dịch vụ cho những danh tính cần thiết và duy trì một con đường khôi phục được cấp quyền cho các thay đổi mạng.