Chi tiết mới được thêm vào cuối câu hỏi này; có thể là tôi không tham gia vào nguyên nhân.
Tôi có VPN dựa trên UDP OpenVPN được thiết lập ở tapchế độ (tôi cần tapvì tôi cần VPN để truyền các gói phát đa hướng, điều mà dường như không thể thực hiện được với tuncác mạng) với một số khách hàng trên Internet. Tôi đã gặp phải tình trạng đóng băng kết nối TCP thường xuyên qua VPN. Nghĩa là, tôi sẽ thiết lập kết nối TCP (ví dụ: kết nối SSH, nhưng các giao thức khác có vấn đề tương tự) và tại một số điểm trong phiên, có vẻ như lưu lượng sẽ ngừng được truyền qua phiên TCP đó.
Điều này dường như có liên quan đến các điểm xảy ra chuyển dữ liệu lớn, chẳng hạn như nếu tôi thực thi một lslệnh trong phiên SSH hoặc nếu tôi catlà tệp nhật ký dài. Một số tìm kiếm của Google đưa ra một số câu trả lời như câu trả lời trước đó trên Server Fault , chỉ ra rằng thủ phạm có khả năng là vấn đề MTU: trong thời gian lưu lượng truy cập cao, VPN đang cố gửi các gói bị rơi ở đâu đó trong các đường ống giữa Điểm cuối VPN. Câu trả lời được liên kết ở trên gợi ý sử dụng các cài đặt cấu hình OpenVPN sau để giảm thiểu sự cố:
fragment 1400
mssfix
Điều này sẽ giới hạn MTU được sử dụng trên VPN ở mức 1400 byte và sửa kích thước phân đoạn tối đa TCP để ngăn chặn việc tạo ra bất kỳ gói nào lớn hơn thế. Điều này có vẻ để giảm thiểu vấn đề một chút, nhưng tôi vẫn thường xuyên thấy sự đóng băng. Tôi đã thử một số kích thước làm đối số cho fragmentchỉ thị: 1200, 1000, 576, tất cả đều có kết quả tương tự. Tôi không thể nghĩ ra bất kỳ cấu trúc liên kết mạng lạ nào giữa hai đầu có thể gây ra vấn đề như vậy: máy chủ VPN đang chạy trên máy pfSense được kết nối trực tiếp với Internet và máy khách của tôi cũng được kết nối trực tiếp với Internet ở một vị trí khác.
Một mảnh ghép kỳ lạ khác: nếu tôi chạy tracepathtiện ích, thì điều đó dường như giúp giải quyết vấn đề. Một mẫu chạy giống như:
[~]$ tracepath -n 192.168.100.91
1: 192.168.100.90 0.039ms pmtu 1500
1: 192.168.100.91 40.823ms reached
1: 192.168.100.91 19.846ms reached
Resume: pmtu 1500 hops 1 back 64
Việc chạy ở trên là giữa hai máy khách trên VPN: Tôi đã bắt đầu theo dõi từ 192.168.100.90đích đến 192.168.100.91. Cả hai máy khách đều được cấu hình với fragment 1200; mssfix;nỗ lực giới hạn MTU được sử dụng trên liên kết. Các kết quả trên dường như cho thấy rằng tracepathcó thể phát hiện MTU đường dẫn 1500 byte giữa hai máy khách. Tôi cho rằng nó sẽ nhỏ hơn một chút do các cài đặt phân mảnh được chỉ định trong cấu hình OpenVPN. Tôi thấy kết quả đó hơi lạ.
Tuy nhiên, thậm chí còn lạ: nếu tôi có kết nối TCP ở trạng thái bị đình trệ (ví dụ: phiên SSH có danh sách thư mục bị đóng băng ở giữa), thì việc thực thi tracepathlệnh được hiển thị ở trên sẽ khiến kết nối khởi động lại ! Tôi không thể tìm ra bất kỳ lời giải thích hợp lý nào cho lý do tại sao điều này lại xảy ra, nhưng tôi cảm thấy như điều này có thể đang hướng đến một giải pháp để cuối cùng xóa bỏ vấn đề.
Có ai có bất kỳ khuyến nghị cho những thứ khác để thử?
Chỉnh sửa: Tôi đã quay lại và xem xét thêm một chút nữa và chỉ tìm thấy nhiều thông tin gây nhiễu hơn:
Tôi đặt kết nối OpenVPN thành đoạn ở mức 1400 byte, như được hiển thị ở trên. Sau đó, tôi kết nối với VPN từ khắp Internet và sử dụng Wireshark để xem xét các gói UDP được gửi đến máy chủ VPN trong khi gian hàng xảy ra. Không có gì lớn hơn số lượng 1400 byte được chỉ định, do đó sự phân mảnh dường như hoạt động đúng.
Để xác minh rằng ngay cả MTU 1400 byte cũng đủ, tôi đã ping máy chủ VPN bằng lệnh (Linux) sau:
ping <host> -s 1450 -M doĐiều này (tôi tin) sẽ gửi một gói 1450 byte bị vô hiệu hóa phân mảnh (ít nhất tôi đã xác minh rằng nó không hoạt động nếu tôi đặt nó thành một giá trị quá lớn như 1600 byte). Chúng dường như chỉ hoạt động tốt; Tôi nhận được trả lời từ chủ nhà mà không có vấn đề.
Vì vậy, có lẽ đây không phải là vấn đề MTU. Tôi chỉ bối rối không biết nó có thể là gì khác!
Chỉnh sửa 2: Lỗ thỏ cứ tiếp tục sâu hơn: Bây giờ tôi đã cô lập vấn đề thêm một chút. Nó dường như có liên quan đến hệ điều hành chính xác mà máy khách VPN sử dụng. Tôi đã sao chép thành công sự cố trên ít nhất ba máy Ubuntu (phiên bản 12.04 đến 13.04). Tôi có thể sao chép một cách đáng tin cậy một kết nối SSH đóng băng trong vòng một phút hoặc lâu hơn bằng cách chỉ cần catmột tệp nhật ký lớn.
Tuy nhiên , nếu tôi thực hiện thử nghiệm tương tự bằng máy CentOS 6 với tư cách là khách hàng, thì tôi không thấy vấn đề gì! Tôi đã thử nghiệm bằng phiên bản máy khách OpenVPN chính xác giống như tôi đang sử dụng trên các máy Ubuntu. Tôi có thể catđăng nhập tập tin trong nhiều giờ mà không thấy kết nối bị đóng băng. Điều này dường như cung cấp một số cái nhìn sâu sắc về nguyên nhân cuối cùng, nhưng tôi chỉ không chắc cái nhìn sâu sắc đó là gì.
Tôi đã kiểm tra lưu lượng qua VPN bằng Wireshark. Tôi không phải là chuyên gia về TCP, vì vậy tôi không biết phải làm gì với các chi tiết chính, nhưng ý chính là tại một thời điểm nào đó, gói UDP bị rớt do băng thông hạn chế của liên kết Internet, gây ra việc truyền lại TCP bên trong đường hầm VPN. Trên máy khách CentOS, các truyền lại này xảy ra đúng cách và mọi thứ tiếp tục vui vẻ. Tuy nhiên, tại một số điểm với các máy khách Ubuntu, đầu cuối từ xa bắt đầu truyền lại cùng một phân đoạn TCP (với độ trễ truyền tăng dần giữa mỗi lần truyền lại). Máy khách sẽ gửi giao diện TCP ACK hợp lệ cho mỗi lần truyền lại, nhưng đầu cuối từ xa vẫn tiếp tục truyền cùng một phân đoạn TCP theo định kỳ. Điều này mở rộng quảng cáo vô hạn và các quầy kết nối. Câu hỏi của tôi ở đây sẽ là:
- Có ai có bất kỳ khuyến nghị nào về cách khắc phục sự cố và / hoặc xác định nguyên nhân gốc của vấn đề TCP không? Như thể đầu cuối từ xa không chấp nhận các tin nhắn ACK được gửi bởi máy khách VPN.
Một điểm khác biệt chung giữa nút CentOS và các bản phát hành Ubuntu khác nhau là Ubuntu có phiên bản nhân Linux gần đây hơn nhiều (từ 3.2 trong Ubuntu 12.04 đến 3.8 trong 13.04). Một con trỏ đến một số lỗi kernel mới có thể? Tôi cho rằng nếu đó là như vậy, thì tôi sẽ không phải là người duy nhất gặp vấn đề; Tôi không nghĩ rằng đây có vẻ như là một thiết lập đặc biệt kỳ lạ.
tunmạng bằng cách chạy các trình định tuyến phát đa hướng (như pimd ) và có máy chủ OpenVPN sử dụng các--topologytùy chọn được đặt thành "mạng con" - xem hướng dẫn