Hai yêu cầu nghe có vẻ tương đương thì không phải vậy: «loại trừ ứng dụng này khỏi VPN» và «gửi đích duy nhất này ra ngoài VPN cho máy tính xách tay trên hotspot của tôi». Yêu cầu thứ nhất thay đổi cách một socket trên điện thoại chọn mạng. Yêu cầu thứ hai phải thay đổi quyết định chuyển tiếp cho một gói đến từ thiết bị khác sau khi điện thoại đã chấp nhận nó. Nhầm lẫn hai điều này là cách một máy khách hotspot kết thúc với một ngoại lệ chỉ từng áp dụng cho trình duyệt của chính điện thoại.

Hai hệ thống con sở hữu hai câu hỏi

Android giữ riêng mạng của ứng dụng và tính năng chia sẻ kết nối. Các socket của ứng dụng được ngăn xếp kết nối gán cho một mạng, và một ứng dụng VPN quyết định socket nào của chính nó đi vào tunel. Các gói được chuyển tiếp từ máy khách đã kết nối do hệ thống con chia sẻ kết nối xử lý, hệ thống này hỏi netd về tuyến đường, quy tắc chính sách và chuyển đổi trên giao diện xuôi.

Việc loại trừ theo ứng dụng được đánh giá khi một ứng dụng mở socket. Gói được chuyển tiếp không bao giờ đi đến bước kiểm tra đó, vì nó không bắt nguồn từ một socket ứng dụng trên thiết bị này. Đó là toàn bộ lý do hai thiết lập không thể thay thế nhau, và đó không phải lỗi ở cả hai.

Loại trừ theo ứng dụng thực sự thay đổi điều gì

Trình tạo VpnService có thể đặt tên các gói ở ngoài tunel bằng addDisallowedApplication, hoặc đặt tên các gói duy nhất được phép ở trong bằng addAllowedApplication. Những ứng dụng đó sau đó mở socket trên mạng bên dưới trong khi VPN tiếp tục sở hữu tuyến mặc định cho mọi thứ khác.

Phạm vi chính xác: socket của chính gói, trên thiết bị này, chừng nào tunel còn hoạt động. Nó không nói gì về lưu lượng được chuyển tiếp, không nói gì về thiết bị thứ hai và không nói gì về các gói mà hệ thống gửi thay mặt tính năng chia sẻ kết nối.

Nó cũng không phải kiểm soát đích. Loại trừ một trình duyệt loại trừ mọi địa chỉ mà trình duyệt đó chạm tới, kể cả địa chỉ bạn muốn giữ trong tunel. Khi yêu cầu nêu đích thay vì ứng dụng, trình chọn ứng dụng là công cụ sai ngay từ cấu trúc.

Một gói được chia sẻ trông như thế nào với điện thoại

Gói của máy khách đến giao diện hotspot với một địa chỉ nguồn riêng do điện thoại cấp, giả sử 192.168.43.20, và một đích công cộng. Để chuyển tiếp nó, điện thoại cần một tuyến đến liên kết thượng nguồn và một quy tắc chuyển đổi để các phản hồi tìm được đường về, vì địa chỉ riêng của máy khách vô nghĩa trên mạng di động.

Android diễn đạt điều đó bằng các quy tắc chính sách chọn bảng định tuyến, và netd dựng lại các bảng cùng quy tắc liên quan khi mạng và VPN thay đổi. Số bảng, độ ưu tiên quy tắc hoặc tên giao diện sao chép từ một bài đăng diễn đàn, hoặc từ cùng mẫu máy ở bản phát hành cũ hơn, không tạo ra quyền sở hữu lâu bền. Việc dựng lại đó cũng là lý do một quy tắc viết tay có thể chạy một giờ rồi dừng sau lần kết nối lại tiếp theo.

Một ngoại lệ hotspot thực sự cần chính sách nào

Viết quyết định thành nguồn, đích và đường đi dự định trước khi chạm vào một quy tắc. Dạng tối thiểu cho một đích đã được phê duyệt trông như sau:

SourceDestinationIntended path
One authorized hotspot clientOne approved public service addressOrdinary cellular uplink
The same clientAll other covered destinationsShared VPN
The phone's own appsTheir existing destinationsUnchanged phone policy

Cả hai chiều đều phải đầy đủ. Nhánh trực tiếp cần một tuyến dùng được qua liên kết thượng nguồn di động đang là hiện tại; nhánh VPN cần tuyến của tunel cùng quyền chuyển tiếp. Mọi chuyển đổi nguồn phải khớp với lối ra bạn đã chọn, vì NAT áp trên giao diện tunel hiển thị địa chỉ của tunel chứ không phải địa chỉ di động, và khi đó đường về không khớp với đường đi.

Các phản hồi phải đến cùng máy khách xuôi qua trạng thái được theo dõi hoặc một tuyến rõ ràng, và bộ đếm gói đi ra không chứng minh được điều nào trong số đó. Giữ cả phần vận chuyển bên ngoài của chính VPN ngoài phạm vi ngoại lệ, nếu không các gói mang của tunel sẽ thừa hưởng một chính sách được viết cho yêu cầu web của máy khách.

Một địa chỉ bị bắt không phải là đích

Một địa chỉ IPv4 duy nhất đọc từ trình duyệt là một ảnh chụp tức thời. Các dịch vụ lớn trả lời từ anycast hoặc từ một tập địa chỉ biên luân phiên, nhiều dịch vụ dùng hai ngăn xếp, và một luồng đăng nhập có thể chạm tới các máy chủ xác thực và đo từ xa mà trang không bao giờ hiển thị. Một ngoại lệ dựng quanh địa chỉ bạn tình cờ thấy sẽ vỡ vào lần tiếp theo dịch vụ cân bằng lại tải.

Dùng các địa chỉ được chủ dịch vụ ghi lại, hoặc một dải mà họ công bố, và tính đến cả hai họ địa chỉ. Nếu yêu cầu không thể diễn đạt thành một tập ổn định, đó có lẽ là câu hỏi chính sách cho dịch vụ chứ không phải mẹo định tuyến trên điện thoại.

Xác minh từ phía xuôi

Ba kiểm tra, theo thứ tự này: dịch vụ đã chọn từ máy tính xách tay, một đích thông thường phải ở trong VPN, và một ứng dụng trên điện thoại phải không bị ảnh hưởng. Sau đó lặp lại sau khi kết nối lại và sau khi thay đổi liên kết thượng nguồn, vì đó là lúc các bảng chính sách được dựng lại.

Nếu phần triển khai chia sẻ của điện thoại không giữ được hợp đồng đó qua một lần kết nối lại, hãy chuyển chính sách chọn lọc sang một bộ định tuyến xuôi được hỗ trợ thay vì tích lũy quy tắc root trên máy. Bộ định tuyến có thể diễn đạt việc khớp nguồn và đích với một chủ sở hữu ổn định, và tài liệu của mô-đun chia sẻ kết nối là tham chiếu đúng cho những gì điện thoại thực sự làm.

Bài viết liên quan