Làm cách nào để thiết lập proxy thay đổi giới tính TCP liên tục?

Tôi có một nhà cung cấp (A) muốn gửi dữ liệu cho chúng tôi thông qua kết nối TCP đến. Thật không may, dịch vụ tiêu thụ (B) không thể nhận các kết nối TCP gửi đến. Ngoài ra, nó không có IP tĩnh, một yêu cầu khác.

Một cách để giải quyết vấn đề này là dịch vụ kết nối cổng TCP A đến với cổng TCP B khác, để người tiêu dùng có thể thực hiện kết nối ra bên ngoài đến B.

Đây không phải là một vấn đề duy nhất [1] [2] và với socat tôi có thể tạo ra thứ gì đó rất gần với những gì tôi muốn:

socat -d -d -d -u TCP4-LISTEN:PORT-A,reuseaddr TCP4-LISTEN:PORT-B,reuseaddr

Tuy nhiên, điều này có các vấn đề sau:

• Nếu B ngắt kết nối, nó không thể kết nối lại. Với TCP4-LISTEN:PORT-B,reuseaddr,fork, nó có thể kết nối nhưng không nhận được dữ liệu.
• B không thể kết nối trước khi A thiết lập kết nối (có thể vượt qua)
• Chỉ có một kết nối có thể được thiết lập để PORT-B(có thể vượt qua)

Có cách nào để điều chỉnh lệnh sao cho trở thành "vĩnh viễn" và chống lại sự thất bại?

Câu hỏi quan trọng là, A sẽ phản ứng thế nào khi mất kết nối hoặc kết nối bị từ chối? Bất cứ điều gì chỉ giả định rằng một kết nối TCP duy nhất sẽ tồn tại mãi mãi sẽ trở nên mong manh; đó chỉ là bản chất của internet.

Làm thế nào về việc thiết lập socatnhư một [x]inetddịch vụ?

Bạn sẽ thiết lập xinetdđể nghe trong PORT-B và bắt đầu socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIOngay khi phía B kết nối.

xinetdsẽ chuyển lưu lượng đến từ phía B sang đầu vào tiêu chuẩn socatvà bắt đầu ra tiêu chuẩn của socatvà chuyển nó sang phía B.

Nếu B ngắt kết nối, thì socatquá trình có thể được phép kết thúc; xinetdsẽ bắt đầu một cái mới ngay khi B kết nối lại. Trong khi B bị ngắt kết nối, A sẽ nhận được lỗi "từ chối kết nối".

Tôi đã từng phải làm một cái gì đó khá giống nhau trên một hệ thống HP-UX cũ.

Thế giới thực lộn xộn.

Trong thế giới thực, đôi khi các kết nối TCP bị chết, điều này có thể xảy ra, ví dụ nếu tường lửa trạng thái hoặc NAT được khởi động lại, nếu kết nối quá lâu mà không có lưu lượng truy cập, nếu kết nối cơ bản bị quá lâu.

Hơn nữa, đôi khi khi kết nối chết, chúng không chết đối xứng. Nếu một kết nối mang nhiều dữ liệu bị chết thì có khả năng người gửi sẽ nhận thấy rằng nó đã chết từ lâu trước khi người nhận làm như vậy. Điều này có một vài tác dụng phụ.

• Nếu kết nối được bắt đầu từ người gửi đến người nhận thì một kết nối mới có thể đến trong khi kết nối cũ rõ ràng vẫn còn tồn tại.
• Nếu kết nối được bắt đầu từ người nhận đến người gửi thì có thể có một độ trễ đáng kể giữa người gửi phát hiện kết nối bị ngắt và người nhận phát hiện thực tế đó và kích hoạt kết nối lại.

Hơn nữa, các kết nối TCP là một luồng byte, KHÔNG phải là luồng thông điệp, vì vậy khi kết nối của bạn chết, bạn có thể nhận được một phần tin nhắn.

Kết quả cuối cùng của việc này khiến tôi kết luận rằng một giải pháp mạnh mẽ đòi hỏi sự hiểu biết về giao thức ứng dụng để giải pháp của bạn có thể hiểu được.

1. Làm cách nào để ghép các luồng khi có kết nối mới.
2. Có nên lưu trữ tin nhắn hay không khi nguồn dữ liệu được kết nối bởi người nhận dữ liệu.
3. Liệu một cơ chế xác nhận kết thúc để kết thúc là thích hợp để ngăn chặn mất tin nhắn.
4. Liệu một số loại cơ chế "ping" cấp ứng dụng là cần thiết để tăng tốc độ phát hiện các kết nối chết.