Vì sao đường hầm chia tách không bao phủ bản cập nhật của ứng dụng

Bạn thêm ứng dụng vào danh sách loại trừ của đường hầm chia tách, ứng dụng ra internet trực tiếp, và bản cập nhật vẫn thất bại hoặc vẫn bò qua đường hầm. Việc loại trừ đã có tác dụng. Nó chỉ bao phủ một tiến trình khác với tiến trình thực hiện việc tải, vì trình cập nhật hiện đại hiếm khi là cùng một tệp thực thi như cửa sổ ứng dụng.

Lầm tưởng: loại trừ ứng dụng là loại trừ lưu lượng của nó

Đường hầm chia tách theo từng ứng dụng khớp một tiến trình, một gói hoặc một đường dẫn ứng dụng, tùy theo nền tảng. Nó không khớp một thương hiệu, một tính năng hay ý định của người dùng. Khi ứng dụng giao việc tải cho một trình hỗ trợ, một dịch vụ nền tảng dùng chung hoặc một thành phần trình duyệt, trình hỗ trợ đó có danh tính riêng và đường đi riêng qua đường hầm. Danh sách loại trừ không hề biết hai tiến trình thuộc cùng một sản phẩm. Nó chỉ biết bạn đã nêu tên cái nào.

Vậy quy tắc đang làm đúng điều được bảo. Giả định về ai sở hữu việc truyền là sai, và cách sửa bắt đầu bằng việc xác định chủ sở hữu đó thay vì thêm nhiều trường hợp loại trừ hơn.

Tìm chủ sở hữu của việc truyền

Trên Android, bản cập nhật có thể do một gói dịch vụ dùng chung tải về thay vì gói ứng dụng bạn đã loại trừ, và một quy tắc VPN theo từng ứng dụng áp dụng cho gói mở socket. Trên Windows, dịch vụ cập nhật có thể chạy dưới một đường dẫn thực thi khác với ứng dụng, nên một quy tắc khớp đường dẫn ứng dụng sẽ bỏ sót nó. Trên macOS, một trình hỗ trợ đặc quyền hoặc một daemon cập nhật hệ thống có thể thực hiện việc truyền trong khi ứng dụng chỉ yêu cầu.

Xác định chủ sở hữu từ bằng chứng: chế độ xem hoạt động mạng của nền tảng, một bản bắt gói được lọc theo tiến trình hoặc tài liệu của nhà cung cấp nêu tên thành phần cập nhật. Đoán từ tên tiến trình là cách hai tệp nhị phân trông giống nhau bị nhầm lẫn và cái sai bị loại trừ.

Các hệ thống cập nhật cũng thường chia việc. Một yêu cầu siêu dữ liệu nhỏ kiểm tra phiên bản, và một lần tải gói lớn hơn nhiều đi tới máy chủ phân phối nội dung hoặc một tên miền khác. Việc kiểm tra siêu dữ liệu có thể thành công qua đường hầm trong khi việc truyền gói bị kẹt trên một máy chủ mà đường hầm định tuyến khác đi. Sự phân chia đó giải thích báo cáo khó hiểu nơi các bản cập nhật được phát hiện nhưng không bao giờ được cài. Hãy thử chính việc tải gói, từ cùng thiết bị và cùng mạng, thay vì thử xem ứng dụng có mở được không.

Việc kiểm tra vẫn tồn tại qua thay đổi tuyến

Đổi tuyến không thay thế TLS, danh tính nhà phát hành hay việc kiểm tra chữ ký gói. Đừng tắt những kiểm tra đó chỉ vì một lần tải chỉ thành công sau khi bạn bỏ qua một cảnh báo chứng chỉ không giải thích. Một cảnh báo chỉ xuất hiện trên tuyến bị loại trừ là một phát hiện, không phải trở ngại. Hãy điều tra nó trước khi mở rộng việc né tránh.

Trên thiết bị được quản lý, hãy yêu cầu một ngoại lệ được hỗ trợ thay vì thêm một quy tắc rộng cho mọi dịch vụ hệ thống. Một quy tắc loại trừ mọi dịch vụ dùng chung để sửa một trình cập nhật sẽ mở rộng việc né tránh vượt xa yêu cầu ban đầu.

Thử bản cập nhật, rồi ghi lại chủ sở hữu

Kết nối lại sau thay đổi và xác minh lại quy tắc đã áp dụng, vì một số máy khách dựng lại định tuyến khi đường hầm kết nối lại. Chạy một chu kỳ cập nhật đầy đủ: kiểm tra, tải, xác minh và cài đặt. Một lần kiểm tra thành công chỉ chứng minh phần nhỏ nhất của tuyến.

Ghi lại chủ sở hữu việc truyền, các máy chủ đích và tuyến dự kiến ở cùng nơi với quy tắc đường hầm chia tách. Nếu không, lần thay đổi cơ chế cập nhật tiếp theo sẽ âm thầm vô hiệu hóa ngoại lệ, và người thừa hưởng nó sẽ không có cách nào biết quy tắc được viết cho tiến trình nào.