TCP RST ngẫu nhiên trên các trang web nhất định, chuyện gì đang xảy ra?

Phiên bản ngắn: Một máy Windows Server 2012 trên mạng của tôi đang nhận được các RST TCP liên tục nhưng không liên tục khi kết nối với một số trang web nhất định. Dunno họ đến từ đâu. Kiểm tra nhật ký wireshark cho phân tích và câu hỏi của tôi.

Phiên bản dài:

Chúng tôi chạy một proxy web cache trên một trong các máy chủ của chúng tôi để phục vụ văn phòng nhỏ của chúng tôi. Một đồng nghiệp đã báo cáo nhận được rất nhiều lỗi Reset Thiết lập lại kết nối 'hoặc' Trang không thể hiển thị 'khi kết nối với một số trang web, nhưng việc làm mới đó thường khắc phục nó.

Tôi đã xác minh hành vi của trình duyệt và sau đó trực tiếp hơn bằng cách thử một trình duyệt không được ủy quyền trên chính máy chủ. Nhưng ping & tracerout đến các trang web rắc rối không hiển thị bất kỳ vấn đề nào, các vấn đề dường như bị giới hạn trong các kết nối tcp.

Sau đó, tôi đã tạo một tập lệnh để kiểm tra các trang web bị ảnh hưởng bằng cách gửi cho chúng các yêu cầu HTTP CHÍNH trực tiếp qua cURL và kiểm tra tần suất chúng thành công. Một thử nghiệm điển hình trông như thế này: (điều này không được chứng minh, chạy trực tiếp trên máy chủ xấu)

C:\sdk\Apache24\htdocs>php rhTest.php
Sending HTTP HEAD requests to "http://www.washingtonpost.com/":
20:21:42: Length: 0     Response Code: NULL (0%)
20:22:02: Length: 0     Response Code: NULL (0%)
20:22:22: Length: 0     Response Code: NULL (0%)
20:22:42: Length: 0     Response Code: NULL (0%)
20:23:02: Length: 3173  Response Code: HTTP/1.1 302 Moved Temporarily (20%)
20:23:22: Length: 3174  Response Code: HTTP/1.1 302 Moved Temporarily (33.33%)
20:23:43: Length: 0     Response Code: NULL (28.57%)
20:24:03: Length: 3171  Response Code: HTTP/1.1 302 Moved Temporarily (37.5%)
20:24:23: Length: 3173  Response Code: HTTP/1.1 302 Moved Temporarily (44.44%)
20:24:43: Length: 3172  Response Code: HTTP/1.1 302 Moved Temporarily (50%)
20:25:03: Length: 0     Response Code: NULL (45.45%)

Về lâu dài, chỉ có khoảng 60% yêu cầu thành công, phần còn lại không trả về gì, với mã lỗi curl là: "lỗi cURL (56): Thất bại khi nhận dữ liệu từ máy ngang hàng" Hành vi xấu phù hợp với các trang web I kiểm tra (chưa có trang web nào trở nên 'tốt hơn') và nó khá dai dẳng, tôi đã xử lý sự cố trong một tuần nay và đồng nghiệp báo cáo sự cố đã xảy ra trong nhiều tháng.

Tôi đã kiểm tra tập lệnh yêu cầu CHÍNH trên các máy khác trong mạng của chúng tôi: không có vấn đề gì, tất cả các kết nối đều đi qua tất cả các trang web trong danh sách kiểm tra của tôi. Sau đó, tôi thiết lập proxy trên máy tính để bàn cá nhân của mình và khi tôi chạy các yêu cầu CHÍNH từ máy chủ có vấn đề mặc dù vậy, tất cả các kết nối đều đi qua. Vì vậy, bất kể vấn đề là gì, nó rất cụ thể cho máy chủ này.

Tiếp theo, tôi đã cố gắng cách ly trang web nào thể hiện hành vi thiết lập lại kết nối:

• Không có trang web mạng nội bộ nào của chúng tôi (192.168.xx) thả kết nối.
• Không có trang web ipv6 tôi đã thử nghiệm giảm kết nối. (Chúng tôi là ngăn xếp kép)
• Chỉ một số ít các trang web ipv4 bỏ kết nối.
• Mọi trang web sử dụng cloudflare dưới dạng CDN (mà tôi đã kiểm tra) đều bỏ kết nối. (nhưng vấn đề dường như không dành riêng cho các trang web trên nền tảng đám mây)

