Chuyển tiếp cục bộ SSH tới một proxy HTTP sẵn có: hai địa chỉ loopback

Proxy đã được phê duyệt của bạn chạy trên một máy nhảy nơi nó chỉ lắng nghe trên loopback, vì vậy không gì bên ngoài máy đó có thể chạm tới nó. Bạn không cần VPN hay một proxy mới; bạn cần một cổng của máy đó được mang sang một cổng của bạn. Chuyển tiếp cục bộ làm đúng điều đó, và nó cần một lệnh cùng một thiết lập của ứng dụng. Sự nhầm lẫn thường đến từ việc lẫn lộn địa chỉ loopback nào thuộc về máy nào.

Quyết định xem đã có proxy cố định chưa

Kỹ thuật này chuyển tiếp một dịch vụ đang chạy sẵn. Nếu máy từ xa chỉ có một daemon SSH và không có proxy, mọi mức chuyển tiếp đều không tạo ra được một cái, và kết nối sẽ bị từ chối từ phía xa. Hãy xác nhận proxy đã được gắn, cổng của nó là gì, và nó lắng nghe trên 127.0.0.1 hay trên một địa chỉ giao diện cụ thể, vì chính địa chỉ đó là mục tiêu mà chuyển tiếp phải nhắm tới.

Xác nhận điều này trước giúp bạn khỏi gỡ lỗi một đường hầm chưa bao giờ được nối với thứ gì.

Dựng chuyển tiếp và đọc lệnh

Dạng bạn muốn gắn một cổng loopback trên máy tính xách tay và nối nó, từ phía máy chủ, tới địa chỉ của proxy như máy chủ nhìn thấy.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N chặn một lệnh từ xa và -T chặn việc cấp phát termios, vì bạn muốn một đường hầm chứ không phải shell. Địa chỉ loopback đầu tiên là nơi máy tính xách tay lắng nghe; địa chỉ thứ hai được máy chủ SSH phân giải, nên 127.0.0.1 ở đó nghĩa là proxy trên máy ấy. ExitOnForwardFailure làm lệnh thất bại rõ ràng nếu cổng cục bộ đã bị chiếm, thay vì khởi động một phiên không chuyển tiếp gì. Hãy viết địa chỉ đích theo cách máy chủ phân giải, vì một cái tên chỉ máy tính xách tay của bạn phân giải được sẽ thất bại ở phía bên kia.

Chính sách của máy chủ được áp dụng trước khi bất kỳ điều gì ở đây hoạt động. AllowTcpForwarding phải cho phép điều đó, và PermitOpen có thể giới hạn những đích và cổng mà một phiên được tới, nên một chuyển tiếp mà máy khách chấp nhận vẫn có thể bị máy chủ từ chối. Sự từ chối hiện ra như một lỗi chuyển tiếp hoặc kênh ở máy khách, và đọc thông báo đó nhanh hơn sửa lệnh.

Hướng một ứng dụng tới chuyển tiếp

Cấu hình ứng dụng dùng proxy HTTP tại http://127.0.0.1:13128, kèm thông tin đăng nhập nếu proxy từ xa yêu cầu. Giữ việc kiểm tra chứng chỉ của chính ứng dụng cho các đích HTTPS, vì đường hầm proxy không thay thế nó. Đây là chuyển tiếp cố định của một dịch vụ, nên phải nói cho ứng dụng biết có một proxy thay vì để nó tự phát hiện.

Một kiểm tra nhanh trước khi cấu hình bất cứ thứ gì lâu dài: curl -x http://127.0.0.1:13128 -I https://example.com, lệnh này thử phương thức HTTP CONNECT mà proxy phải hỗ trợ.

Giữ quyền lực ở nơi nó vốn ở

Proxy từ xa vẫn quyết định những đích và phương thức nó cho phép, và một lần đăng nhập SSH không nên lặng lẽ cấp cho mọi tài khoản một relay web chung. Gắn vào 127.0.0.1 trên máy tính xách tay tránh việc công bố cổng ra mạng cục bộ của bạn, và nó không làm cổng trở nên riêng tư với các tiến trình khác trên cùng máy. Thay việc gắn đó bằng một địa chỉ wildcard để chia sẻ proxy chính là cách một relay mở không được quản lý hình thành.

Tầng vận chuyển SSH bảo vệ bước nhảy tới máy chủ. Qua điểm đó proxy mở kết nối của riêng nó, nên một yêu cầu HTTP thường tới một đích vẫn thường ở phía bên kia máy chủ, dù đoạn đầu đã được mã hóa.

Kiểm tra cả hai đầu rồi dọn dẹp

Việc dựng đường hầm cục bộ và thành công của dịch vụ từ xa là hai kết quả khác nhau, và trạng thái thoát của lệnh chỉ cho bạn biết về cái đầu. Kiểm tra xem bộ lắng nghe có tồn tại bằng ss -ltn, rồi thực hiện một yêu cầu được phép của ứng dụng và một yêu cầu mà proxy nên từ chối. Nếu cả hai hành xử như mong đợi, đường đi là thật; nếu đường hầm hoạt động mà mọi yêu cầu đều thất bại, proxy đang từ chối hoặc không tới được đích.

Khi xong, hãy dừng tiến trình SSH sở hữu nó, gỡ thiết lập proxy khỏi ứng dụng và xác nhận cổng cục bộ đã biến mất thay vì để lại một bộ lắng nghe sống lâu hơn nhiệm vụ.