Ping qua VPN chạy được nhưng trang web bị treo: kiểm tra kích thước

Phản hồi echo đến, máy tính để bàn từ xa hoạt động, còn trình duyệt đứng ở trang trắng cho đến khi bỏ cuộc. Hai cách giải thích phù hợp với mẫu đó, và chúng không phải biến thể của một vấn đề: một chính sách chưa bao giờ cho phép dịch vụ, hoặc các gói không còn vừa khi lưu lượng lớn dần. Phản hồi echo không loại trừ cả hai.

Đi từ câu hỏi nhỏ nhất đến lớn nhất, và ghi lại mỗi bước thực sự chứng minh điều gì.

Một phản hồi echo trả lời một câu hỏi nhỏ hơn nhiều

Một phản hồi echo nói rằng ngăn xếp IP của đích đã trả lời một yêu cầu ICMP từ nguồn của bạn. Nó không nói gì về việc có trình lắng nghe TCP trên cổng bạn cần hay không, liệu một chính sách có cho phép cổng đó hay không, hay liệu máy chủ đích có lọc lưu lượng độc lập với cổng vào hay không. Một cổng vào cho phép một dịch vụ có thể bỏ rơi dịch vụ khác trong khi cả hai đích đều trả lời ping. Hãy đọc phản hồi như một sự thật duy nhất về một gói và một hướng.

Xác nhận đích và cổng dịch vụ trước khi diễn giải bất cứ điều gì khác. Địa chỉ bạn đã kiểm tra và địa chỉ ứng dụng dùng đôi khi là các bản ghi khác nhau, và một tên phân giải thành hai địa chỉ khiến điều đó có khả năng.

Tìm hiểu xem kết nối đã bắt đầu chưa

Một kết nối bị từ chối ngay lập tức là câu trả lời của trình lắng nghe hoặc của chính sách: có thứ gì đó trả lời và nói không. Một kết nối mở ra rồi kẹt khi dữ liệu bắt đầu di chuyển chỉ về kích thước. Một kết nối không bao giờ hoàn tất bắt tay thường là chính sách hoặc định tuyến, và trông giống hết thời gian chứ không giống từ chối.

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

Ghi lại bạn đã quan sát trường hợp nào trong ba trường hợp đó trước khi chạm vào cài đặt MTU. Thay đổi kích thước đường hầm để sửa một kết nối bị từ chối làm lãng phí thay đổi đó và che giấu nguyên nhân thật trong một thời gian.

Đo kích thước bằng một con số được nêu

Khi hiện tượng kẹt xuất hiện dưới tải, thử một kích thước gói với bit cấm phân mảnh được đặt và nêu phép tính để kết quả có ý nghĩa. Trên Linux có iputils, tải trọng 1392 byte cộng phần đầu ICMP 8 byte và phần đầu IPv4 20 byte tạo ra gói bên trong đúng 1420 byte. Hãy nêu phép tính đó trong phiếu, vì một ping trần đến được cổng vào không chứng minh gì về ứng dụng.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

Cả hai phép thử đều là điểm đo, không phải khuyến nghị về kích thước đường hầm. Nếu ICMP bị lọc ở đâu đó trên đường đi, thời gian chờ không cho bạn biết gì về kích thước, vì lọc và một gói quá lớn trông giống nhau từ phía máy khách. Thành công cũng không nói gì về hướng ngược lại hay về một đích khác.

Tính đến đường đi bên ngoài

Đóng gói thêm các phần đầu của chính nó, nên gói trên dây lớn hơn gói bạn đo bên trong đường hầm. Chính khoảng chênh giữa hai gói khiến một yêu cầu nhỏ chạy được và một yêu cầu lớn thất bại có thể cùng tồn tại.

Việc phát hiện MTU đường đi trong IPv4 phụ thuộc vào phản hồi về các gói không thể chuyển tiếp mà không phân mảnh, còn IPv6 dùng thông điệp Packet Too Big. Đặc tả IPv4 mô tả cơ chế đó. Lọc phản hồi làm hỏng khả năng học của bên gửi và khiến nó gửi lại những gói sẽ không bao giờ vừa. Đó là lý do một yêu cầu nhỏ chạy được và một yêu cầu lớn thất bại cùng tồn tại thoải mái đến vậy.

Đổi một con số và thử lại ứng dụng

Hạ MTU của đường hầm, hoặc giới hạn kích thước phân đoạn tối đa cho TCP, rồi lặp lại phép thử ban đầu của ứng dụng thay vì phép thử dò. Một phép thử thành công sau thay đổi và một ứng dụng vẫn kẹt là vấn đề khác có hình dạng tương tự, và chỉ phép thử ứng dụng mới phân biệt được chúng.

Giữ phép tính trong bản ghi thay đổi: kích thước đã đo, phần chi phí thêm bạn giả định và giá trị bạn đặt. Ai xem lại sau này có thể kiểm tra giả định thay vì suy ra nó lần nữa từ ảnh chụp màn hình một lệnh ping.

Nếu ứng dụng chạy ở mọi kích thước bạn đã thử, hãy ngừng chỉnh số và xem chính sách phân tách dịch vụ chạy được khỏi dịch vụ thất bại.