Tự động kết nối lại đường hầm TCP

9

Tôi có một kết nối mạng không đáng tin cậy giữa hai máy: đôi khi các kết nối TCP hoạt động bị hủy vì những lý do ngoài tầm kiểm soát của tôi. Tôi muốn thiết lập kết nối TCP đáng tin cậy giữa hai máy.

Nếu mạng đáng tin cậy, tôi chỉ cần chạy ssh -L 1234:localhost:1234 remotehost, với máy chủ lắng nghe trên cổng 1234 remotehostvà hướng máy khách vào localhost:1234. Nhưng nếu kết nối ssh chết, kết nối chuyển tiếp cũng vậy. Làm cách nào tôi có thể sắp xếp để tự động khôi phục kết nối giữa máy khách và máy chủ?

Phi giải pháp:

  • Điều này không dành cho các ứng dụng tương tác, vì vậy màn hình không được áp dụng.
  • Đây không chỉ là về việc kết nối lại một đường hầm SSH tự động, la la autossh . Tôi muốn tiếp tục sử dụng cùng một kết nối TCP được tạo đường hầm, không bắt đầu một kết nối mới.
  • Về nguyên tắc, một VPN sẽ thực hiện các mẹo. Nhưng có vẻ như quá mức khi tôi chỉ muốn một kết nối TCP và tôi muốn một giải pháp hoạt động ngay cả khi tôi không có quyền root ở hai bên.

Tôi có một ký ức mờ nhạt về một chương trình được gọi là rocksđã làm điều đó, nhưng dường như nó đã rơi ra khỏi khuôn mặt của web. Tôi hầu như quan tâm đến Linux ở cả hai phía (mặc dù tôi mong muốn một chương trình ở cấp độ này có thể được chuyển sang các đơn vị khác), nhưng nếu bạn biết về một chương trình hoạt động giữa QNX và VMS, thì tốt hơn hết.

ssh  unix  tcp  tunneling 
— Gilles 'SO- ngừng là ác'
nguồn
Gilles, bạn đang sử dụng thủ tục tcp với các kết nối ssh của bạn? Nếu không, hãy thử điều này trước ... một số kết nối thời gian thực hiện NAT nhanh chóng
— Mike Pennington
@Mike: Cảm ơn vì tiền boa. Tôi không có nhu cầu ngay lập tức, nhưng tôi đã phải đối mặt với cả hai tình huống khi một số tuyến trung gian đến và đi (vì vậy các thủ tục TCP gây hại nhiều hơn là tốt) và các tình huống khiến NAT quá tải và bỏ rơi tôi (vì vậy các thủ tục TCP có thể giúp đỡ). Các thủ tục TCP sẽ không quan trọng đối với một luồng liên tục (ví dụ: scp), phải không? Trong mọi trường hợp tôi muốn giữ vị tướng này: lần tới khi tôi phải đối mặt với một mạng lưới không có hương vị gì, tôi có thể làm gì?
— Gilles 'SO- ngừng trở nên xấu xa'
Gilles, các giải pháp là khác nhau cho dòng liên tục như scp. Tôi đã trả lời các thủ tục w / ssh dựa trên ví dụ chuyển tiếp cổng của bạn. Re: flakes hạ lưu hop, không có nhiều thứ bạn có thể làm, ngoài việc tạo một phiên ssh với các thủ tục có khả năng chịu đựng tốt hơn (nghĩa là cho phép nhiều người bỏ rơi hơn ServerAliveInterval > 0và ServerAliveCountMax > 3). NAT yêu cầu khoảng thời gian bảo trì thấp hơn. Vấn đề chính là xác định vấn đề là gì và điều chỉnh cho phù hợp. Đặt các tùy chọn .ssh/configđể chúng luôn ở đó cho bạn
— Mike Pennington
@Mike: Một trong những trường hợp sử dụng của tôi bao gồm máy khách nhận IP của nó từ một NAT bị quá tải thay vì giảm ngẫu nhiên ngay cả các kết nối hoạt động (nghĩ rằng P2P nhiều hơn mức cần thiết). Sau vài giây, khách hàng quản lý để kết nối lại nhưng có thể nhận được một địa chỉ IP khác. Không có cách nào kết nối TCP sẽ tồn tại trong trường hợp đó. Đá đối phó, nhưng tôi thích thứ gì đó được tổng hợp từ các hệ thống ngày nay.
— Gilles 'SO- ngừng trở nên xấu xa'
trong trường hợp NAT cung cấp cho bạn IP mới, bạn sẽ không thể làm gì hơn là sửa NAT hoặc hy vọng cho rocksviệc thực hiện khác ... mặc dù đây rõ ràng là một loại bùn thực sự
— Mike Pennington

