Công tắc an toàn vẫn chặn lưu lượng sau khi VPN ngắt kết nối

Đường hầm đã biến mất, biểu tượng mạng trông bình thường và không có gì tải được. Bạn đã ngắt VPN, gỡ cài đặt hoặc khởi động lại, và khối chặn lẽ ra phải bảo vệ bạn khi kết nối rớt vẫn đứng đó. Cửa sổ ứng dụng khách không giải thích được, vì thứ chặn bạn không phải ứng dụng khách: quyết định đã được ghi vào kernel dưới tên bạn, và không còn gì để gỡ nó. Trên Windows trạng thái đó nằm trong Windows Filtering Platform; trên Linux đó là một tập quy tắc trong iptables hoặc nftables, thường kèm ảnh chụp được phát lại khi khởi động. Dưới đây là thứ tự tôi dùng: đọc trạng thái, xóa đối tượng hẹp nhất giải thích sự cố, rồi tìm bất cứ thứ gì cứ đặt nó trở lại.

Công tắc an toàn là trạng thái kernel, không phải cài đặt

Ứng dụng khách trên máy tính thực hiện chặn bằng cách thêm bộ lọc từ chối lưu lượng ngoài đường hầm. Trên Windows đó là bộ lọc WFP ở lớp connect-redirect và transport, và một số là cố định: chúng được ghi vào kho chính sách của Base Filtering Engine và được phục hồi khi máy khởi động, trước khi bất kỳ phần mềm VPN nào chạy. Các ứng dụng khách khác nhau ở thời điểm dọn dẹp. Một số gỡ bộ lọc khi ngắt kết nối, một số chỉ khi thoát sạch, một số chỉ khi tắt công tắc trước. Gỡ cài đặt khi khối chặn đang hoạt động, hoặc giết tiến trình, và bộ lọc vẫn ở lại.

Tương đương trên Linux là quy tắc drop hoặc reject trên đường ra, đôi khi là quy tắc forwarding, đôi khi là chính sách chuỗi bị thay đổi. Những quy tắc đó sống lâu hơn tiến trình đã thêm chúng vì chúng là trạng thái kernel: giết ứng dụng khách, làm nó sụp hoặc cắt điện, kernel vẫn tiếp tục bỏ gói và không còn gì để hoàn tác. Gói lưu trạng thái thêm một lớp cố định thứ hai bằng cách chụp ảnh bộ quy tắc hiện tại và phục hồi khi khởi động, nên lần khởi động sau bắt đầu với khối chặn đã cài sẵn.

Đọc trạng thái WFP trước khi xóa bất cứ thứ gì

Windows có sẵn công cụ bạn cần. Mở dấu nhắc quản trị và kết xuất trạng thái nền tảng; bản kết xuất xuất hiện dưới dạng wfpstate.xml trong thư mục làm việc.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

Tìm trong XML tên nhà cung cấp đã rời đi, hành động Block và lớp. Bộ lọc ở connect-redirect và transport là những thứ phá lưu lượng bình thường; bộ lọc ở lớp receive-accept thường không phải nguyên nhân của bạn. Nếu Base Filtering Engine hoàn toàn không chạy, hãy tìm chỗ khác, vì không gì khác thi hành được những bộ lọc đó.

Cũng kiểm tra chế độ xem tường lửa thông thường, vì hầu hết mọi người chỉ xem một trong hai:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Khi các hồ sơ tích hợp đang bật và không quy tắc nào khớp với lưu lượng lỗi, khối chặn đến từ nhà cung cấp bên thứ ba chứ không phải Windows Firewall. Sự khác biệt đó quyết định công cụ bạn dùng để sửa.

Đọc quy tắc Linux bằng đúng cú pháp bạn sẽ xóa

iptables -S in quy tắc theo đúng dạng đã dùng khi thêm, nên kết quả có thể dùng lại trực tiếp để xóa. iptables -L -v -n thêm bộ đếm gói, và bộ đếm đó cho biết quy tắc có thực sự khớp với các yêu cầu thất bại của bạn hay chỉ ngồi trong chuỗi.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

