Một kill switch trên danh sách tính năng gần như không cho biết điều gì xảy ra khi đường hầm sập. Một cách triển khai đóng các tiến trình được chọn, cách khác cài bộ lọc gói ở ranh giới hệ điều hành, và cách thứ ba chỉ đơn giản cố kết nối lại. Sự khác biệt hiện ra trong những giây sau sự cố, không phải trên màn hình cài đặt. Hãy đi qua các kiểm tra này theo thứ tự và dừng ở kiểm tra đầu tiên bạn không thể trả lời một cách trung thực, vì đó là nơi phạm vi bảo vệ thực sự của bạn kết thúc.

Trước hết hãy gọi tên cơ chế thực thi

Chấm dứt tiến trình là một tính năng của vòng đời ứng dụng. Nó tìm các chương trình được chọn sau khi phát hiện sự cố đường hầm và đóng chúng. Mọi thứ không phải tiến trình chính đều sống sót: dịch vụ phụ trợ, đồng bộ nền và bất kỳ ứng dụng nào khởi động một giây sau đó, mỗi thứ có vòng đời và thời điểm riêng.

Lọc gói là một tính năng của hệ điều hành. Nó từ chối lưu lượng không đi theo đường được phép, đó là một cam kết mạnh hơn, nhưng chỉ trong phạm vi quy tắc thực sự khớp. Họ địa chỉ, giao diện, ứng dụng bị loại trừ và các ngoại lệ quyết định điều đó, không phải nhãn trong ứng dụng khách.

Việc chặn có sống lâu hơn ứng dụng khách không?

Hãy hỏi bốn câu theo thứ tự này: điều gì xảy ra khi sập, khi thoát thủ công, khi đăng xuất và khi khởi động lại. Một quy tắc do chính ứng dụng khách duy trì thường bị gỡ khi tắt máy gọn gàng và thường bị bỏ lại sau khi sập. Một quy tắc được cài vào kho của nền tảng có thể hành xử ngược lại: sống qua cả ứng dụng khách và đôi khi cả việc gỡ cài đặt.

Đóng ứng dụng khách giữa một lần tải xuống dài và xem quá trình truyền dừng lại hay tiếp tục.

Tìm những lỗ hổng quen thuộc

IPv6 là lỗ đầu tiên. Một quy tắc viết cho địa chỉ IPv4 để lưu lượng IPv6 không bị ảnh hưởng, và nhiều ứng dụng khách chỉ viết nửa v4. Lỗ thứ hai là giao diện: chia sẻ kết nối USB, bộ điều hợp Wi-Fi thứ hai và modem di động có thể không nằm trong quy tắc chỉ giới hạn ở kết nối chính. Ứng dụng bị loại trừ và các ngoại lệ mạng cục bộ là lỗ thứ ba.

Trên Windows, bạn có thể đọc các quy tắc đã cài thay vì tin vào nút gạt: Get-NetFirewallRule -DisplayName '*VPN*' và netsh wfp show filters đều cho thấy những gì tồn tại. Trên Linux, iptables -S, ip6tables -S và nft list ruleset bao quát các trường hợp phổ biến, và việc so sánh cả ba chính là điểm mấu chốt.

DNS là chỗ rò rỉ quen thuộc

Chặn TCP trong khi để UDP 53 mở cho bạn một kill switch rất thuyết phục mà vẫn trả lời mọi truy vấn tên máy chủ. Điều tương tự cũng xảy ra khi DNS được giao cho một trình phân giải trên giao diện khác, hoặc khi ứng dụng khách chỉ chặn v4 và trình phân giải truy cập được qua v6.

Khi đường hầm đã xuống, hãy phân giải một tên đã biết và xem có câu trả lời trở lại không. Nếu có, lưu lượng chưa bị chặn hoàn toàn, bất kể biểu tượng trạng thái nói gì.

Hãy thử chuyển tiếp, không phải nút gạt

Tắt VPN từ menu của chính nó là một lần tắt gọn gàng, và trường hợp gọn gàng thì mọi cách triển khai đều xử lý tốt. Chuyển tiếp quan trọng là kiểu thô bạo: giết tiến trình đường hầm, rút mạng, để máy chủ ngừng trả lời. Sau đó khởi động một yêu cầu và xem nó thất bại hay lặng lẽ dùng liên kết vật lý.

Kết quả từ một máy tính xách tay không chuyển sang điện thoại hay bộ định tuyến. API nền tảng khác nhau, giá trị mặc định khác nhau, và trên Android sự khác biệt rất rõ: chế độ always-on kèm chặn do hệ thống chứ không phải ứng dụng khách thực thi, nên nó vẫn hoạt động khi ứng dụng khách không hoạt động. Hướng dẫn VPN của Android mô tả sự tách biệt đó.

Giữ một đường quay lại

Chặn ở cấp hệ thống có chế độ thất bại ngược lại. Các bộ lọc sống lâu hơn ứng dụng khách có thể để máy hoàn toàn không có mạng sau khi gỡ cài đặt, đó là một cuộc gọi hỗ trợ không có nguyên nhân rõ ràng. Trước khi bật bất kỳ kill switch nào ghi quy tắc nền tảng, hãy ghi lại cách gỡ nó, và giữ đường sửa chữa của nhà cung cấp ở nơi bạn có thể tìm thấy.

Nếu bạn không thể trả lời các kiểm tra sập, IPv6, DNS và chuyển tiếp cho ứng dụng khách của mình, hãy coi nó là một công tắc cấp ứng dụng với những lỗ hổng đã biết và lập kế hoạch tương ứng.

Bài viết liên quan