Câu trả lời:

1

Giao thức tiêu chuẩn duy nhất tôi biết với khả năng này là MPTCP . Nó trong suốt đối với lớp ứng dụng, vì vậy SSH trên MPTCP chỉ nên hoạt động. Nó có thể chạy các kết nối TCP cơ bản trên các đường dẫn khác nhau với các IP khác nhau, vì vậy về nguyên tắc, nó có thể được sử dụng để di chuyển kết nối SSH của bạn vào và ra khỏi kết nối VPN tùy thuộc vào việc kết nối VPN có hoạt động hay không.

Tôi không biết nhiều về sự trưởng thành của việc triển khai MPTCP, nhưng thiết kế của giao thức có vẻ khá mạnh mẽ.

Nó sẽ bảo vệ các kết nối SSH của bạn khỏi bị mất do kết nối mạng không ổn định. Nó sẽ không bảo vệ bạn trước một người muốn phá vỡ kết nối SSH của bạn. Một mitm vẫn có thể tiêm dữ liệu bị hỏng, mà SSH sẽ phát hiện và phá vỡ kết nối.

Một MPTCP như phương thức kết nối lại được xây dựng trong giao thức SSH sẽ là phương pháp tôi có thể tưởng tượng để giữ kết nối tồn tại trong thời gian dài nhất có thể. Nhưng tôi không nghĩ rằng một tính năng như vậy đã được thiết kế cho giao thức SSH.

— kasperd
nguồn
0

Bạn có thể sử dụng daemontoolsđể giữ cổng ssh tiến lên; nó sẽ không nhất thiết giữ các chương trình tùy thuộc vào kết nối còn tồn tại trong khi nó ngừng hoạt động (có lẽ khi ssh ngắt kết nối, cổng cục bộ sẽ bắt đầu từ chối kết nối của chúng), nhưng đó là một sự khởi đầu.

Tôi nghi ngờ có một số iptablesthủ thuật, như khiến cổng đó chuyển sang các gói DROP ngay khi ssh chuyển tiếp biến mất, vì vậy các chương trình kết nối chỉ biết rằng các gói đang biến mất, không bị từ chối. Tôi chỉ đang daemontoolstự học (một lần nữa) vì vậy tôi không chắc liệu bạn có thể chạy tập lệnh tùy chỉnh khi dịch vụ bị chết hay không, nhưng tôi nghi ngờ bạn có thể.

— Gordon Morehouse
nguồn
-2

TCP thực hiện điều này tự động. Bạn chỉ cần vô hiệu hóa hoặc làm suy yếu các hack dọn dẹp thực tế điển hình được sử dụng để tiêu diệt các kết nối TCP moribund. Vô hiệu hóa TCP keepalive cho kết nối của bạn và tăng đáng kể giới hạn cho truyền lại quá mức. Trên Linux, ví dụ, viết một số lượng lớn vào /proc/sys/net/ipv4/tcp_retries2.

Tuy nhiên, trong một mạng hiện đại, tường lửa kiểm tra gói trạng thái có khả năng quên kết nối TCP không trao đổi gói thường xuyên, do đó, nó có thể làm mưa trên cuộc diễu hành của bạn.

— xe đẩy
nguồn
1
Đúng là TCP có thể xử lý tình huống, miễn là mỗi điểm cuối có một địa chỉ IP tĩnh và không có hộp trung gian trạng thái. Câu hỏi đề cập reasons beyond my control, mà tôi đọc là IP động hoặc hộp trung gian trạng thái. Trong các trường hợp như vậy, TCP keepalive có thể giúp một chút. Nhưng cho dù bạn định cấu hình TCP keepalive như thế nào, nó sẽ không đủ để duy trì kết nối khi hộp giữa bị mất trạng thái do bị khởi động lại.
— kasperd
@kasperd Tôi đồng ý. Tuy nhiên, thật vô ích khi cố gắng duy trì kết nối TCP mở trong những trường hợp đó. Do đó, tôi cho rằng người hỏi không phải đối mặt với những thách thức cụ thể đó.
— xe đẩy
Sẽ không vô ích nếu bạn kiểm soát cả hai điểm cuối và có thể nâng cấp chúng thành một ngăn xếp với sự hỗ trợ MPTCP. Ngoài ra, một giải pháp lớp ứng dụng có thể được triển khai trên TCP mà không cần MPTCP.
— kasperd
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.