Giữ SSH cục bộ khi máy chủ dùng VPN hướng ra ngoài

Một máy chủ Linux nhỏ dùng VPN hướng ra ngoài cho ứng dụng mà nó lưu trữ, và quản trị viên vẫn muốn truy cập nó qua SSH từ bàn làm việc bên cạnh. Đó là yêu cầu hợp lý, và thường không cần chuyển tiếp cổng, địa chỉ nhà cung cấp hay một lỗ hổng trong đường hầm. Điều cần là một đường quản trị được thiết kế có chủ đích thay vì kế thừa từ những gì ứng dụng VPN đã làm với bảng định tuyến.

Các bước dưới đây giả định quản trị viên ở cùng một LAN.Quản trị từ xa là một vấn đề khác với một câu trả lời khác.

Gắn SSH vào địa chỉ mà quản trị viên sử dụng

Bắt đầu từ trình lắng nghe.ss -ltnp | grep :22 cho thấy sshd được gắn vào đâu, và trình lắng nghe trên 0.0.0.0 chấp nhận kết nối từ mọi giao diện, kể cả đường hầm. Gắn vào địa chỉ LAN thì hẹp hơn và làm cho ý định trở nên rõ ràng:ListenAddress 192.168.10.20 trong sshd_config, tiếp theo là kiểm tra cấu hình và nạp lại. Một lỗi đánh máy trong địa chỉ đó dễ thấy hơn ký tự đại diện, vì sshd từ chối khởi động khi địa chỉ không tồn tại.

Giữ nguyên việc kiểm tra khóa máy chủ và xác thực từng người dùng đúng như hiện có. „Chỉ là mạng cục bộ thôi“ không phải là phương thức xác thực, và một kênh quản trị bỏ qua kiểm tra khóa vì tuyến ngắn là kênh quản trị đang chờ bị lạm dụng. Việc đặt trước DHCP hoặc địa chỉ tĩnh làm cho mục tiêu có thể dự đoán được mà không biến nó thành danh tính công khai của máy chủ.

Giữ tuyến LAN ở ngoài đường hầm

Một máy chủ có địa chỉ trong 192.168.10.0/24 có tuyến kết nối cho tiền tố đó, và một tuyến cụ thể hơn thắng tuyến mặc định của VPN trong cùng bảng. Đó là lý do SSH cục bộ thường tiếp tục tự hoạt động khi đường hầm được dựng lên. Hãy xác minh thay vì giả định:ip route get 192.168.10.50 nêu tên giao diện và địa chỉ nguồn mà nhân sẽ dùng, và câu trả lời phải là thiết bị LAN, không phải đường hầm. Lặp lại việc kiểm tra từ máy của quản trị viên nữa, vì chính bảng của máy đó quyết định các gói có đến hay không. Hai máy chủ trên cùng một dây có thể không đồng ý về hướng nào là có thể tiếp cận.

Giả định vỡ ở hai chỗ. Một quy tắc định tuyến dựa trên chính sách có thể gửi lưu lượng vào một bảng mà tuyến mặc định trỏ vào đường hầm trước khi bảng chính được xem xét. Một ứng dụng VPN có tính năng khóa hoặc kill switch cũng có thể chặn lưu lượng không đi vào đường hầm, bất kể bảng định tuyến nói gì.

Các VLAN quản trị được định tuyến là trường hợp khác. Nếu quản trị viên ngồi trong 192.168.50.0/24 sau bộ định tuyến cục bộ, máy chủ cần một tuyến rõ ràng cho tiền tố đó qua 192.168.10.1, và tuyến đó phải chịu được việc kết nối lại. Giữ ngoại lệ chỉ dành riêng cho tiền tố quản trị; một ngoại lệ rộng cho dải riêng sẽ vô hiệu hóa mục đích của đường hầm.

Làm cho ngoại lệ tường lửa hẹp như quy tắc

Nếu máy chủ chạy tường lửa, chỉ cho phép SSH từ nguồn quản trị và chỉ trên giao diện LAN. Một quy tắc cho phép cổng 22 từ mọi nơi là rộng hơn yêu cầu và khó biện minh hơn khi xem xét. Trên máy chủ nftables quy tắc nằm trong chuỗi đầu vào với giao diện và nguồn được khớp; trên máy chủ iptables tương đương là một cặp khớp trên -i và -s. Hãy chú thích quy tắc bằng nhóm quản trị viên mà nó phục vụ, để lần đánh giá sau không phải đoán tại sao cổng 22 lại mở.

Cũng kiểm tra bộ lọc riêng của ứng dụng VPN. Một số ứng dụng cài đặt các quy tắc loại bỏ lưu lượng cục bộ theo thiết kế, và một quy tắc tường lửa đúng phía trên việc loại bỏ ở cấp ứng dụng không thay đổi gì. Đọc cấu hình của ứng dụng trước khi sửa tường lửa của máy chủ, vì hai bộ lọc nối tiếp tạo ra một lỗi không giống bộ lọc nào.

Thử cả hai trạng thái

Chạy thử hai lần: một lần khi đường hầm đã kết nối và một lần khi ngắt kết nối. Ở mỗi trạng thái, xác nhận trình lắng nghe, tuyến và một lần đăng nhập SSH thực sự từ máy của quản trị viên. Một đường chỉ hoạt động khi đường hầm được dựng lên không phải là đường quản trị cục bộ; đó là sự trùng hợp.

Sau đó khởi động lại đường hầm trong khi một phiên SSH đang mở. Một phiên sống sót chứng minh định tuyến ổn định; một phiên rớt cho bạn biết ứng dụng đang viết lại tuyến hoặc bộ lọc khi kết nối lại, điều đáng biết trước một sự cố hơn là trong lúc nó xảy ra.

Ghi lại địa chỉ nguồn mà bạn đã thử, vì một quy tắc viết cho 192.168.10.50 sẽ thất bại âm thầm khi máy tính xách tay của quản trị viên chuyển sang mạng con khác.

Viết đường khôi phục vào runbook

Hãy quyết định ngay bây giờ điều gì xảy ra nếu VPN hướng ra ngoài phá vỡ đường cục bộ. Truy cập bảng điều khiển, địa chỉ quản trị thứ hai hoặc một quy trình được ghi lại để dừng ứng dụng đều là những câu trả lời chính đáng, và bất kỳ câu nào trong số đó cũng tốt hơn việc phát hiện ra vấn đề đúng lúc bạn cần đăng nhập. Nếu máy chủ ở xa, đường cục bộ không tồn tại, và thiết kế đúng là một tuyến truy cập từ xa đã được phê duyệt riêng hoặc một bastion thay vì một cổng công khai bị lộ.

Giữ hai vai trò tách biệt trong tài liệu: SSH cục bộ cho quản trị viên ở gần, và đường hầm hướng ra ngoài cho lưu lượng của ứng dụng. Khi các vai trò đó được ghi lại, một thay đổi trong tương lai ở vai trò nào cũng có chỗ rõ ràng để kiểm tra, và người kế tiếp không phải khám phá lại tại sao một máy chủ có VPN vẫn trả lời trên địa chỉ LAN của nó.