Các máy khách Linux không thể kết nối, máy chủ và vấn đề TCP Kích thước / Dấu thời gian của Windows

Chúng tôi có một vấn đề là đôi khi một số máy khách (tất cả Ubuntu Ubuntu) không thể kết nối với máy chủ từ xa qua SSH. Nếu sự cố xảy ra, máy khách Windows không gặp sự cố đó và có thể kết nối tốt.

Tôi đã tìm thấy câu hỏi khác này với một vấn đề tương tự: Tại sao máy chủ sẽ không gửi gói SYN / ACK để đáp ứng với gói SYN

Vô hiệu hóa thời gian TCP trên máy chủ thực sự giải quyết được vấn đề, nhưng tôi muốn biết vấn đề thực sự là gì. Tôi thực sự không thấy lý do tại sao điều này sẽ gây ra bất kỳ vấn đề, chắc chắn không phải khi thiết lập kết nối.

Khi sử dụng Wireshark, tôi thấy rằng các máy khách Windows sử dụng kích thước Cửa sổ là 8192 trong khi các máy khách Linux sử dụng kích thước Cửa sổ là 29200. Các máy khách Windows nhận được SYN_ACK, các máy khách Linux thì không. Có thể là kích thước cửa sổ ban đầu cao hơn này chịu trách nhiệm cho việc không gửi SYN_ACK bởi máy chủ? Tôi không thể đưa ra một lời giải thích hợp lý về lý do tại sao nó có thể gây ra vấn đề nhất định, nhưng vì đó là sự khác biệt duy nhất (hiển thị với tôi), nên nó có vẻ như thế. Tui bỏ lỡ điều gì vậy?

*** CHỈNH SỬA Sau khi tìm kiếm nhiều hơn, suy nghĩ và một số phép thuật voodoo, tôi nghĩ rằng tôi có thể đã đưa ra một lời giải thích hợp lý. Phải có một số giả định và điều kiện cụ thể được đưa ra, nhưng tôi tin rằng những điều này có thể chỉ có thể xảy ra trong tình huống cụ thể này.

Cả hai người dùng đều đứng sau cùng một thiết bị NAT (trong trường hợp của chúng tôi là tường lửa Fortigate). Tường lửa này sẽ gán các cổng cục bộ trên giao diện / IP bên ngoài của nó cho mỗi kết nối NAT. Nếu cổng đã được sử dụng cho người dùng khác, nó sẽ bị bỏ qua. Nếu kết nối bị đóng, cổng sẽ được giải phóng và trở về nhóm NAT. Nếu cổng đó sau đó được gán cho người dùng khác, nhưng máy chủ vẫn có một số bản ghi kết nối (TIME_WAIT, FIN / ACK cuối cùng không nhận được) và dấu thời gian của gói thấp hơn kết nối trước đó, gói sẽ là âm thầm chán ghét.

Ok, có rất nhiều nếu ở đó, nhưng ... - hai người dùng đang phát triển trên cùng một trang web nên họ sẽ thực hiện nhiều kết nối đến cùng một máy chủ từ xa - tường lửa (Fortigate) luôn giữ một bộ đếm tuần tự của cổng NAT trên mỗi IP nguồn / đíchIP / DestinationPort. Nếu bộ đếm của cả hai người dùng gần nhau, khả năng xảy ra "va chạm" như vậy với hai kết nối đến máy chủ đó là không thể xảy ra, vì cả hai IP đích là cổng đều giống nhau. Điều đó sẽ giải thích tại sao vấn đề chỉ xảy ra lẻ tẻ.

Vấn đề duy nhất với lý thuyết này là tôi không thể tìm thấy bất kỳ bằng chứng nào về việc này xảy ra ở phía máy chủ. Không có kết nối nào bị kẹt trong TIME_WAIT hoặc một cái gì đó tương tự, và tôi cho rằng một khi chúng biến mất khỏi đầu ra netstat, máy chủ đã quên chúng.

Tôi tin rằng Kích thước cửa sổ ban đầu không có vai trò gì trong việc này, vì vậy tôi rất ấn tượng rằng một trong những danh sách nghi phạm.

Vì vậy, nếu các máy khách Windows không gặp sự cố, tôi đoán là chúng không yêu cầu dấu thời gian TCP trong khi các máy khách Linux thì có. Bạn có thể xác minh điều này bằng cách xem lại các ảnh chụp của Wireshark từ cả hai ví dụ.

Để bắt đầu khắc phục sự cố nguyên nhân cơ bản của sự cố dấu thời gian, thứ tự đầu tiên của doanh nghiệp là đảm bảo máy khách và máy chủ được đồng bộ hóa với máy chủ NTP. Nếu họ chỉ có một chiếc đồng hồ chạy miễn phí, nó rất có thể là nguyên nhân của vấn đề. Ví dụ:

 # ntpq -p
 remote           refid      st t when poll reach   delay   offset  jitter
========================================================================
*utcnist2.colora .ACTS.           1 u   92 1024  377   50.242    2.041   1.847
+time-c.timefreq .ACTS.           1 u  623 1024  377   55.413   -1.781   0.418

Hãy chắc chắn rằng ít nhất một cái có dấu hoa thị ở phía trước. Điều đó có nghĩa là nó đồng bộ. Dù sao cũng lạ khi thấy gian hàng phiên TCP ngay từ đầu. Người ta sẽ mong đợi nó bị đình trệ sau khi một vài gói có giá trị dấu thời gian đã được trao đổi. Chính xác hơn khi giá trị dấu thời gian từ một gói dường như bị ngược thời gian so với gói trước.