Công tắc an toàn VPN có sống sót sau khi khởi động lại? Cách kiểm chứng

Khởi động lại là cách phổ biến nhất mà mọi người dùng để thử công tắc an toàn, và đó cũng là bài kiểm tra nói dối thường xuyên nhất. Ô đánh dấu trong ứng dụng khách chỉ là một tùy chọn; điều quan trọng là liệu có thứ gì đó thực thi việc chặn giữa thời điểm ngăn xếp mạng khởi động và thời điểm đường hầm thực sự được thiết lập. Trên Windows, thứ đó thường là một bộ lọc trong Windows Filtering Platform, trên Linux là một tập quy tắc do một unit tải, trên macOS là một neo pf, trên Android là các cờ luôn bật và khóa của chính hệ thống. Những cách bố trí này hành xử rất khác nhau qua một lần khởi động lại, và chỉ những cái ở cấp nền tảng mới có mặt trước khi bất kỳ ai có thể đăng nhập.

Một lần khởi động lại đặt ra ba câu hỏi riêng biệt

Hãy tách câu hỏi ra. Thứ nhất, chính sách có tồn tại trên đĩa ở dạng mà thứ gì đó đọc lúc khởi động không? Thứ hai, trình đọc đó có chạy trước khi bất kỳ lưu lượng nào có thể ra ngoài không? Thứ ba, chính sách có bao phủ lưu lượng mà bạn quan tâm không, nghĩa là mọi tiến trình, cả hai họ địa chỉ và DNS. Một câu có cho câu thứ nhất và không cho câu thứ hai tạo ra đúng thất bại mà mọi người báo cáo là công tắc an toàn không sống sót sau khởi động lại: lưu lượng lọt ra ngoài vài giây lúc khởi động, và không ai nhận ra cho đến khi có người đi kiểm tra.

Hãy giữ các lớp tách biệt. Một tập quy tắc tường lửa đã lưu, một dịch vụ khởi động cùng hệ thống và một tùy chọn của ứng dụng khách là ba đối tượng khác nhau với ba vòng đời khác nhau. Tùy chọn tồn tại qua các lần khởi động lại vì nó là một giá trị trong tệp cấu hình. Các quy tắc là thứ duy nhất chặn gói, và chúng biến mất cùng với nhân đã giữ chúng.

Tìm đối tượng khôi phục việc chặn

Trên Linux, các quy tắc netfilter sống trong nhân. Không có gì ghi chúng trở lại lúc khởi động trừ khi bạn đã sắp đặt: iptables-save cộng với netfilter-persistent, nftables.service tải /etc/nftables.conf, hoặc một unit systemd chạy script của riêng bạn. Hãy kiểm tra cái gì đang được bật, thay vì cái bạn nhớ là đã cấu hình.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Một tập quy tắc trống vài giây sau khi khởi động chính là câu trả lời cho câu hỏi trong tiêu đề. Trên Windows, hãy hỏi dịch vụ của ứng dụng khách cách nó khởi động, rồi kết xuất trạng thái bộ lọc nền tảng khi đường hầm đang xuống.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

Lệnh thứ hai ghi wfpstate.xml vào thư mục hiện tại. Hãy tìm các bộ lọc có hành động chặn đã tồn tại trước khi ứng dụng khách kết nối. Base Filtering Engine khởi động sớm và khôi phục các bộ lọc được thêm bằng cờ thường trú, đó là lý do một số công tắc an toàn chặn lưu lượng trước khi có bất kỳ cửa sổ ứng dụng khách nào và một số khác thì không. Trên macOS, sudo pfctl -s info báo cáo liệu pf có được bật, sudo pfctl -s rules hiển thị cái gì đã tải, và các ứng dụng khách VPN thường gắn quy tắc của chúng vào một neo thay vì tập chính. Một quy tắc nêu tên utun3 có thể trỏ tới một giao diện khác sau lần khởi động tiếp theo, vì con số đó được cấp lúc chạy.

Theo dõi khoảng trống giữa lúc mạng lên và lúc đường hầm lên

Khoảng nguy hiểm không phải toàn bộ lần khởi động lại, mà là khoảng trống. Giao diện nhận một hợp đồng thuê và một tuyến mặc định ở một thời điểm, dịch vụ VPN khởi động ở thời điểm khác, và đường hầm xác thực còn muộn hơn, đôi khi chỉ sau khi người dùng đăng nhập và một tác nhân thông tin xác thực chạy. Nếu việc chặn được áp dụng cuối cùng, mọi thứ trong khoảng trống đều ra ngoài không được bảo vệ.