Đọc chính sách chuỗi, không chỉ quy tắc: -P OUTPUT DROP chặn lưu lượng ngay cả khi không quy tắc nào khớp. Kiểm tra IPv6 riêng, vì ứng dụng khách cài cả hai họ có thể để khối chặn IPv6 lại sau khi quy tắc IPv4 biến mất, và triệu chứng khi đó phụ thuộc vào họ mà ứng dụng ưu tiên. Nơi dùng nftables, chạy cả nft list ruleset; hai công cụ cùng tồn tại qua lớp tương thích, và một danh sách không nhất thiết hiển thị mọi quy tắc có thể bỏ gói.

Xóa đối tượng hẹp nhất giải thích sự cố

Trên Windows bước đầu vẫn là đường gỡ của chính nhà cung cấp: chạy lại trình cài đặt và dùng repair hoặc uninstall, hoặc chạy công cụ dọn dẹp nếu nhà cung cấp phát hành. Dịch vụ và tác vụ đã lên lịch còn sót là chuyện thường, và tác vụ khởi chạy ứng dụng khách khi đăng nhập sẽ cài lại bộ lọc ở lần khởi động sau. Một lần gỡ thất bại khi đọc khóa đăng ký của ứng dụng khách thường có nghĩa là một dịch vụ hoặc tác vụ vẫn giữ nó, không phải đăng ký bị hỏng.

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

Bộ lọc cố định là phương án cuối. Chúng nằm dưới HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, một giá trị cho mỗi bộ lọc với khóa GUID. Xuất khóa trước, ghi lại các GUID bạn xóa, chỉ xóa những giá trị thuộc về ứng dụng khách đã rời đi, rồi khởi động lại để engine dựng lại trạng thái. Đừng xóa cả khóa và đừng tắt Base Filtering Engine: Windows Firewall và Defender phụ thuộc vào nó, và bạn sẽ đổi một sự cố lấy một sự cố tệ hơn.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

Trên Linux, lấy dòng mà iptables -S in ra và thay -A bằng -D. Xóa một quy tắc bạn đã xác định tốt hơn làm rỗng cả chuỗi, vì chính sách của bạn vẫn nguyên vẹn.

sudo iptables -D OUTPUT -p udp -j REJECT

Nếu drop nằm trong chuỗi do người dùng định nghĩa, trước hết xóa bước nhảy tới chuỗi đó rồi gỡ chuỗi bằng -X. Đặt chính sách chuỗi thành ACCEPT khi quy tắc drop vẫn còn chỉ giúp các gói thực sự tới được quyết định chính sách. Làm rỗng mọi bảng là phương án cuối: nó cũng gỡ các quy tắc bạn thêm vì lý do khác, và khi bật ufw nó khiến dịch vụ tin rằng mình sở hữu những chuỗi không còn tồn tại.

Tìm chủ sở hữu đặt nó trở lại

Sau khi sửa ngay, hãy tìm thứ sẽ phục hồi trạng thái. Trên Linux, kiểm tra xem một unit lưu trạng thái có được bật không, ứng dụng khách có cài đặt phục hồi tường lửa khi đăng nhập không và có tệp quy tắc đã lưu dưới /etc không. Trên Windows, kiểm tra lại mục khởi động, dịch vụ và tác vụ đã lên lịch, rồi khởi động lại và đọc trạng thái bằng đúng các lệnh như trước.

Nếu khối chặn quay lại, việc xóa không phải là cách sửa; chủ sở hữu mới là. Ghi lại ứng dụng khách hoặc dịch vụ nào cài nó và tắt tính năng ở đó, thay vì đấu với nó ở lớp tường lửa sau mỗi lần ngắt kết nối.

Kiểm chứng bằng lưu lượng thật, không phải một lần ping

Thử phân giải tên, kết nối TCP và một phiên trình duyệt mới, rồi khởi động lại và lặp lại đúng ba kiểm tra đó. Ping chạy được trong khi HTTPS lỗi chỉ ra bộ lọc ở lớp transport chứ không phải mạng, và khối chặn chỉ xuất hiện lại sau khi khởi động lại chỉ ra chủ sở hữu bạn chưa tìm ra.

Giữ bằng chứng: khóa BFE đã xuất, hoặc kết quả iptables -S chụp trước khi thay đổi. Trước khi nói đã sửa, hãy xác nhận lớp bạn đã gỡ đối tượng, chủ sở hữu có thể cài lại nó, trạng thái sau một lần khởi động sạch, và việc duyệt web bình thường hoạt động khi không có tiến trình VPN. Trang hướng dẫn iptables(8) có cú pháp xóa và chính sách chính xác nếu bạn viết kịch bản dọn dẹp.