Ứng dụng không được chạy khi VPN đang bật: điều gì thực thi nó

Kill switch và các quy tắc cấm chồng lấn chỉ về hai hướng ngược nhau, điều đó giải thích vì sao cài đặt VPN thông thường không bao giờ diễn đạt cái thứ hai. Kill switch phản ứng với một đường hầm đã sập, trong khi yêu cầu này phản ứng với một đường hầm đang bật và giữ ứng dụng ra ngoài bức tranh. Một quyết định thiết kế giải quyết phần lớn: ứng dụng bị dừng, bị chặn khởi động hay chỉ bị tước quyền truy cập mạng. Hãy chọn lớp đó trước khi với tới một quy tắc tường lửa hay vòng lặp giết tiến trình, vì một quy tắc được thực thi bằng quan sát sẽ rò rỉ một cửa sổ ở mỗi lần khởi chạy.

Huyền thoại: kill switch ngăn chương trình khởi động

Kill switch là kiểm soát lưu lượng, và chúng trung thực về điều đó: chúng cho phép hoặc từ chối gói tin theo trạng thái đường hầm. Không cái nào từ chối khởi động một chương trình, và không cái nào kiểm tra tệp thực thi nào đã mở socket. Một lối tắt trên màn hình, một tác vụ đã lên lịch và một trình trợ giúp nền đều đến được mạng mà không đi qua thứ gì biết tên ứng dụng. Khoảng cách giữa hai cơ chế đó là nơi phần lớn sự nhầm lẫn trú ngụ.

Cách sắp đặt thực sự quyết định một chương trình có được khởi động hay không là kiểm soát ứng dụng. Trên Windows, điều đó có nghĩa là AppLocker hoặc WDAC, và trên macOS được quản lý, nó có nghĩa là danh sách cho phép do hồ sơ thiết bị thực thi. Cả hai đều độc lập với đường hầm, vì vậy hai yêu cầu được gộp vào cùng một phiếu rồi sau đó không cái nào được đáp ứng.

Đặt tên chế độ trước khi đặt tên công cụ

Hãy viết quy tắc như một máy trạng thái với ba trạng thái: sử dụng thông thường, phiên làm việc VPN và rời đi. Việc chồng lấn bị cấm thuộc về trạng thái giữa, không thuộc về phần mềm khách.

Ai thay đổi trạng thái thì sở hữu ba hành động theo thứ tự: hoàn tất công việc của ứng dụng, yêu cầu tắt bình thường và xác nhận phiên bản đã biến mất trước khi đường hầm dựng lên. Thứ tự cũng quan trọng ở đầu bên kia, vì một VPN kết nối trước rồi dừng chương trình sau đã cho phép chồng lấn. Nếu yêu cầu bao gồm việc thiết lập kết nối, chờ chỉ báo đã kết nối là quá muộn.

Xung đột hai chiều thực sự làm gì

Với hai dịch vụ thực sự do systemd quản lý, Conflicts= là đối xứng: khởi động cái này sẽ dừng cái kia. Tài liệu tham chiếu unit ghi lại hành vi đó và riêng biệt yêu cầu một thứ tự rõ ràng khi cái này phải kết thúc việc dừng trước khi cái kia bắt đầu. Không có các mục thứ tự đó, việc dừng và khởi động sẽ đua nhau, và kết quả phụ thuộc vào thời điểm.

Đây không phải là danh sách cấm. Nối phụ thuộc ngược lại và việc khởi động ứng dụng sẽ dừng VPN thay vào đó, đó là lỗi cần nghi ngờ khi một đường hầm tự ngắt kết nối vào một thời điểm có thể đoán trước. Ứng dụng máy tính để bàn không phải là unit systemd, và kết nối NetworkManager cũng không phải là unit, nên mẫu này chỉ hoạt động với các dịch vụ do bạn tự bọc.

Kiểm tra các chuyển đổi, không chỉ lần khởi chạy đầu tiên

Bốn chuyển đổi quyết định yêu cầu có giữ được hay không: vào phiên khi ứng dụng đang chạy, khởi chạy lại nó giữa phiên, khởi động VPN thất bại và ngắt kết nối có chủ đích. Hãy kiểm tra từng cái và giữ kết quả bên cạnh các tệp unit. Các lệnh bên dưới đọc mối quan hệ hiện tại rồi thực hành chuyển đổi quan trọng nhất.

systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active

Lệnh thứ ba phải để ứng dụng không hoạt động, và lệnh thứ tư chỉ được liệt kê kết nối đường hầm trong khi một phiên đang chạy. Một kết quả khác nghĩa là chuyển đổi hoàn toàn không được thực thi.

Việc khởi chạy lại trong phiên là trường hợp phơi bày một thiết kế dựa trên lớp bọc, vì một lối tắt khởi chạy từ màn hình không bao giờ tham khảo một script khởi chạy. Nếu việc vượt qua đó quan trọng, việc thực thi thuộc về kiểm soát ứng dụng chứ không phải ứng dụng khách VPN. Hãy ghi lại cả phần cuối của phiên, và ưu tiên tiếp tục có chủ đích hơn là mở lại mọi tiến trình đã bị dừng khi vào. Ghi kết quả của từng chuyển đổi vào cùng ghi chú lưu các tệp unit.