Trên các máy chủ systemd, hãy đọc thứ tự thay vì đoán nó. Chạy systemctl cat trên các unit VPN và tường lửa và tìm After= hoặc Before= so với network-pre.target và network-online.target. Một unit tường lửa được sắp sau network-online.target thua giao diện; cái được yêu cầu bởi và sắp trước network-pre.target sẽ thắng. Trên Windows, các câu hỏi tương đương là kiểu khởi động của dịch vụ và các phụ thuộc của nó, vì một dịch vụ đặt ở Manual không thể chặn một tiến trình lúc khởi động. Nếu yêu cầu của bạn bao gồm lưu lượng trước khi đăng nhập, chỉ một cách bố trí ở cấp thiết bị mới đáp ứng được: một đường hầm thiết bị Always On VPN xác thực bằng chứng chỉ máy và kết nối trước khi người dùng đăng nhập, và Microsoft ghi lại cấu hình đường hầm thiết bị tách biệt với đường hầm người dùng. Android đi con đường khác, buộc VPN luôn bật và chặn các kết nối không có nó từ hệ thống chứ không phải từ tiến trình ứng dụng.

Chạy bài kiểm tra, rồi so sánh hai dòng thời gian

Khởi động lại với một đích không tốn gì nếu bị rò rỉ, và ghi lại trạng thái trong khoảng trống thay vì sau đó. Cách sạch nhất là một đầu dò lúc khởi động: một unit oneshot hoặc một tác vụ được lên lịch khởi động sớm nhất mà nền tảng cho phép, ghi lại tuyến mặc định và trạng thái tường lửa, thử một yêu cầu với thời gian chờ ngắn và thêm một dòng vào tệp cục bộ. Hãy so sánh bản ghi đó với thời điểm dịch vụ VPN khởi động từ journalctl -b -u hoặc nhật ký hệ thống.

Sau đó chạy bài kiểm tra thông thường: đường hầm lên, ngắt kết nối, xem lưu lượng trực tiếp có bị chặn không, khôi phục. Vượt qua cái thứ hai và thất bại ở cái thứ nhất là kết quả bình thường, và điều đó có nghĩa là việc thực thi nằm ở phía ứng dụng khách, được áp dụng khi ứng dụng khách kết nối chứ không phải lúc khởi động. Trên chiếc máy cuối cùng tôi kiểm toán, việc chặn đến từ một script điều phối của NetworkManager: có mặt và đúng và vô dụng cho những giây trước khi giao diện lên. Hãy ghi lại cả hai kết quả, vì việc sống sót qua khởi động lại chỉ có ý nghĩa khi bạn nói được lớp nào đã sống sót và từ thời điểm nào.

Bịt khoảng trống mà không cắt đường quay về của bạn

Nếu thiếu việc chặn lúc khởi động, hãy hạ việc thực thi xuống một lớp thay vì thêm một quy tắc ứng dụng khách thứ hai. Lưu tập quy tắc và tải nó từ một unit được sắp trước khi mạng dùng được, và bảo đảm unit đó không cần một truy vấn DNS hay một lần gắn kết mạng mà nó lẽ ra phải bảo vệ. Phạm vi quan trọng ngang với thời điểm: các quy tắc khớp theo ID người dùng hoặc cgroup để mọi daemon hệ thống ở ngoài việc chặn, và một tập quy tắc chỉ xử lý IPv4 để IPv6 và DNS vẫn truy cập được.

Hãy để lại cho mình một đường quay về. Một chiếc máy chặn mọi thứ lúc khởi động rồi không xác thực được thì không có mạng nào cả, và cách sửa không phải là xóa việc chặn mà là sửa thông tin xác thực hoặc thứ tự. Hãy duy trì một quy trình có tài liệu cho bảng điều khiển cục bộ và một ngoại lệ hẹp, có chủ đích cho những gì đường hầm thực sự cần, như địa chỉ máy chủ và trình phân giải được dùng trước khi đường hầm tồn tại.

Trước khi tin vào cách bố trí này, hãy xác nhận bốn điều theo thứ tự. Chính sách được lưu ở nơi mà quá trình khởi động đọc. Trình đọc đó chạy trước khi giao diện dùng được. Việc chặn bao phủ cả hai họ địa chỉ và DNS. VPN vẫn xác thực được trong khi việc chặn đang hoạt động. Khi cả bốn điều đúng, một lần khởi động lại không thay đổi gì.