sshuttle so với VPN đầy đủ: phương pháp của nó thực sự bao phủ những gì
sshuttle chỉ mang những gì phương thức chuyển tiếp của nó hỗ trợ: trước tiên hãy kiểm tra phạm vi TCP, DNS và UDP, đặc quyền cục bộ cần thiết và trình trợ giúp từ xa.
sshuttle được chọn vì SSH đã hoạt động và mật mã học trông quen thuộc, và lý lẽ đó bỏ qua câu hỏi duy nhất quyết định xem nó có phù hợp không. Những gói nào rời khỏi máy, tài khoản nào mang chúng ở phía bên kia, và công cụ đòi hỏi bao nhiêu đặc quyền cục bộ. Ba câu trả lời đó thay đổi theo phương thức chuyển tiếp, nên một thiết lập hoạt động cho ứng dụng này có thể âm thầm thất bại với ứng dụng tiếp theo. Phần trình bày dưới đây bắt đầu từ giao thức mà ứng dụng thực sự cần.
Hãy bắt đầu từ giao thức mà ứng dụng cần
Hỗ trợ giao thức trong sshuttle 2.0 phụ thuộc vào phương thức bạn chọn. Các phương thức NAT và nft của Linux xử lý TCP và DNS, còn TPROXY thêm UDP chung. Mỗi nền tảng và phương thức có giới hạn riêng, và macOS chặn bắt bằng một cơ chế hoàn toàn khác. Ghi lại phiên bản đã cài, phương thức đã chọn và các giao thức mà ứng dụng cần trước khi chọn bất cứ điều gì.
Vì vậy một yêu cầu TCP hoạt động chứng minh rất ít về ứng dụng UDP hoặc về mọi truy vấn DNS. sshuttle cũng coi TCP là luồng thay vì đường hầm hóa toàn bộ gói IP, nên kết luận về thông lượng vay từ một VPN thông thường không chuyển sang được. Hãy so sánh cơ chế bạn thực sự chạy với khối lượng công việc bạn thực sự có.
| Approach | What it carries | What it needs locally |
|---|---|---|
| SSH local forward | One explicitly named TCP destination | Nothing beyond the SSH client |
| sshuttle, nft or nat method | TCP and DNS to the routed prefixes | Root or sudo for firewall rules |
| sshuttle, tproxy method | TCP, DNS and general UDP | Root or sudo, and kernel support |
| IP VPN | Routed IP traffic in a tunnel | A client with the required privileges |
Những gì máy khách cần ở cục bộ
Cách bố trí máy khách được ghi trong tài liệu yêu cầu root hoặc sudo, vì nó cài các quy tắc chặn bắt cục bộ thay vì tạo một giao diện đường hầm. Chính sự thật đó thay đổi câu chuyện bảo mật: một tiến trình có đặc quyền đó có thể chuyển hướng lưu lượng của toàn bộ máy, không chỉ của một ứng dụng. Hãy coi đặc quyền là một phần của thiết kế chứ không phải chi tiết cài đặt.
Xác nhận công cụ đã cài những quy tắc nào và chúng biến mất khi công cụ thoát. Một phiên bị sập và để lại quy tắc chặn bắt có thể đẩy lưu lượng vào hố đen rất lâu sau khi người vận hành tin rằng kết nối đã mất, và triệu chứng trông giống sự cố mạng chứ không phải một quy tắc còn sót lại.
sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip routeLệnh đầu tiên là dạng của một lời gọi điển hình, với tiền tố bạn thực sự cần. Lệnh thứ hai cho thấy công cụ đã cài gì, và lệnh thứ ba xác nhận không có giao diện đường hầm nào xuất hiện, đó là kết quả mong đợi cho thiết kế này.
Phía xa chạy những gì
Phía xa là một tài khoản SSH được cấp phép cùng một môi trường trợ giúp Python tương thích. Một lần đăng nhập thành công trong shell hạn chế không tự động cấp quyền chạy trình trợ giúp đó, và một tài khoản chạy được trình trợ giúp không tự động đến được mọi dịch vụ đích. Cả hai sự thật thuộc về yêu cầu truy cập chứ không phải ghi chú khắc phục sự cố.
Hãy bảo vệ việc xác minh danh tính máy chủ và xác thực tài khoản. Chấp nhận một khóa máy chủ không quen để kết nối đầu tiên hoạt động sẽ bỏ đi việc kiểm tra rằng phía xa là chiếc máy bạn định đến, và điều đó ở đây nặng hơn so với một lần chuyển tiếp cho một mục đích duy nhất.
Giới hạn tài khoản từ xa trong các dịch vụ mà quy trình làm việc cần, và thương lượng phạm vi đó với những người vận hành máy chủ. Họ là một phần của quan hệ tin cậy, và không thiết lập nào phía máy khách thay đổi điều đó.
Ranh giới tin cậy nằm ở đâu
Chuyển tiếp một kết nối API riêng qua SSH không cấp quyền cho mọi thao tác API. TLS của ứng dụng và việc đăng nhập vào ứng dụng vẫn áp dụng, và công cụ không thể làm cho một dịch vụ không có xác thực trở nên an toàn. Một bước nhảy tiếp theo từ máy chủ từ xa cũng không tự động là cùng một phân đoạn được bảo vệ như kênh SSH, vì kết nối thứ hai đó tuân theo chính sách mà máy chủ từ xa có.
Hãy viết ranh giới thành một câu: lưu lượng đến các tiền tố này đi ra qua tài khoản này trên máy chủ đó. Nếu câu đó cần một đoạn ngoại lệ, thiết kế đang làm nhiều hơn tài liệu của nó tuyên bố và đáng được xem lại trước khi đến môi trường sản xuất.
Hãy chứng minh theo từng giao thức, rồi chọn công cụ
Kiểm tra từng giao thức cần thiết bằng một yêu cầu vô hại, bao gồm đường đi của trình phân giải và các họ địa chỉ mà ứng dụng dùng. Đưa cả việc ngắt kết nối vào bài kiểm tra, để hành vi thất bại được phép của ứng dụng trở thành kết quả đã biết chứ không phải bất ngờ trong sự cố. Một phiên chuyển tiếp đúng khi đang chạy không nói gì về điều xảy ra khi nó sập.
Với một số ít dịch vụ được nêu tên rõ ràng, chuyển tiếp cục bộ thông thường dễ sở hữu và dễ kiểm toán hơn. Với lưu lượng ứng dụng phù hợp với phương thức của nó, sshuttle đưa ra một con đường trung gian chính đáng. Khi yêu cầu là kết nối IP rộng, thiết kế VPN là câu trả lời trung thực, và lựa chọn đi theo phạm vi cùng trách nhiệm vận hành chứ không phải bảng xếp hạng thuật toán mã hóa.