Trang tải được nhưng tải lên bị treo trên VPN: nguyên nhân nào thắng
Tình trạng treo phụ thuộc kích thước khớp với lỗi MTU của đường đi, và cũng khớp với DNS, giới hạn ứng dụng hay một đường hầm không ổn định. Bốn quan sát quyết định nguyên nhân nào.
Trang tải được, VPN báo đã kết nối, và việc tải tệp lên đóng băng ở cùng một điểm mỗi lần. Bốn cách giải thích khớp với mô tả đó: vấn đề kích thước gói, vấn đề phân giải tên, giới hạn của ứng dụng và một đường hầm liên tục đặt lại. Mỗi cách có thể được xác nhận hoặc loại trừ bằng một quan sát khác, nên quyết định là chọn đúng phép thử thay vì đoán nguyên nhân.
Bốn ứng viên và một hình dạng
Bắt đầu từ hình dạng của sự cố, vì nó loại bỏ phần lớn danh sách trước khi mở bất kỳ công cụ nào. Treo xảy ra ở một kích thước cố định là vấn đề kích thước cho đến khi chứng minh ngược lại. Treo ở các điểm ngẫu nhiên là vấn đề mất gói hoặc ổn định. Thất bại trước khi kết nối mở là vấn đề tên.
Ứng viên thứ tư là ứng dụng. Giới hạn tải lên, thời gian chờ của yêu cầu và mức trần kích thước phần thân ở proxy tạo ra những thất bại mà từ trình duyệt trông như lỗi mạng, và chúng thường đến dưới dạng từ chối chứ không phải treo.
Ghi lại hình dạng quan sát được trước khi thử bất cứ điều gì. "Dừng ở khoảng cùng số byte, mỗi lần, khi đường hầm đang bật" là điểm khởi đầu mạnh hơn nhiều so với "tải lên không hoạt động".
Sau đó giữ cố định đường đi trong khi thử. Thay đổi đầu ra, giao thức và máy chủ cùng lúc cho ra kết quả mà bạn không thể quy cho bất kỳ cái nào. Một biến mỗi lần chạy, và ghi lại.
Chia đôi kích thước trước khi chạm vào chính sách
Bộ phân biệt rẻ nhất là một phép thử thay đổi một con số. Gửi ping không phân mảnh với kích thước tăng dần tới đích, tải tệp bạn kiểm soát lên cùng dịch vụ, rồi so sánh nơi mỗi cái dừng lại.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadLệnh đầu tiên cho biết liệu một gói kích thước đầy đủ có đi qua đường đi hay không. Với MTU 1500 byte, tải trọng ICMP lớn nhất không bị phân mảnh là 1472 byte, và đường hầm lấy thêm từ ngân sách đó trước khi gói bên trong bắt đầu. Lệnh thứ hai cho bạn kích thước và thời lượng cho một lần truyền ở mức ứng dụng, và đó là con số thực sự quan trọng.
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
Đọc cả hai cùng nhau. Các phép thử thất bại trên một ngưỡng và việc tải lên dừng gần cùng ngưỡng đó là một câu chuyện mạch lạc. Các phép thử đều thành công trong khi việc tải lên treo ở một số byte mà đường đi rõ ràng chuyên chở được chỉ về ứng dụng hoặc máy chủ, và không công việc MTU nào sẽ thay đổi điều đó. Kết quả phủ định đó có giá trị ngang một kết quả khẳng định. Nó loại bỏ nhánh điều tra đắt nhất.
Sau đó kiểm tra độ ổn định trong khi truyền, vì một đường hầm làm mới khóa giữa lúc tải lên lớn tạo ra thất bại trông như phụ thuộc kích thước mà không phải vậy. Đọc thời gian hoạt động là cách rẻ nhất để xác nhận điều đó.
Chọn giữa sửa chữa và lách
Nếu bằng chứng chỉ về kích thước, có hai câu trả lời trung thực và một câu trả lời không trung thực. Các câu trung thực là khôi phục việc dò MTU của đường đi bằng cách cho phép phản hồi ICMP cần thiết, hoặc giới hạn kích thước đoạn được công bố để các bên gửi đoạn nhỏ hơn. Câu không trung thực là hạ MTU của một giao diện xuống một giá trị chép từ diễn đàn và không bao giờ kiểm tra nó đã thay đổi điều gì.
Lựa chọn phụ thuộc vào việc bạn kiểm soát cái gì. Trên mạng bạn vận hành, cho phép các thông điệp ICMP là cách sửa sạch hơn vì nó giữ cơ chế hoạt động cho mọi giao thức. Trên một đường bạn không kiểm soát, giới hạn là lựa chọn thực tế, và nó nên được áp dụng hẹp chứ không phải toàn máy chủ.
Nếu bằng chứng chỉ về ứng dụng, sửa ứng dụng hoặc cấu hình proxy của nó. Phản hồi 413 và kết nối bị treo là những thất bại khác nhau, và cái thứ hai thường là hết thời gian ở đâu đó trong một chuỗi có proxy với giới hạn riêng.
Dù thế nào, hãy giữ các giá trị gốc và kiểm tra lại sau khi hoàn tác. Một thay đổi trùng với lần truyền thành công không phải bằng chứng rằng nó đã gây ra, và khả năng hoàn tác là thứ phân biệt chẩn đoán với sự trùng hợp.
Ghi lại quyết định để nó sống sót qua sự cố tiếp theo
Bốn sự kiện là đủ: hình dạng thất bại quan sát được, kết quả các phép thử, thay đổi bạn đã làm và kết quả kiểm tra lại. Với chúng, người tiếp theo có thể nói vấn đề là cũ hay mới với cùng triệu chứng.
Cũng ghi lại bối cảnh đường đi, vì một phát hiện về MTU là riêng cho một liên kết. Một laptop hoạt động ở nhà và thất bại ở khách sạn có hai đường, và một bản sửa áp dụng cho một trong hai không nói gì về đường còn lại.
Cuối cùng, chống lại tóm tắt rằng "VPN đã làm hỏng việc tải lên". Đường hầm có mặt cả trong trường hợp chạy được và trường hợp thất bại; điều đã thay đổi là kích thước gói mà đường phải chuyên chở, hoặc nơi việc truyền bị dừng. Gọi tên đúng cơ chế là điều làm cho ghi chú hữu ích.