Hai ứng dụng VPN cùng lúc: kill switch nào thực sự áp dụng?

Hai client VPN có thể chạy song song, nhưng kill switch của chúng không hợp nhất thành một chính sách duy nhất. Mỗi client cài đặt các quy tắc cho đường hầm của riêng nó, và không bên nào biết bên kia tồn tại. Tôi đã gặp chuyện này với một client công việc được kết nối trước: ứng dụng thứ hai không thể hoàn tất bắt tay, nằm ở „Connecting“ suốt mười phút, và đường hầm đầu tiên lặng lẽ mang theo mọi thứ. Việc ứng dụng thứ hai có được bảo vệ hay không phụ thuộc vào ba điều kiện, không phải vào việc cả hai biểu tượng có ghi Đã kết nối hay không.

Kill switch thực sự giới hạn trong phạm vi nào

Không có một cờ kill switch duy nhất nào trong hệ điều hành. Một client quảng cáo tính năng đó sẽ cài một bộ quy tắc: bỏ mọi thứ không đi ra qua đường hầm của tôi, và thường fail closed khi đường hầm biến mất. Trên Linux thường là chuỗi nftables hoặc iptables, trên Windows là một tập bộ lọc Windows Filtering Platform, trên Android và iOS là định tuyến riêng của dịch vụ đường hầm cộng với thiết lập hệ thống chặn các kết nối không có VPN. Hướng dẫn VPN cho Android mô tả mô hình dịch vụ đó nếu bạn muốn góc nhìn của nền tảng.

Phạm vi là phần quan trọng. Một quy tắc kiểu „chỉ cho phép gói tin trên giao diện ra wg0“ không quan tâm liệu có đường hầm thứ hai hay không. Nếu client khác dựng wg1, các quy tắc của client đầu tiên coi những gói đó là lưu lượng bình thường: thường bị bỏ, đôi khi được cho qua. Dù thế nào thì client đầu tiên quyết định, và nó không hề biết rằng ứng dụng thứ hai đang chờ.

Ba điều kiện quyết định ai được bảo vệ

Bạn không cần liệt kê mọi tổ hợp. Ba câu hỏi giải quyết trong vài phút.

1. Nền tảng có cho phép đường hầm thứ hai không? Hầu hết điện thoại Android và iPhone chỉ nhận một dịch vụ VPN đang hoạt động cho mỗi hồ sơ người dùng, nên ứng dụng thứ hai không bao giờ có đường hầm và không bao giờ thực thi gì. Bạn có một chính sách duy nhất, từ ứng dụng thắng chỗ đó.
2. Tiến trình nào sở hữu tuyến mặc định? Windows, macOS và Linux mang hai đường hầm một cách thoải mái. Tuyến mặc định thuộc về client đã cấu hình nó sau cùng hoặc có metric tốt hơn, còn client kia vẫn kết nối nhưng không làm gì. Trên Linux, chế độ tuyến mặc định của wg-quick dùng định tuyến theo chính sách với bảng riêng và quy tắc fwmark, nên đường hầm wg-quick thứ hai thêm một quy tắc cạnh tranh thay vì thay thế cái đầu.
3. Client thứ hai có tới được máy chủ của chính nó không? Nếu kill switch đầu tiên là từ chối mặc định, điểm cuối bên ngoài của ứng dụng thứ hai chỉ là một đích bị bỏ nữa. Nó thử lại lặng lẽ và không bao giờ báo lỗi.

Phiên bản ngắn, cho các luồng hỗ trợ:

Hai trong số các dòng đó trông giống hệt nhau từ biểu tượng trên khay hệ thống, đó là lý do biểu tượng là bằng chứng tệ nhất có ở đây.

Cái gì hỏng trước, và nó trông thế nào

Một client bị kẹt ở „Connecting“ trong khi bên kia khỏe mạnh gần như luôn là đói điểm cuối: kill switch đang chạy bỏ bắt tay của client thứ hai tới máy chủ của chính nó. Xác nhận điều đó một cách rẻ bằng cách tạm dừng các quy tắc chặn của client đầu tiên trong một lần thử. Nếu client thứ hai kết nối ngay, câu hỏi đã có đáp án.

