Split tunneling theo ứng dụng hay theo đích đến: chọn cách nào

Split tunneling theo ứng dụng và theo đích đến không phải hai thiết lập cho cùng một việc. Cái này hỏi tiến trình nào đang gửi gói tin; cái kia hỏi gói tin đó đi đâu. Một quy tắc dựng cho câu hỏi đầu sẽ âm thầm thất bại khi lưu lượng đến từ một tiến trình phụ, và quy tắc dựng cho câu hỏi thứ hai thất bại khi một tên máy chủ phân giải thành địa chỉ mà bạn chưa bao giờ liệt kê. Hãy chọn đối tượng khớp với yêu cầu, rồi chứng minh bằng hai gói tin thử: một gói phải dùng tunnel và một gói không được dùng.

Hai quy tắc khớp ở các tầng khác nhau

Quy tắc ứng dụng được áp dụng phía trên tầng mạng, dựa trên danh tính mà hệ điều hành gán cho bên gửi. Trên Android đó là UID phía sau một gói, và dịch vụ VPN quyết định theo từng UID liệu lưu lượng có vào tunnel hay không. Không có gì được hỏi về đích đến, nên ứng dụng được chọn có thể chạm tới mọi thứ và không ứng dụng nào khác chạm tới mạng nội bộ.

Quy tắc đích đến được áp dụng trên chính gói tin. Giao diện tunnel sở hữu một tập tiền tố, bảng định tuyến đưa lưu lượng khớp vào đó, và tiến trình gửi không liên quan. Đó là lý do một quy tắc đích đến bao phủ một dịch vụ, một máy in hay một tác vụ hàng loạt mà không ai nhớ liệt kê, và cũng là lý do không thể diễn đạt nó thành đúng chương trình này trên một nền tảng mà ứng dụng khách không bao giờ nhìn vào tiến trình.

Quy tắc ứng dụng phù hợp với ứng dụng khách di động và tác nhân được quản lý

Android trình bày lựa chọn trực tiếp: VpnService.Builder.addAllowedApplication() và addDisallowedApplication() nhận tên gói và áp dụng quyết định theo từng UID, như mô tả trong hướng dẫn nhà phát triển VPN của Android. iOS có tương đương qua các quy tắc VPN theo từng ứng dụng dựa trên định danh gói, thường được phân phối qua hồ sơ MDM thay vì gõ tay.

Ứng dụng khách trên máy tính để bàn là điểm yếu. Hầu hết ứng dụng VPN trên Windows và macOS định tuyến theo đích đến và không cung cấp bộ chọn theo tiến trình nào cả, vì trình điều khiển tunnel nhìn thấy gói tin chứ không thấy tiến trình. Nếu kế hoạch của bạn phụ thuộc vào việc tạo tunnel cho một ứng dụng trên máy tính xách tay, hãy kiểm tra khả năng thực tế của ứng dụng khách trước khi thiết kế quanh nó; có thể bạn đang chọn giữa danh sách đích đến và một máy thứ hai.

Một hệ quả mà mọi người bỏ qua: trên những nền tảng đó bạn không thể bắt chước quy tắc ứng dụng bằng route. Thêm một route máy chủ cho server của ứng dụng sẽ đưa lưu lượng của mọi người vào tunnel tới server đó, kể cả trình duyệt và trình cập nhật.

Quy tắc đích đến phù hợp với danh sách subnet và khả năng tiếp cận trang

WireGuard làm rõ mô hình. AllowedIPs là định tuyến khóa mã hóa: một gói bên trong có đích đến nằm trong danh sách của một peer sẽ được mã hóa tới peer đó, còn mọi thứ khác đi ra không mã hóa theo đường bình thường. Không có tiến trình nào để đặt tên và không có sự mơ hồ về những gì được bao gồm.

OpenVPN đến cùng chỗ thông qua bảng định tuyến được đẩy xuống. route-nopull ngăn server áp đặt route, sau đó một route 10.20.0.0 255.255.0.0 vpn_gateway phía máy khách bao phủ chính xác tiền tố văn phòng. IPv6 là một câu lệnh riêng trong từng ứng dụng khách này, và quên nó là cách phổ biến nhất để rò rỉ quanh một split IPv4 trông có vẻ đúng.

