Có những bất lợi trong đường hầm SSH?

Gần đây tôi đã "mua" một VPS mà tôi muốn sử dụng làm Proxy để có thể sử dụng một số trang web và nội dung mà tôi không thể truy cập từ Đức.

Vì tôi chưa quá lười để thiết lập Squid và OpenVPN (mà hiện tại tôi nghĩ là cần thiết) nên tôi sử dụng ssh-đường hầm.

Bây giờ sau một vài tuần, tôi đã tự hỏi mình rằng liệu ssh-đường hầm có ổn không, hay - và đó là câu hỏi của tôi - nếu có bất kỳ cảnh báo / nhược điểm / nhược điểm nào tôi cần phải có trong đầu?

ssh proxy ssh-tunneling

— Nils Riedemann
nguồn

Đối với những gì nó có giá trị, OpenVPN cực kỳ dễ thiết lập bằng cách sử dụng khóa tĩnh nếu bạn đang chuyển từ Linux sang Linux. Sẽ khó hơn một chút nếu một trong các máy của bạn là Windows, nhưng có thể thực hiện được. bit.ly/ujkD2

— bóng bán

Câu trả lời:

Vấn đề về hiệu năng phát sinh khi bạn tạo đường hầm TCP qua TCP vì bạn có hai lớp thực hiện chỉnh sửa thích ứng (khởi động chậm, tránh tắc nghẽn, truyền lại nhanh, xem RFC2001 ).

Không nhận thức được nhau, họ sẽ gặp khó khăn lớn nếu bạn bị mất kết nối bên ngoài.

Trang này mô tả hiện tượng một cách chi tiết.

biên tập:

Thay vì gắn bó với vấn đề TCP qua TCP, hãy xem sshript ngăn chặn nó.
Hãy xem phần " Lý thuyết vận hành " để biết thêm chi tiết về tình huống này.

— Shadok
nguồn

Không phải lớp bên trong biết rằng nó đang nói chuyện với giao diện loopback sao?

— Random832

Về câu hỏi của bạn, vấn đề là TCP không hỗ trợ vô hiệu hóa các "tối ưu hóa" đó, ngay cả khi bằng cách nào đó "nhận thức được vị trí của nó" như một luồng bên trong, nó không thể làm gì được. Vấn đề ở đây là hành vi thích ứng bên ngoài sẽ phá vỡ hành vi bên trong, điều này sẽ cố gắng thích ứng bằng cách làm chậm quá trình truyền lại, mặc dù luồng TCP bên ngoài đã thích ứng với điều đó.

— Shadok

Tôi đã suy nghĩ về trường hợp đó là kết nối TCP đường hầm thông thường, không phải là "TCP qua IP qua PPP qua TCP" - trong trường hợp đó thực sự không có ngăn xếp giao thức TCP thứ hai - ssh chỉ chuyển tiếp một luồng byte. Và tôi không có nghĩa là "nhận thức được vị trí của nó như một luồng bên trong", ý tôi là làm thế nào trong tình huống này nó sẽ có giao diện loopback (cổng ssh cục bộ đang lắng nghe) như là đích đến của nó.

— Random832

OP đã nói về "một số trang web", tôi cho rằng anh ta đang thực hiện HTTP qua VớV5 thông qua SSH, có nghĩa là anh ta đang thực hiện TCP qua TCP (bản thân SSH là TCP và HTTP bên trong đường hầm chảy qua các luồng TCP khác, được gói gọn trong SSH).

— Shadok

@Shadok Tôi khá chắc chắn rằng kết luận của bạn không đúng. apenwarr đã đề cập đến việc tun/tapđào hầm dẫn đến kết quả là tcp-over-tcp. SOCKSv5 không gặp phải vấn đề tương tự nhưng không hoạt động trong suốt với tất cả các ứng dụng (trong khi tun / tap chỉ là một giao diện mạng khác để có thể xử lý trong suốt).

— jpc

Một điều tôi có thể nghĩ ra khỏi tâm trí của tôi là hiệu suất. Nhưng điều đó thực sự phụ thuộc vào loại công cụ bạn đang đào hầm.

— Marcus
nguồn

Những loại hiệu suất? Băng thông? Tôi hiện đang sử dụng nó để truy cập hulu và một số video youtube bị chặn.

— Nils Riedemann

CPU trên cao (mã hóa) và có thể có độ trễ, rất có thể.

— Xt

Thông thường tôi đã thấy rằng độ trễ tăng nhưng thông lượng vẫn ổn (90%) so với đường hầm SSH. Hãy chắc chắn đặt ServerAliveIntervalđể ngăn chặn ngắt kết nối và gói nó trong một tập lệnh để tiếp tục khởi động lại đường hầm khi thất bại.

Hạn chế chính là đường hầm cổng trên mỗi TCP, trừ khi bạn sử dụng SOCKS. SOCKS vẫn ổn nhưng độ trễ dường như còn tăng hơn nữa với nó, và tất nhiên, không phải mọi khách hàng đều hỗ trợ SOCKS.

Bạn có thể cần chạy GatewayPortstrên máy khách hoặc máy chủ SSH để cho phép người khác kết nối qua đường hầm của bạn. Trên máy chủ, điều này yêu cầu quyền truy cập root vào sshd_config.

Thông báo chính về hiệu năng (như những người khác lưu ý) là các kết nối không đáng tin cậy có thể không phù hợp với phương pháp này, vì thuật toán của TCP không phản ứng tốt khi đóng gói.

Điều đó nói rằng, SSH dường như "làm điều đúng đắn" hầu hết thời gian.

— Stu Charlton
nguồn

Vấn đề với các kết nối không đáng tin cậy mà bạn quan sát có lẽ liên quan đến độ trễ và bắt tay tăng lên cần được lặp lại khi kết nối giảm. Chuyển tiếp cổng SSH không thực hiện đóng gói tcp-over-tcp.

— jpc