Sự phân chia của cài đặt tcp_tw_recycle / tái sử dụng thành 1 là gì?

Tôi đặt cả tcp_tw_recycle / tái sử dụng thành 1 trong tệp cấu hình của mình.

Sự phân nhánh của việc này là gì?

Nếu một ổ cắm tcp được sử dụng lại, điều đó có gây rủi ro bảo mật không? tức là 2 kết nối khác nhau có khả năng gửi dữ liệu vào?

Có phù hợp với các kết nối ngắn hạn với cơ hội kết nối lại không?

Theo mặc định, khi cả hai tcp_tw_reusevà tcp_tw_recyclebị vô hiệu hóa, kernel sẽ đảm bảo rằng các socket ở TIME_WAITtrạng thái sẽ vẫn ở trạng thái đó đủ lâu - đủ lâu để chắc chắn rằng các gói thuộc các kết nối trong tương lai sẽ không bị nhầm với các gói trễ của kết nối cũ.

Khi bạn bật tcp_tw_reuse, các socket ở TIME_WAITtrạng thái có thể được sử dụng trước khi chúng hết hạn và kernel sẽ cố gắng đảm bảo rằng không có xung đột nào liên quan đến số thứ tự TCP. Nếu bạn bật tcp_timestamps(còn gọi là PAWS, để bảo vệ chống lại các số thứ tự được bọc), nó sẽ đảm bảo rằng những va chạm đó không thể xảy ra. Tuy nhiên, bạn cần kích hoạt dấu thời gian TCP ở cả hai đầu (ít nhất, đó là sự hiểu biết của tôi). Xem định nghĩa của tcp_twsk_unique để biết chi tiết về tin đồn .

Khi bạn kích hoạt tcp_tw_recycle, kernel trở nên hung hăng hơn nhiều và sẽ đưa ra các giả định về dấu thời gian được sử dụng bởi các máy chủ từ xa. Nó sẽ theo dõi dấu thời gian cuối cùng được sử dụng bởi mỗi máy chủ từ xa có kết nối ở TIME_WAITtrạng thái) và cho phép sử dụng lại ổ cắm nếu dấu thời gian đã tăng chính xác. Tuy nhiên, nếu dấu thời gian được sử dụng bởi máy chủ thay đổi (tức là cong ngược thời gian), SYNgói sẽ bị hủy âm thầm và kết nối sẽ không được thiết lập (bạn sẽ thấy lỗi tương tự như "hết thời gian kết nối"). Nếu bạn muốn đi sâu vào mã hạt nhân, định nghĩa của tcp_timewait_state_ process có thể là một điểm khởi đầu tốt.

Bây giờ, dấu thời gian không bao giờ nên quay ngược thời gian; trừ khi:

• máy chủ được khởi động lại (nhưng sau đó, khi nó hoạt động trở lại, TIME_WAITsocket có thể đã hết hạn, vì vậy nó sẽ không thành vấn đề);
• địa chỉ IP nhanh chóng được sử dụng lại bởi một thứ khác (các TIME_WAITkết nối sẽ ở lại một chút, nhưng các kết nối khác có thể sẽ bị tấn công TCP RSTvà điều đó sẽ giải phóng một số không gian);
• dịch địa chỉ mạng (hoặc tường lửa thông minh) có liên quan ở giữa kết nối.

Trong trường hợp sau, bạn có thể có nhiều máy chủ phía sau cùng một địa chỉ IP và do đó, các chuỗi dấu thời gian khác nhau (hoặc, các dấu thời gian đã nói được ngẫu nhiên hóa ở mỗi kết nối bởi tường lửa). Trong trường hợp đó, một số máy chủ sẽ ngẫu nhiên không thể kết nối, vì chúng được ánh xạ tới một cổng mà TIME_WAITnhóm của máy chủ có dấu thời gian mới hơn. Đó là lý do tại sao các tài liệu nói với bạn rằng "Thiết bị NAT hoặc bộ cân bằng tải có thể bắt đầu giảm khung hình do cài đặt".

Một số người khuyên bạn nên rời khỏi tcp_tw_recyclemình, nhưng cho phép tcp_tw_reusevà hạ thấptcp_timewait_len . Tôi đồng tình :-)

