Vì sao trang OpenConnect treo cho đến khi bạn hạ MTU của đường hầm

Đăng nhập thành công, trang chủ của cổng thông tin được vẽ ra, rồi một tiện ích bảng điều khiển hoặc một báo cáo nằm ở waiting for host cho đến khi trình duyệt bỏ cuộc. Các trang công khai vẫn tải bình thường suốt thời gian đó, và không có thông tin đăng nhập nào thay đổi. Việc phản hồi nhỏ đến trong khi phản hồi lớn bị kẹt là dấu hiệu của trần kích thước gói chứ không phải quy tắc truy cập. Hãy xác nhận cách đọc đó trước khi sửa bất cứ thứ gì khác trong hồ sơ.

Tách vấn đề kích thước khỏi vấn đề chính sách

Bắt đầu bằng việc loại trừ khả năng bị từ chối. Nếu cổng từ chối bạn, kết nối sẽ thất bại ngay chứ không tải được nửa trang. Một đường hầm dựng lên rồi chỉ kẹt ở các lần truyền lớn hơn đang nói với bạn rằng đường bên ngoài không chở được gói bên trong.

Cơ chế là đóng gói. Mỗi gói bên trong nhận thêm phần đầu của đường hầm, nên phần tải vừa với liên kết vật lý trở thành gói bên ngoài không còn vừa nữa, và bất cứ thứ gì mang bit do-not-fragment đều bị bỏ mà không có phản hồi nào để trình duyệt diễn giải.

Đo trần bằng đầu dò do-not-fragment

Đo trần thay vì đoán nó. Gửi các đầu dò từ chối phân mảnh và hạ dần phần tải cho đến khi có phản hồi trở lại, bắt đầu bằng một lệnh như ping -M do -s 1472 host. Một phản hồi phàn nàn rằng cần phân mảnh trong khi DF đã đặt nghĩa là giá trị vẫn còn quá cao. Lặp lại ở 1462, rồi 1452, và dừng ở kích thước đầu tiên trả lời. Ghi lại con số cùng với máy chủ bạn đã thử, vì câu trả lời thuộc về đường đó chứ không phải giao thức nói chung.

Thử địa chỉ mà đường hầm thật sự gửi lưu lượng tới. Một đầu dò bên ngoài nhắm vào tên công khai của cổng và một đầu dò bên trong nhắm vào máy chủ nội bộ đo những bước nhảy khác nhau, và việc lọc ICMP trên một trong hai có thể khiến một đường lành trông như hỏng.

Áp dụng giá trị cho thiết bị đường hầm

Áp dụng kết quả cho giao diện mà ứng dụng khách tạo ra, không phải cho bộ điều hợp Wi-Fi. Trên ứng dụng khách Linux thì đó là ip link set dev tun0 mtu 1300 tiếp theo là ip link show tun0 để xác nhận giá trị đã được nhận. Dùng bất kỳ tên thiết bị nào ứng dụng khách báo cáo, vì nó thay đổi theo cách hiện thực và theo cách đường hầm được dựng.

Hạ MTU của đường hầm làm nhỏ phần tải mà mỗi gói mang, nên thông lượng tổng giảm một chút, và đó là cái giá của việc không ném các phản hồi lớn vào hố đen. Một con số nhỏ hơn không tự động an toàn hơn. Đổi bộ điều hợp vật lý thay vào đó lại rải hư hại lên mọi kết nối trên liên kết ấy trong khi các gói bên trong quá cỡ vẫn quá cỡ như cũ.

Trước hết hãy dùng các yêu cầu MTU của chính ứng dụng khách

Khi bạn kiểm soát lệnh gọi, ứng dụng khách có thể yêu cầu một kích thước thay vì bị vá sau đó. --mtu yêu cầu máy chủ một MTU đường hầm, và --base-mtu khai báo MTU của đường bên dưới để cổng có thể suy ra con số của đường hầm. Cả hai đều là yêu cầu, và hướng dẫn của ứng dụng khách không hứa rằng cổng sẽ tuân theo một trong hai.

Sự phân biệt đó quyết định thứ tự công việc của bạn. Thử yêu cầu trước và xem giao diện mà nó tạo ra, rồi quay lại đặt thiết bị cục bộ nếu giá trị cổng chọn vẫn kẹt.

Xác minh bằng lần truyền đã thất bại, rồi làm cho nó bền vững

Một thay đổi ip link cục bộ kéo dài cho đến khi ứng dụng khách dựng lại đường hầm, điều xảy ra ở lần kết nối lại hoặc tiếp tục kế tiếp. Đặt giá trị ở nơi kết nối bắt đầu: một trình bao chạy ứng dụng khách rồi chỉnh thiết bị, một đơn vị systemd có bước ExecStartPost, hoặc tùy chọn của ứng dụng khách khi cổng chấp nhận. Giữ nó cạnh hồ sơ trong kiểm soát phiên bản để người sau thấy vì sao con số ở đó.

Thử bằng yêu cầu đã thất bại, không phải bằng trang chủ. Mở báo cáo, tải tệp đính kèm, hoặc chạy lần lấy kho đã treo, và ghi chính xác nó dừng ở đâu nếu vẫn dừng. Một trang được vẽ sau thay đổi chứng minh được ít, vì trước đó nó cũng được vẽ.

Nếu cùng lần truyền đó kẹt ở cùng điểm, thì lý thuyết MTU chưa được chứng minh. Bắt lưu lượng trên đường hầm và kiểm tra bên nào ngừng gửi trước khi đổi con số lần nữa, và giữ giá trị trước đó được ghi lại để việc hoàn tác vẫn là một lệnh duy nhất.