DNS là lỗi thứ hai. Các client đặt cấu hình trình phân giải cho giao diện của riêng mình, và một số ghi đè thẳng danh sách toàn cục. Khi cả hai đường hầm cùng hoạt động, truy vấn có thể đi ra qua một bên trong khi trình phân giải thuộc về bên kia. Ngắt kết nối một trong hai ứng dụng và bên sống sót giữ một máy chủ tên không thể tới được: các trang đứng hình một phút rồi phân giải lại, trong khi VPN vẫn hiển thị đã kết nối.

Cái thứ ba là tuyến nhảy. Các lần kết nối lại sắp xếp lại tuyến mặc định, và kill switch gắn với giao diện không đi theo nó. Lưu lượng vừa nằm trong đường hầm giờ khớp với một quy tắc bỏ, điều mà phía người dùng đọc là VPN đột nhiên ngừng hoạt động.

Xác minh chính sách nào thực sự có hiệu lực

Hãy làm điều này với lưu lượng vô hại, không phải với thứ bạn sẽ tiếc.

Trên Linux, hỏi kernel ai thắng và tường lửa gắn vào đâu. ip -4 route show default nêu tên đường hầm sở hữu lối ra. ip rule show cho thấy định tuyến theo chính sách có tham gia hay không. sudo nft list ruleset | grep -n oifname cho thấy các lần bỏ gói gắn với tên giao diện, một dấu, hay toàn bộ chuỗi ra.

Trên Windows cùng câu chuyện nằm ở metric tuyến và danh sách bộ lọc: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric và Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". Trên macOS, netstat -rn -f inet | head -5 và scutil --dns | head -20.

Sau đó làm bước mà mọi người bỏ qua: cố ý dừng đường hầm và xác nhận rằng lưu lượng bạn mong sẽ hỏng thực sự hỏng. Biểu tượng đã kết nối là trạng thái giao diện, không phải sự thực thi.

Khi hai client là thiết kế sai

Nếu yêu cầu duy nhất đằng sau ứng dụng thứ hai là bảo vệ nhiều hơn, hãy bỏ nó đi. Hai chính sách chặn tương tác với nhau khó đoán hơn một, và mỗi lần kết nối lại là cơ hội rơi vào trạng thái mà không nhà cung cấp nào kiểm thử.

Nếu bạn thực sự cần nối chuỗi, ví dụ một cổng công ty đạt được qua một chặng thương mại, hãy chọn thiết kế có một điểm thực thi duy nhất. Điều đó thường có nghĩa là một router hoặc một client duy nhất hỗ trợ chuỗi, không phải hai ứng dụng máy tính để bàn tranh nhau cùng một tuyến mặc định. Trên thiết bị được quản lý, hãy giữ client được phép và coi mọi thứ khác là ngoài phạm vi, bất kể nó hiển thị gì trên khay.

Danh sách kiểm tra trước khi giữ cả hai

Đi theo danh sách này theo thứ tự; mục đầu tiên hỏng là mục cần sửa.

• Xác nhận rằng đúng một client sở hữu tuyến mặc định và trình phân giải.
• Nếu muốn client thứ hai hoạt động, hãy cho phép rõ ràng điểm cuối máy chủ của nó và kiểm tra lại sau mỗi lần cập nhật client.
• Ghi lại kết quả mong đợi khi một trong hai đường hầm rơi, rồi thử đúng trường hợp đó.
• Kiểm tra đường hỏng sau khi khởi động lại, khi thứ tự khởi động khác đi.
• Trên hồ sơ được quản lý, hãy dừng lại và hỏi chủ sở hữu trước khi thêm bất cứ thứ gì.

Nếu bước thứ ba hỏng, câu trả lời trung thực là chỉ một client đang cho bạn một chính sách. Hãy quyết định tin cái nào và để cái kia ra đi.