Nguyên nhân nào khiến cờ đặt lại TCP / IP (RST) được gửi?

123

Tôi đang cố gắng tìm hiểu lý do tại sao kết nối TCP / IP của ứng dụng của tôi liên tục trục trặc sau mỗi 10 phút (chính xác là trong vòng 1-2 giây). Tôi đã chạy Wireshark và phát hiện ra rằng sau 10 phút không hoạt động, đầu bên kia đang gửi một gói có cờ đặt lại (RST) được đặt. Một tìm kiếm trên google cho tôi biết "cờ ĐẶT LẠI biểu thị rằng người nhận đã bị nhầm lẫn và vì vậy muốn hủy kết nối" nhưng đó là một chút thiếu chi tiết tôi cần. Điều gì có thể gây ra điều này? Và có khả năng là một số bộ định tuyến trên đường đi chịu trách nhiệm cho nó hoặc điều này sẽ luôn đến từ điểm cuối khác?

Chỉnh sửa: Có một bộ định tuyến (cụ thể là Linksys WRT-54G) nằm giữa máy tính của tôi và điểm cuối khác - có điều gì tôi nên tìm trong cài đặt bộ định tuyến không?

networking tcp

— Luke
nguồn

12

Đây là một cái khác: Comcast

— Tom Ritter

1

Rất may mắn là tôi không phụ thuộc vào Comcast vì điều này đang xảy ra trong mạng LAN. Tôi ước gì tôi có thể thay đổi lời đổ lỗi dễ dàng;)

— Luke

Bạn đã bao giờ nhận ra điều này? Tôi không thể bình luận vì tôi không có đủ điểm, nhưng tôi có cùng một vấn đề chính xác mà bạn đang gặp phải và tôi đang tìm cách khắc phục.

Dịch vụ cụ thể này đề cập đến trường hợp nào? Có thể thiết lập keepalive trên socket (từ cấp ứng dụng) để thời gian chờ lâu không dẫn đến việc ai đó (ở giữa hoặc không) cố gắng buộc thiết lập lại kết nối vì thiếu tài nguyên.

— mình

"Comcast" bạn nói? : D Kiểm tra repo này có liên quan: github.com/tylertreat/comcast

— joonas.fi

89

Một 'bộ định tuyến' có thể làm bất cứ điều gì - đặc biệt là NAT, có thể liên quan đến bất kỳ lượng lỗi nào gây rối với lưu lượng truy cập ...

Một lý do khiến thiết bị gửi RST là để phản hồi việc nhận gói tin cho một ổ cắm đã đóng.

Thật khó để đưa ra một câu trả lời chắc chắn nhưng chung chung, bởi vì mọi hành vi xấu có thể xảy ra đều đã được truy cập trên TCP kể từ khi thành lập và tất cả mọi người có thể đang chèn RST để cố gắng chặn lưu lượng truy cập. (Ví dụ: một số 'tường lửa quốc gia' hoạt động như thế này.)

— Will Dean
nguồn

6

Bộ định tuyến có thời gian chờ 10 phút cho các kết nối TCP hoặc bộ định tuyến đã bật "phát hiện gói thông minh cổng".

— David Schwartz

2

Nó hơi phong phú khi gợi ý rằng một bộ định tuyến có thể bị lỗi.

— Marquis of Lorne,

23

Chạy một trình dò tìm gói tin (ví dụ: Wireshark) cũng trên máy ngang hàng để xem liệu máy ngang hàng đang gửi RST hay ai đó ở giữa.

— Alexander
nguồn

14

Tôi vừa dành khá nhiều thời gian để khắc phục sự cố này. Không có giải pháp nào được đề xuất hoạt động. Hóa ra là do nhầm lẫn sysadmin của chúng tôi đã gán cùng một IP tĩnh cho hai máy chủ không liên quan thuộc các nhóm khác nhau nhưng lại nằm trên cùng một mạng. Kết quả cuối cùng là kết nối vnc bị ngắt liên tục, trình duyệt phải được làm mới nhiều lần để tìm nạp trang web và những điều kỳ lạ khác.

— OutputLogic
nguồn

7

Một số tường lửa làm điều đó nếu kết nối không hoạt động trong x số phút. Một số ISP cũng đặt bộ định tuyến của họ để làm điều đó vì nhiều lý do khác nhau.

Trong thời đại ngày nay, bạn sẽ cần xử lý khéo léo (thiết lập lại nếu cần) tình trạng đó.

— Brian Knoblauch
nguồn

2

Kết nối được thiết lập lại tốt, vấn đề là khoảng thời gian ngắn ngắt kết nối gây ra cảnh báo không cần thiết.

— Luke

1

Tôi đã gặp sự cố cụ thể với thiết bị PIX / ASA của Cisco. Chúng có thời gian chờ đặc biệt ngắn như mặc định. Các thiết bị rẻ hơn thường là "tốt hơn" trong vấn đề này (như trong họ không timeout nhanh thật) ...

