Ứng dụng VPN bị treo: công tắc an toàn còn bật không?

Hãy bắt đầu từ nơi người dùng bắt đầu: cửa sổ ứng dụng khách biến mất, biểu tượng trên khay hệ thống không còn, và trình duyệt hoặc tải được hoặc không. Chỉ riêng quan sát đó không cho biết khối chặn còn sống hay không. Câu trả lời phụ thuộc vào thành phần nào giữ các quy tắc, thành phần đó có chết cùng cửa sổ không, và nền tảng có giữ việc thực thi bên ngoài ứng dụng không. Đi từ cửa sổ tới tiến trình, rồi tới tường lửa, rồi tới đường đi thực tế.

Đừng khởi động lại trước; khởi động lại thường phá hủy bằng chứng.

Bắt đầu từ thứ vẫn đang chạy

Mở danh sách tiến trình trước khi chạm vào bất cứ thứ gì. Ứng dụng khách trên máy tính thường tách thành một tiến trình giao diện người dùng và một dịch vụ hoặc daemon, và việc tiến trình đầu bị treo không nhất thiết dừng tiến trình sau. Trên Windows dịch vụ có thể vẫn còn trong danh sách, trên Linux unit có thể vẫn hoạt động, và trên Android đường hầm thuộc về hệ thống sau khi đã đồng ý. Hãy đọc ba sự thật đó theo đúng thứ tự.

Nếu daemon còn sống thì đường hầm nhiều khả năng cũng còn sống, và cửa sổ mất đi chỉ là chuyện hình thức.

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

Đọc khối chặn ở bên thực thi, không phải ở ứng dụng

Nếu ứng dụng khách thực thi công tắc an toàn bằng cách chèn các quy tắc tường lửa, thì những quy tắc đó thuộc về hệ điều hành và tồn tại sau khi tiến trình tạo ra chúng kết thúc. Khi đó một lần treo để bạn bị chặn mà không có giao diện nào để tắt, trông giống mạng hỏng hơn là bảo vệ. Nếu ngược lại khối chặn nằm trong chính đường đi gói tin của ứng dụng khách, việc giết tiến trình sẽ gỡ khối chặn ngay lập tức.

Android xử lý việc này lại theo cách khác: always-on VPN kèm lockdown là một thiết lập của nền tảng, nên khối chặn vẫn tồn tại độc lập với tiến trình ứng dụng, và hệ thống có thể khởi động lại dịch vụ. Hãy tra tài liệu nền tảng để biết hành vi chính xác thay vì giả định nó giống ứng dụng khách trên máy tính.

Phân biệt thoát sạch với treo

Một Quit bình thường thường chạy đường tắt của ứng dụng khách, vốn cố ý gỡ các quy tắc và đóng đường hầm. Một lần treo bỏ qua đường đó và để lại mọi thứ bên thực thi đã cài. Khác biệt hiện ra ở dấu thời gian của các quy tắc so với lúc tiến trình thoát, và ở việc còn tồn tại giao diện đường hầm cũ không có chủ hay không.

Khác biệt đó quyết định cách khôi phục: thoát sạch có thể cần kết nối mới, còn treo có thể cần gỡ các quy tắc còn lại qua hành động sửa chữa được ứng dụng khách hỗ trợ.

Khôi phục mà không phá các kiểm soát khác

Khởi động lại ứng dụng khách theo quy trình đã ghi trong tài liệu, rồi kiểm tra cả hai nửa của yêu cầu: đường hầm chở lưu lượng, và khối chặn vẫn áp dụng khi cần. Xả toàn bộ tường lửa để lấy lại kết nối cũng gỡ luôn các kiểm soát không liên quan, và đánh đổi đó hiếm khi đáng.

Với một lần treo lặp lại, hãy thu thập phiên bản ứng dụng khách, bản dựng nền tảng và các bản ghi giới hạn mà nhà cung cấp yêu cầu. Hồ sơ ứng dụng khách, khóa riêng hoặc nhật ký kết nối đầy đủ của tài khoản khác không cần cho báo cáo treo, và việc đưa chúng vào biến một ca hỗ trợ thành vấn đề xử lý dữ liệu.

Một lần treo không phải bằng chứng rò rỉ. Bằng chứng là một gói tin được quan sát thấy đi ra qua đường mà chính sách đáng lẽ phải ngăn, bắt được đúng lúc ứng dụng khách đang tắt. Hãy thử điều đó một cách có chủ đích, với đích đến vô hại, và ghi lại tầng thực thi nào đã trụ vững.