Netcat ngừng nghe lưu lượng UDP

Tôi đang sử dụng netcat trên một số máy Linux (xem câu hỏi khác này ), nhưng thấy một số hành vi không mong muốn.

Không giống như hướng dẫn trong câu trả lời được chấp nhận, tôi không sử dụng đường hầm UDP để thực hiện các truy vấn DNS. Tôi có một máy chủ từ xa mà tôi có thể đăng nhập, nhưng không cài đặt phần mềm và tôi đang cố gắng tạo đường hầm lưu lượng UDP từ máy tính của mình đến máy chủ, sau đó thiết lập một đường hầm riêng để gửi phản hồi UDP từ máy chủ về máy của tôi .

Đường hầm đi từ máy của tôi đến máy chủ đang hoạt động hoàn hảo, tuy nhiên về phía máy chủ, trường hợp netcat đang lắng nghe phản hồi từ máy chủ UDP sẽ đóng trình nghe sau khi nhận được phản hồi đầu tiên. Vì vậy, tôi có thể gửi yêu cầu và nhận lại 1 phản hồi, nhưng mọi yêu cầu tiếp theo sẽ làm cho máy chủ ổn nhưng phản hồi không được nhận. Sử dụng netstat tôi có thể thấy rằng trước khi nhận được phản hồi, netcat đang lắng nghe, nhưng cổng sẽ bị đóng sau khi nhận được phản hồi.

Ví dụ netcat trên máy của tôi dường như xử lý mọi thứ tốt. Cả hai máy đều đang chạy netcat v1.10-38. Bất cứ ý tưởng những gì đang xảy ra?

Vì vậy, có nhiều thứ gọi là netcat; Ubuntu thậm chí còn có / etc / giải pháp thay thế biểu tượng-liên kết-hackery cho nó.

Tôi nghĩ một phần của vấn đề của bạn là UDP không thực hiện các phiên; Tôi đã sao chép một phần của tệp /usr/share/doc/netcat-traditable/README.gz bên dưới, đây là một công việc khá tốt để giải thích.

Kết nối UDP được mở thay vì TCP khi -u được chỉ định. Chúng không thực sự là "kết nối" mỗi lần vì UDP là giao thức không kết nối, mặc dù netcat sử dụng bên trong cơ chế "ổ cắm UDP được kết nối" mà hầu hết các hạt nhân hỗ trợ. Mặc dù netcat tuyên bố rằng một kết nối UDP đi là "mở" ngay lập tức, không có dữ liệu nào được gửi cho đến khi một cái gì đó được đọc từ đầu vào tiêu chuẩn. Chỉ sau đó mới có thể xác định liệu có thực sự có máy chủ UDP ở đầu bên kia hay không và thường thì bạn không thể biết được. Hầu hết các giao thức UDP sử dụng thời gian chờ và thử lại để thực hiện công việc của họ và trong nhiều trường hợp sẽ không bận tâm trả lời, vì vậy bạn nên chỉ định thời gian chờ và hy vọng điều tốt nhất.

OK, có lẽ đó không phải là một lời giải thích tuyệt vời nhưng đó là những gì tôi có thể tìm thấy.

Nếu bạn chưa có, bạn có thể muốn thử nghiệm với bất kỳ tùy chọn netcat nào bạn có thể thấy có liên quan đến việc chờ đợi ... bạn đã thử nghiệm với:

• sử dụng -l cũng như -u để đảm bảo bạn đang ở chế độ "nghe"

• -vv để xem chính xác những gì đang xảy ra

• -q -1 ... sẽ "đợi mãi" ngay cả sau khi nhận EOF (hy vọng, nghe lại?)

Bạn có thể sử dụng socatcho điều đó. Nó có tùy chọn rất hay fork:

fork Sau khi thiết lập kết nối, xử lý kênh của nó trong một tiến trình con và giữ cho tiến trình cha mẹ cố gắng tạo ra nhiều kết nối hơn, bằng cách lắng nghe hoặc bằng cách kết nối trong một vòng lặp (ví dụ).

Máy khách (có cái này bạn chạy từ máy khách):

$ ssh -L 7753:localhost:7753 YourServer.com "/usr/bin/socat tcp4-listen:7753,reuseaddr,fork UDP:8.8.8.8:53"

Khách hàng:

$ sudo socat udp4-listen:53,reuseaddr,fork tcp:localhost:7753

$ dig @127.0.0.1 google.com