Tên máy chủ không phải route. Nếu hồ sơ cung cấp trường tên miền, hãy coi đó là tên mà ứng dụng khách phân giải một lần, không phải một dải địa chỉ cố định; mạng phân phối nội dung và bộ cân bằng tải sẽ cấp địa chỉ khác vào ngày mai.

Nơi cả hai mô hình vỡ: tiến trình phụ, dịch vụ chia sẻ, bộ phân giải

Tiến trình phụ phá vỡ quy tắc ứng dụng theo cách trông như lỗi server. Trình cập nhật của trình duyệt, trình báo cáo sự cố, dịch vụ đồng bộ chạy dưới SYSTEM và WebView nhúng trong một gói khác đều là những danh tính riêng, nên tạo tunnel cho trình duyệt có thể để yêu cầu thật ở ngoài tunnel. Chiều ngược lại cũng khó hiểu như vậy: một ứng dụng bị loại trừ gọi thư viện chia sẻ bên trong một tiến trình đã được tạo tunnel vẫn đi qua tunnel.

Quy tắc đích đến vỡ trên các dịch vụ chia sẻ và trên tên. Chia sẻ tệp, máy in, DNS nội bộ và server giấy phép đều sống ở địa chỉ, nên một tunnel cho một ứng dụng cho trình duyệt quyền truy cập trong khi ổ đĩa được ánh xạ vẫn chết. Khác biệt về độ phủ đó không phải lỗi của mô hình nào, nhưng chính nó là lý do một tunnel cho một ứng dụng thường xuyên tạo ra tình huống VPN đang bật và chia sẻ đã biến mất.

Bộ phân giải cắt ngang cả hai. Nếu máy khách đặt server DNS nội bộ nhưng hệ điều hành dùng DNS qua HTTPS tới một bộ phân giải công cộng, câu trả lời đến từ ngoài tunnel và quy tắc đích đến có thể không bao giờ khớp. Hãy kiểm tra bộ phân giải nào thực sự trả lời trước khi kết luận quy tắc sai, và xác nhận phía máy khách xem nó đã cài bộ phân giải của tunnel hay chưa. Một split để DNS ngoài tunnel trông hoàn hảo trong bảng định tuyến và vẫn thất bại ở mọi tên nội bộ.

Quy trình: chọn, áp dụng, xác minh

Hãy bắt đầu từ yêu cầu, không phải từ menu. Nếu mục tiêu là chỉ ứng dụng này được dùng tunnel, bạn cần quy tắc ứng dụng và một nền tảng hỗ trợ chúng. Nếu mục tiêu là những mạng này tiếp cận được qua tunnel, bạn cần tiền tố. Nếu câu trả lời là cả hai, hãy triển khai chúng như hai bộ điều khiển riêng và ghi lại cái nào chịu trách nhiệm cho lỗi nào.

Hãy áp dụng hình thức hẹp nhất mà bạn có thể diễn đạt, rồi xác minh bằng cách hỏi bảng định tuyến thay vì biểu tượng trạng thái của máy khách:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

Hai dòng đầu nêu giao diện mà một đích đến thật sẽ dùng; wg show in danh sách tiền tố đã cấu hình; trên Windows, Find-NetRoute trả lời đúng câu hỏi mà ngăn xếp sẽ trả lời khi gói tin được gửi. Nếu giao diện là tunnel, quy tắc đã khớp.

Sau đó thử một gói thứ hai đáng lẽ phải bị loại trừ, từ một ứng dụng khác, tới cùng đích đến. Ghi vào phiếu yêu cầu phiên bản máy khách, loại quy tắc, danh sách tiền tố hoặc gói và hai kết quả quan sát được. Chính cặp kết quả đó cho kỹ sư tiếp theo biết chính sách bị cấu hình sai hay lưu lượng chưa bao giờ thuộc về nó.