— Brian Knoblauch

1

Tôi thậm chí sẽ nói thêm rằng TCP không bao giờ thực sự hoàn toàn đáng tin cậy từ quan điểm kết nối liên tục. Nó chỉ trở nên đáng chú ý hơn theo thời gian. Một ví dụ thú vị khác: một số người có thể triển khai logic đánh dấu máy khách TCP là ngoại tuyến ngay khi phát hiện thấy việc đóng hoặc đặt lại kết nối. Và rồi đôi khi họ không thèm cho khách hàng cơ hội kết nối lại. Điều này rõ ràng là không hoàn toàn chính xác.

— Victor Yarema

7

RST được gửi bởi bên thực hiện đóng hoạt động vì nó là bên gửi ACK cuối cùng. Vì vậy, nếu nó nhận được FIN từ phía đóng thụ động ở trạng thái sai, nó sẽ gửi một gói RST chỉ ra phía bên kia rằng đã xảy ra lỗi.

— Vishal gupta
nguồn

6

Cả hai bên gửi và nhận FIN trong một quá trình đóng bình thường. Không có gì sai trong tình huống này và do đó không có lý do gì để một bên đưa ra yêu cầu đặt lại. Câu đầu tiên thậm chí không có ý nghĩa.

— Marquis of Lorne,

2

[RST, ACK] cũng có thể được gửi bởi bên nhận SYN trên một cổng không được lắng nghe. Trong một trường hợp tôi chạy ngang qua, RST / ACK xuất hiện khoảng 60 giây sau SYN đầu tiên. FWIW

— Les

@MarquisofLorne, bản thân câu đầu tiên có thể bị coi là không chính xác. Nhưng cụm từ "ở trạng thái sai" trong câu thứ hai làm cho nó có giá trị bằng cách nào đó.

— Victor Yarema

7

Nếu có một bộ định tuyến thực hiện NAT, đặc biệt là một bộ định tuyến cấp thấp với ít tài nguyên, thì trước tiên nó sẽ già đi các phiên TCP cũ nhất. Để thực hiện điều này, nó đặt RSTcờ trong gói để thông báo hiệu quả cho trạm nhận (rất vô duyên) đóng kết nối. điều này được thực hiện để tiết kiệm tài nguyên.

— MKII
nguồn

3

Một điều cần lưu ý là nhiều tường lửa netfilter Linux được định cấu hình sai.

Nếu bạn có một cái gì đó như:

-Một trạng thái FORWARD -m - trạng thái LIÊN QUAN, ĐƯỢC THÀNH LẬP -j CHẤP NHẬN

-A FORWARD -p tcp -j TỪ CHỐI - từ chối-với tcp-reset

thì việc sắp xếp lại gói có thể dẫn đến việc tường lửa coi các gói không hợp lệ và do đó tạo ra các thiết lập lại mà sau đó sẽ phá vỡ các kết nối lành mạnh.

Việc sắp xếp lại thứ tự đặc biệt có thể xảy ra với mạng không dây.

Thay vào đó, điều này phải là:

-Một trạng thái FORWARD -m - trạng thái LIÊN QUAN, ĐƯỢC THÀNH LẬP -j CHẤP NHẬN

- Trạng thái FORWARD -m - trạng thái INVALID -j DROP

-A FORWARD -p tcp -j TỪ CHỐI - từ chối-với tcp-reset

Về cơ bản bất cứ lúc nào bạn có:

... -m trạng thái - trạng thái LIÊN QUAN, ĐƯỢC THÀNH LẬP -j CHẤP NHẬN

ngay lập tức nó phải được theo sau bởi:

... -m state --state INVALID -j DROP

Tốt hơn là bạn nên thả một gói tin sau đó để tạo ra một giao thức có khả năng làm gián đoạn việc thiết lập lại tcp. Đặt lại sẽ tốt hơn khi chúng có thể là thứ chính xác để gửi ... vì điều này giúp loại bỏ thời gian chờ. Nhưng nếu có bất kỳ cơ hội nào chúng không hợp lệ thì chúng có thể gây ra loại đau đớn này.

— Mê cung
nguồn

0

Điều này là do có một quá trình khác trong mạng gửi RST đến kết nối TCP của bạn.

Thông thường RST sẽ được gửi trong trường hợp sau

Quá trình đóng ổ cắm khi ổ cắm sử dụng tùy chọn SO_LINGER được bật
Hệ điều hành đang thực hiện dọn dẹp tài nguyên khi quy trình của bạn thoát mà không đóng ổ cắm.

Trong trường hợp của bạn, có vẻ như một quá trình đang kết nối kết nối của bạn (IP + cổng) và tiếp tục gửi RST sau khi thiết lập kết nối.

— Ben
nguồn