SSH bị treo qua OpenVPN? Hãy đo MTU của đường đi trước

SSH kết nối, dấu nhắc hiện ra và phiên chết ngay khi một lệnh trả về thứ gì đó lớn. Echo còn chạy một lúc, rồi kết nối hết thời gian trong khi máy khách vẫn hiển thị đường hầm là đang bật. Một phiên khỏe mạnh cho đến khi dữ liệu đến thường đụng giới hạn kích thước chứ không phải lỗi SSH. Các kiểm tra dưới đây được sắp xếp để loại trừ lời giải thích rẻ nhất trước.

Đọc hình dạng của lỗi trước khi chạm vào hồ sơ

Gói nhỏ đi qua còn gói đầy thì không. Dấu nhắc, biểu ngữ hay một lần nhấn phím vừa dễ; danh sách thư mục, bản tải xuống hay khối dán thì không. Kích thước mà hành vi thay đổi chính là manh mối, không phải việc SSH là chương trình liên quan.

Cơ chế là việc dò tìm MTU của đường đi, phụ thuộc vào phản hồi. TCP chọn kích thước đoạn, và khi một bộ định tuyến trên đường không thể chuyển tiếp gói tạo ra, nó phải báo điều đó bằng thông điệp ICMP. Việc đóng gói làm gói ngoài lớn hơn gói trong, nên kích thước dùng được bên trong đường hầm luôn thấp hơn liên kết vật lý. Lọc những thông điệp ICMP đó ở bất cứ đâu và bên gửi không bao giờ nhận được chỉnh sửa, tiếp tục gửi đoạn đầy, và gói ngoài bị bỏ mà không báo gì.

Đo mức trần từ cả hai phía

So sánh MTU của đường hầm với liên kết vật lý trước khi đổi một trong hai. Một đường hầm đã sao chép giá trị vật lý đã cho bạn biết sự lệch nằm ở đâu.

Thử từ bên trong đường hầm bằng yêu cầu cấm phân mảnh, hạ tải trọng cho đến khi có phản hồi trở lại. Đối số kích thước chỉ đếm tải trọng, nên con số chạy được luôn thấp hơn MTU của giao diện. Cộng lại kích thước phần đầu nếu bạn cần con số của giao diện.

ip link show tun0
ping -M do -s 1380 10.9.0.1

Lặp lại phép thử với địa chỉ công khai của máy chủ từ bên ngoài đường hầm. Nếu các phép thử lớn cũng thất bại ở đó, giới hạn nằm trên đường đến máy chủ và không tùy chọn đường hầm nào dịch được nó. Phép so sánh đó giúp bạn khỏi chỉnh một máy khách vốn không phải vấn đề. Ghi lại cả hai kết quả trước khi mở tệp cấu hình.

mssfix và fragment làm việc khác nhau

mssfix giới hạn kích thước đoạn mà các kết nối TCP bên trong đường hầm công bố khi bắt tay. Đó là đòn bẩy đúng cho SSH, HTTPS và việc sao chép tệp, vì thế tình trạng treo thường biến mất ngay khi đặt nó. Nó không đụng chút nào đến tải trọng UDP.

Một đường hầm cũng chở dịch vụ UDP có thể vẫn hỏng sau khi SSH đã sửa, và kết quả đó khiến bất cứ ai cho rằng một tùy chọn phủ hết mọi thứ phải bối rối.

fragment là cơ chế kia và một công cụ khác. Nó chia các gói quá lớn trước khi đóng gói, chỉ áp dụng cho vận chuyển UDP, thêm chi phí cho mỗi datagram và được ghi nhận là phương án cuối cho việc dò tìm hỏng. Cả hai thiết lập phải khớp ở các đầu mút kết thúc đường hầm. Khi một đầu giới hạn còn đầu kia phân mảnh, sẽ có cảnh báo trong nhật ký và hành vi mà không ai đoán được từ các tệp.

Hạ MTU của giao diện là lựa chọn thô

Giảm MTU của giao diện ở cả hai đầu là công cụ thô. Nó báo cho mọi bên gửi bên trong một con số nhỏ hơn, điều này có tác dụng, và nó đặt chi phí đó lên toàn bộ lưu lượng thay vì các luồng TCP cần đến.

Chọn nó khi đường hầm chở lưu lượng bạn không thể giới hạn, hoặc khi máy khách là thiết bị mà bạn không kiểm soát hồ sơ. Áp dụng đối xứng và ghi giá trị bên cạnh hồ sơ. Một thay đổi áp dụng nửa vời còn tệ hơn không làm gì, vì nó trông như một bản sửa.

Thử lại bằng chính bản truyền đã bị treo

Kết nối lại để các thiết lập được nạp, mở kết nối mới và lặp lại lệnh đã đóng băng. Kích thước đoạn được thương lượng lúc bắt tay, nên một phiên sống qua lần kết nối lại vẫn mang giá trị cũ. Ping là phép thử yếu ở đây, vì toàn bộ lỗi là việc gói nhỏ đi qua được. Hãy dùng danh sách, bản tải xuống hay thao tác dán đã hỏng.

Nếu tình trạng treo vẫn tiếp diễn ở kích thước nhỏ hơn, hãy nhìn nơi khác: tường lửa có trạng thái làm luồng hết hạn, địa chỉ trùng, hoặc tuyến đường dịch chuyển khi kết nối lại. Ghi lại kích thước phép thử đã thất bại và thiết lập bạn đã đổi, vì chính cặp đó làm báo cáo sau hữu ích.