Góc này không phát triển thành bất cứ điều gì thực sự hữu ích, vì vậy tiếp theo tôi đã cài đặt dây dẫn để xem xét những gì đang diễn ra khi yêu cầu thất bại. Một yêu cầu CHÍNH thất bại trông như thế này: (ảnh chụp màn hình lớn hơn ở đây: http://imgur.com/TNfRUtX )

127 48.709776000    192.168.1.142   192.33.31.56    TCP 66  52667 > http [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=8960 WS=256 SACK_PERM=1
128 48.728207000    192.33.31.56    192.168.1.142   TCP 66  http > 52667 [SYN, ACK, ECN] Seq=0 Ack=1 Win=42340 Len=0 MSS=1460 SACK_PERM=1 WS=128
129 48.728255000    192.168.1.142   192.33.31.56    TCP 54  52667 > http [ACK] Seq=1 Ack=1 Win=65536 Len=0
130 48.739371000    192.168.1.142   192.33.31.56    HTTP    234 HEAD / HTTP/1.1 
131 48.740917000    192.33.31.56    192.168.1.142   TCP 60  http > 52667 [RST] Seq=1 Win=0 Len=0
132 48.757766000    192.33.31.56    192.168.1.142   TCP 60  http > 52667 [ACK] Seq=1 Ack=181 Win=42240 Len=0
133 48.770314000    192.33.31.56    192.168.1.142   TCP 951 [TCP segment of a reassembled PDU]
134 48.807831000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
135 48.859592000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
138 49.400675000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
139 50.121655000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
141 51.564009000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
143 54.452561000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897

Cách tôi đọc nó (sửa tôi nếu tôi sai, đây không thực sự là khu vực của tôi) là:

• Chúng tôi mở một kết nối tcp đến máy chủ web
• máy chủ web ACK
• Yêu cầu HTTP Head được gửi
• Có một gói RST, được đánh dấu là từ IP máy chủ web, giết chết kết nối.
• Máy chủ web gửi ACK
• Máy chủ web (cố gắng) đáp ứng yêu cầu CHÍNH với dữ liệu HTTP hợp lệ (Câu trả lời byte 951 chứa tiêu đề HTTP chính xác)
• Truyền lại máy chủ web (nhiều lần trong vài giây) phản hồi HTTP hợp lệ, nhưng nó không thể thành công vì kết nối đã được RST

Vì vậy, nếu máy chủ web đã gửi RST hợp lệ, tại sao nó cứ cố gắng điền yêu cầu? Và nếu máy chủ web không tạo RST, cái quái gì đã làm?

Những điều tôi đã thử mà không có hiệu quả:

• Vô hiệu hóa việc lập nhóm
• Thay đổi bộ điều hợp mạng (thay thế NIC được biết là đang hoạt động)
• Chỉ định một ip tĩnh.
• Vô hiệu hóa ipv6.
• Vô hiệu hóa khung jumbo.
• Cắm máy chủ trực tiếp vào modem của chúng tôi một đêm, bỏ qua các thiết bị chuyển mạch và bộ định tuyến của chúng tôi.
• Tắt tường lửa windows.
• Đặt lại cài đặt TCP qua Netsh
• Vô hiệu hóa thực tế mọi dịch vụ khác trên máy chủ. (Chúng tôi chủ yếu sử dụng nó như một máy chủ tệp, nhưng có apache & một vài DB)
• Gục đầu trên bàn (lặp đi lặp lại)

Tôi nghi ngờ một cái gì đó trên máy chủ đang tạo ra các gói RST, nhưng với cuộc sống của tôi, tôi không thể tìm thấy nó. Tôi cảm thấy như thể tôi biết: tại sao nó chỉ là máy chủ này? HOẶC tại sao chỉ một số trang web? nó sẽ giúp rất nhiều Trong khi tôi vẫn tò mò, tôi ngày càng có xu hướng nuke từ quỹ đạo và bắt đầu lại.

Ý tưởng / Gợi ý?

-Cảm ơn

Việc bắt gói của bạn có điều gì đó bất thường: Các bit ECN được đặt trong gói SYN đi.

Thông báo tắc nghẽn rõ ràng là một phần mở rộng cho giao thức IP cho phép các máy chủ phản ứng nhanh hơn với tắc nghẽn mạng. Nó lần đầu tiên được giới thiệu với Internet 15 năm trước, nhưng có những vấn đề nghiêm trọng được ghi nhận khi lần đầu tiên được triển khai. Điều nghiêm trọng nhất trong số đó là nhiều tường lửa sẽ làm rơi các gói hoặc trả về RST khi nhận được gói SYN với các bit ECN được đặt.

Do đó, hầu hết các hệ điều hành đều vô hiệu hóa ECN theo mặc định, ít nhất là đối với các kết nối đi. Kết quả là, tôi nghi ngờ rằng rất nhiều trang web (và nhà cung cấp tường lửa!) Đơn giản là không bao giờ sửa chữa tường lửa của họ .

Cho đến khi Windows Server 2012 được phát hành. Microsoft kích hoạt ECN theo mặc định bắt đầu với phiên bản hệ điều hành này.

Thật không may, bộ nhớ gần đây không có ai thực hiện bất kỳ thử nghiệm đáng kể nào về phản ứng của các trang Internet đối với ECN, vì vậy thật khó để đánh giá liệu các vấn đề được nhìn thấy vào đầu những năm 2000 có còn tồn tại hay không, nhưng tôi nghi ngờ rằng chúng và lưu lượng truy cập của bạn, ít nhất là một số thời gian, đi qua các thiết bị như vậy.

Sau khi bật ECN trên máy tính để bàn của tôi và sau đó kích hoạt Wireshark, chỉ vài giây trước khi tôi bắt được một ví dụ về máy chủ lưu trữ mà tôi đã nhận RST tới một gói với bộ SYN và ECN, mặc dù hầu hết các máy chủ đều hoạt động tốt. Có lẽ tôi sẽ tự mình quét Internet ...

Bạn có thể thử vô hiệu hóa ECN trên máy chủ của mình để xem sự cố có được giải quyết không. Điều này cũng sẽ khiến bạn không thể sử dụng DCTCP, nhưng trong một văn phòng nhỏ, rất khó có khả năng bạn đang làm như vậy hoặc có bất kỳ nhu cầu nào để làm như vậy.

netsh int tcp set global ecncapability=disabled