MTU của VPN trên iPhone: xác định chủ sở hữu trước khi đổi một con số

Mọi thảo luận về kích thước gói của VPN trên iPhone cuối cùng đều đưa ra cùng một lệnh Mac áp cho một giao diện tên là ppp0, thường kèm một con số. Nó không chuyển được, và nó cũng không phải là cách điều khiển đúng ngay cả trên Mac trừ khi giao diện đó thuộc về kết nối đang bàn. Trên điện thoại, con số thuộc về người triển khai đường hầm: hệ điều hành với hồ sơ gốc, nhà cung cấp đường hầm gói với ứng dụng, hoặc cổng khi một thuộc tính được ghi tài liệu được thương lượng. Ba câu hỏi xác định bạn đang gặp trường hợp nào.

Câu hỏi một: ứng dụng khách nào đang chạy

Hồ sơ IKEv2 gốc, hồ sơ Cisco IPsec tích hợp và ứng dụng khách Cisco của bên thứ ba là ba cách triển khai khác nhau với ba bộ thuộc tính được hỗ trợ khác nhau. Loại hồ sơ trong Cài đặt cho biết điện thoại thực sự đã khởi động cái nào, và danh sách ứng dụng cho biết có nhà cung cấp trên đường hay không. Hãy bắt đầu từ đó, vì phần còn lại của quyết định bắt nguồn từ đây. Nếu không có nhà cung cấp nào xuất hiện trong danh sách ứng dụng thì hệ điều hành sở hữu đường hầm.

Đừng suy ra cách triển khai từ nhà cung cấp cổng. Một headend Cisco có thể kết thúc kết nối từ những ứng dụng khách không có gì chung ngoài tên nhà cung cấp. Ảnh chụp màn hình của một bản dựng cũ trên bản phát hành cũ cho biết cặp đó đã hỗ trợ gì, không phải chiếc điện thoại trong tay bạn làm gì.

Câu hỏi hai: ai sở hữu giá trị

Apple công bố thuộc tính MTU cho nhà phát triển đường hầm gói thông qua đối tượng cài đặt của tiện ích mạng. Đó là API cho nhà cung cấp tự cấu hình đường hầm của mình, không phải công tắc mà người dùng hay quản trị viên có thể bật trên ứng dụng khách đã cài của người khác. Một ứng dụng bên thứ ba có thể chọn công bố, bỏ qua hoặc mã hóa cứng một giá trị.

Với hồ sơ gốc, hệ điều hành chọn kích thước giao diện và điện thoại không cung cấp trình chỉnh sửa nào cho việc đó. Với cổng Cisco dùng cho truy cập từ xa, có một thuộc tính được ghi tài liệu cho hồ sơ kết nối, và việc nó có áp dụng hay không phụ thuộc vào ứng dụng khách, bản phát hành và giao vận đã thương lượng. Chính trong khoảng trống giữa được ghi tài liệu và được tuân thủ đó, con số sao chép mới sai.

Câu hỏi ba: triệu chứng có phụ thuộc vào kích thước không

Vấn đề kích thước có một chữ ký: yêu cầu nhỏ thành công, tải lên lớn hoặc phản hồi lớn bị treo, và cùng dịch vụ đó lại chạy được qua một mạng truy cập khác. Lọc gói, giới hạn tải trọng của ứng dụng và máy chủ bị kẹt cũng có thể tạo ra phàn nàn tương tự, nên hãy ghi lại thao tác thất bại bên cạnh một thao tác thành công. Ghi cả hai kèm thời gian và kích thước nếu ứng dụng báo cáo. Không có cặp đó, mọi thay đổi về sau chỉ là phỏng đoán.

Chạy cùng bài kiểm tra trên Wi-Fi và trên mạng di động. Lỗi đi theo mạng chỉ ra đường truyền; lỗi đi theo thiết bị chỉ ra ứng dụng khách hoặc hồ sơ, và hai bên cần những người sở hữu khác nhau. Dùng cùng dịch vụ và cùng tài khoản cho cả hai lần chạy, nếu không thì so sánh chẳng nói lên điều gì.

Vì sao công thức Mac cứ lặp lại

Những năm của VPN máy tính để bàn dựa trên PPP đã biến việc đổi kích thước giao diện thành một cách xử lý cục bộ hợp lệ, và những hướng dẫn đó được sao chép sang các thảo luận di động. Trên điện thoại không có shell, không có tên giao diện như vậy và không có sự tồn tại qua lần kết nối lại. Một công thức đã giải quyết vấn đề máy tính để bàn năm 2011 đã đi xa hơn nhiều so với những điều kiện khiến nó đúng. Ứng dụng khách di động không chấp nhận bất kỳ lệnh shell nào cho việc này, bất kể thảo luận nói gì.

Hãy coi giá trị sao chép là một giả thuyết về đường truyền, không phải một cài đặt. Nếu kích thước nhỏ hơn làm một lần truyền chạy được và kích thước lớn hơn thất bại một cách đáng tin cậy, bạn có bằng chứng về đường truyền; vẫn phải tìm thành phần được phép tác động lên nó. Việc tìm kiếm đó thường kết thúc ở hồ sơ cổng hoặc ở nhà cung cấp ứng dụng, và hiếm khi ở điện thoại.

Giao vận thay đổi câu trả lời

Nếu phiên chạy qua TLS thay vì IPsec, việc điều chỉnh phân đoạn TCP trên cổng có thể giúp, vì nó viết lại kích thước phân đoạn được quảng bá cho các luồng TCP. Nó không làm gì cho lưu lượng UDP, vốn bao gồm phần lớn hơn của web hiện đại so với người ta tưởng. Hãy kiểm tra giao vận đã thương lượng trước khi đề xuất thay đổi, và ghi trong phiếu giao vận nào bạn mong sẽ bị ảnh hưởng.

Việc phát hiện MTU đường truyền tồn tại để các điểm cuối học được giới hạn thực thay vì đoán. Chặn phản hồi và mã hóa cứng một kích thước nhỏ đánh đổi một lần truyền lớn đang chạy được lấy một chi phí thường trực, ẩn giấu trên mỗi kết nối.

Cần hỏi nhóm cổng những gì

Hãy hỏi ba điều: tên thuộc tính chính xác và phạm vi của nó, liệu các ứng dụng khách đã triển khai có tuân thủ không, và phiên đã thương lượng giao vận nào. Một thay đổi áp cho một chính sách nhóm thì kiểm chứng được; chỉnh sửa toàn cục thì không, và nó đẩy rủi ro sang những người dùng chưa từng báo cáo sự cố. Cũng xin tham chiếu tài liệu, vì tên thuộc tính thay đổi giữa các bản phát hành.

Sau đó chỉ đổi một thứ và kiểm tra lại thao tác gốc bị lỗi, không phải một lượt tải xuống của bài kiểm tra tốc độ. Giữ bản ghi trước và sau cùng phiên bản ứng dụng khách và mạng truy cập, để báo cáo tiếp theo có thể được so sánh thay vì tranh luận lại.

Nếu thao tác vẫn lỗi ở kích thước gốc thì kích thước không phải nguyên nhân. Hãy ghi lại kết luận đó, để người tiếp theo không mở lại cùng giả thuyết.