Chuyển tiếp SSH thực sự mang lưu lượng ứng dụng nào?

Terminal kết nối, dấu nhắc hiện ra và mọi người đều đồng ý rằng quyền truy cập SSH hoạt động. Sau đó một ứng dụng khách cơ sở dữ liệu trên máy tính xách tay vẫn không đến được máy chủ riêng, và phiên làm việc bị đổ lỗi. Thứ được xây dựng là một shell, và đó là một trong bốn giao diện khá khác nhau mà SSH có thể cung cấp. Hãy gọi tên giao diện trước, sau đó kiểm tra rằng ứng dụng thực sự dùng nó. Thứ tự quan trọng, vì mỗi giao diện thất bại theo cách riêng của nó.

Gọi tên giao diện trước khi so sánh bất cứ điều gì

hướng dẫn của ứng dụng khách OpenSSH phân biệt bốn cơ chế dễ bị nhầm lẫn. Một shell hoặc lệnh từ xa chạy trên máy chủ SSH. Chuyển tiếp cục bộ mở một socket lắng nghe trên máy khách và thực hiện kết nối tiếp theo từ phía xa. Chuyển tiếp từ xa làm ngược lại, lắng nghe ở phía máy chủ. Chuyển tiếp động đưa ra một điểm cuối SOCKS cho các chương trình biết cách dùng nó.

• Shell: chương trình chạy trên máy từ xa, không có gì lắng nghe cục bộ.
• Chuyển tiếp cục bộ: máy tính xách tay của bạn có một cổng, máy chủ từ xa thực hiện kết nối đi ra.
• Chuyển tiếp từ xa: phía xa có một cổng, lưu lượng quay trở lại phía bạn.
• Động: một proxy SOCKS trên máy khách, chỉ các ứng dụng hiểu proxy mới dùng.

Không cái nào trong số này cài đặt một tuyến đường. Một chương trình bỏ qua cài đặt proxy, hoặc nói UDP, hoặc tự phân giải tên, không bị ảnh hưởng bởi một phiên SSH đang hoạt động. Đó không phải là lỗi trong SSH; đó là phạm vi của giao diện bạn đã chọn.

Chuyển tiếp cục bộ, từ xa và động khác nhau ở ai lắng nghe

Sự khác biệt quyết định hầu hết các trường hợp là ai sở hữu socket lắng nghe. Với chuyển tiếp cục bộ, máy khách lắng nghe và đầu xa quay số đích, đó là lý do địa chỉ đích được phân giải theo quan điểm của máy chủ. Với chuyển tiếp từ xa, máy chủ lắng nghe và kết nối được mang về phía bạn, và đó là cách bạn đưa ra một dịch vụ cục bộ mà không công bố trực tiếp.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

Lệnh đầu tiên liên kết cổng 5432 trên máy tính xách tay và chuyển nó tới cơ sở dữ liệu như được nhìn thấy từ bastion. Lệnh thứ hai tạo một proxy SOCKS trên cổng 1080. Lệnh thứ ba xác nhận tiến trình nào thực sự đang lắng nghe, và đó là bằng chứng duy nhất cho thấy chuyển tiếp tồn tại thay vì đã thất bại âm thầm do xung đột cổng.

Chuyển tiếp động xứng đáng có cảnh báo riêng: nó chỉ bao gồm các ứng dụng tôn trọng SOCKS. Trình duyệt có thể được trỏ vào nó, một công cụ dòng lệnh có thể được bảo dùng nó, nhưng một trình điều khiển cơ sở dữ liệu có ngăn xếp kết nối riêng thường không thể. Giả định rằng mọi chương trình trên máy giờ đây dùng đường hầm là sai lầm phổ biến nhất trong toàn bộ lĩnh vực này.

Chế độ thiết bị đường hầm là ngoại lệ mạng thực sự duy nhất

OpenSSH cũng hỗ trợ chuyển tiếp thiết bị đường hầm -w, truyền một giao diện điểm-đến-điểm thay vì một bộ lắng nghe TCP. Đó là một đường hầm mạng thực sự, và nó được cấu hình có chủ đích, không phải tác dụng phụ của việc mở một shell.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Nó cần các số giao diện tương ứng có sẵn ở cả hai đầu, cấu hình đúng trên máy chủ và đủ đặc quyền trên máy khách để tạo thiết bị. Nó cũng cần một kế hoạch địa chỉ và định tuyến, vì một giao diện trần không mang bất kỳ chính sách nào về việc đích nào nên dùng nó.

Dù vậy, đường hầm kết thúc tại máy chủ từ xa. Bất kỳ sự bảo vệ nào mà vận chuyển SSH cung cấp đều kết thúc ở đó, và kết nối tiếp theo là một bước nhảy riêng. Một cổng VPN cũng có hình dạng ranh giới như vậy, đó là lý do việc so sánh nên về phạm vi và điểm kết thúc chứ không phải về công cụ nào mạnh hơn. Gọi tên ranh giới đó thành tiếng cũng giải quyết tranh luận về việc liệu một đường hầm có «mã hóa mọi thứ» hay không, vì rõ ràng là không.

Kiểm tra rằng ứng dụng của bạn dùng giao diện bạn đã xây

Việc xác minh là theo từng ứng dụng, không phải theo phiên. Một chuyển tiếp hoạt động chứng minh rằng cổng đã được liên kết và phía xa có thể quay số; nó không chứng minh rằng chương trình bạn quan tâm đã kết nối qua nó.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

Lệnh đầu tiên gửi một yêu cầu qua điểm cuối SOCKS với tên máy chủ được phân giải từ xa, và lệnh thứ hai thử cổng cơ sở dữ liệu đã chuyển tiếp trong khi TLS vẫn bắt buộc. Chạy lại các kiểm tra tương tự khi dừng chuyển tiếp để xác nhận chúng thất bại, vì một kiểm tra vượt qua cả hai cách chưa bao giờ dùng đường hầm.

Sau đó so sánh với một VPN có định tuyến chỉ trên các khía cạnh quan trọng: những đích nào được bao phủ, những giao thức nào hoạt động, sự bảo vệ kết thúc ở đâu và ai phải phê duyệt quyền truy cập. Chuyển tiếp cho một dịch vụ có thể là câu trả lời hẹp hơn và tốt hơn, trong khi VPN là hình thức đúng khi nhiều ứng dụng cần cùng một đường mạng. Không cái nào cấp mọi thứ có thể tiếp cận từ đầu xa của nó.