Tôi vừa mới cắn tôi, nên có lẽ ai đó có thể hưởng lợi từ nỗi đau và sự đau khổ của tôi. Đầu tiên, một liên kết có liên quan với nhiều thông tin: http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html

Đặc biệt:

Kết quả của việc thiếu tài liệu này là chúng tôi tìm thấy nhiều hướng dẫn điều chỉnh khuyên nên đặt cả hai cài đặt này thành 1 để giảm số lượng mục trong trạng thái TIME-WAIT. Tuy nhiên, như được nêu trong trang hướng dẫn tcp (7), tùy chọn net.ipv4.tcp_tw_recycle khá rắc rối đối với các máy chủ đối mặt công khai vì nó sẽ không xử lý các kết nối từ hai máy tính khác nhau sau cùng một thiết bị NAT, đây là một vấn đề khó giải quyết phát hiện và chờ đợi để cắn bạn:

Tôi đã sử dụng những cái được kích hoạt khá thành công để cung cấp độ trễ thấp nhất có thể, kết nối haproxy từ máy khách đến cụm MySql NDB. Đây là một đám mây riêng và không có kết nối nào từ bất kỳ đến bất kỳ loại NAT nào trong hỗn hợp. Trường hợp sử dụng có ý nghĩa, giảm độ trễ cho các máy khách bán kính đánh NDB thông qua haproxy càng nhiều càng tốt cho con người. Nó đã làm như vậy.

Tôi đã làm điều đó một lần nữa trên một hệ thống haproxy công khai, tải cân bằng lưu lượng truy cập web, mà không thực sự nghiên cứu tác động (câm, phải không?!) Và phát hiện ra sau nhiều sự cố và xua đuổi ma:

• Nó sẽ tạo ra tình trạng lộn xộn cho các khách hàng kết nối thông qua NAT.
• Gần như không thể xác định được vì nó hoàn toàn ngẫu nhiên, không liên tục và các triệu chứng sẽ tấn công khách hàng A, vào những thời điểm hoàn toàn khác nhau (hoặc không) so với khách hàng B, v.v.

Về phía khách hàng, họ sẽ thấy các khoảng thời gian mà họ không còn nhận được phản hồi cho các gói SYN, đôi khi ở đây và ở đó, và đôi khi trong thời gian dài. Một lần nữa, ngẫu nhiên.

Câu chuyện ngắn ở đây, theo kinh nghiệm gần đây, đau đớn của tôi, là để những thứ này một mình / bị vô hiệu hóa trên các máy chủ đối mặt công khai, bất kể vai trò là gì!

Từ 'man 7 tcp' Bạn sẽ thấy điều này:

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this option is not recommended since this causes problems when working with NAT
          (Network Address Translation).

   tcp_tw_reuse (Boolean; default: disabled; since Linux 2.4.19/2.6)
          Allow  to  reuse  TIME_WAIT  sockets  for  new connections when it is safe from protocol viewpoint.  It should not be changed without
          advice/request of technical experts.

Không có nhiều giúp đỡ ở đó. Uestion này cũng có một số hiểu biết tốt:

/programming/6426253/tcp-tw-reuse-vs-tcp-tw-recycle-which-to-use-or-both

Nhưng không có thông tin cụ thể về lý do tại sao tái sử dụng an toàn hơn tái chế. Câu trả lời cơ bản là tcp_tw numuse sẽ cho phép một người sử dụng cùng một ổ cắm nếu đã có một trong TIME_WAIT với cùng các tham số TCP và ở trạng thái không có lưu lượng truy cập nữa (tôi tin rằng đó là khi FIN được gửi ). mặt khác, tcp_tw_recycle sẽ chỉ sử dụng lại các ổ cắm trong TIME_WAIT với cùng các tham số bất kể trạng thái, có thể gây nhầm lẫn tường lửa trạng thái có thể mong đợi các gói khác nhau.

tcp_tw numuse có thể được thực hiện một cách chọn lọc trong mã bằng cách đặt tùy chọn ổ cắm SO_REUSEADDR, được ghi lại man 7 socketnhư sau:

   SO_REUSEADDR
          Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses.  For  AF_INET
          sockets  this means that a socket may bind, except when there is an active listening socket bound to the address.  When the listening
          socket is bound to INADDR_ANY with a specific port then it is not possible to bind to this port for any local address.   Argument  is
          an integer boolean flag.