Chỉ tường lửa Windows làm công tắc ngắt VPN: có trụ được không?

Hỏi liệu tường lửa Windows một mình có thể đóng vai công tắc ngắt khẩn cấp không và bạn sẽ nhận hai câu trả lời tự tin nhưng không tương thích. Một ý nói quy tắc theo loại giao diện làm toàn bộ việc; ý kia nói nó không chạy nếu thiếu script. Cả hai mô tả một nửa của cùng một cơ chế. Tường lửa có thể diễn đạt việc chặn, và liệu kết quả có thực sự thất bại theo kiểu đóng hay không phụ thuộc ba điều: Windows phân loại bộ điều hợp đường hầm thế nào, ngoại lệ điểm cuối có sống sót không, và phân giải tên cùng IPv6 có được bao phủ không. Sai bất kỳ điều nào thì máy sẽ rò rỉ hoặc mất toàn bộ kết nối.

Ba điều kiện, theo thứ tự này

Điều kiện đầu tiên là phân loại, và nó quyết định quy tắc bạn muốn có diễn đạt được hay không. Quy tắc tường lửa Windows có thể bị giới hạn theo loại giao diện: có dây, không dây hoặc truy cập từ xa. Chính sách chặn lưu lượng đi ra trên các loại vật lý trong khi cho phép đường hầm chỉ hoạt động nếu Windows nhận ra đường hầm là truy cập từ xa.

Điều kiện thứ hai là ngoại lệ điểm cuối. Trước khi có bất kỳ đường hầm nào, máy khách phải tới máy chủ VPN qua bộ điều hợp vật lý, nên việc chặn toàn bộ bộ điều hợp đó ngăn đúng kết nối sẽ khiến việc chặn trở nên không cần thiết. Ngoại lệ phải nêu tên máy chủ và cổng của nó, và gói tin phải đi ra qua cổng vật lý thay vì đi vào một đường hầm chưa dựng.

Thứ ba là phạm vi bao phủ. Tập quy tắc chặn IPv4 và quên IPv6, hoặc cho phép bộ phân giải cục bộ tra cứu điểm cuối và do đó cho phép mọi tra cứu khác, thất bại mở đúng trong cửa sổ mà công tắc tồn tại để che. Đó là lỗ hổng thiết kế, không phải lỗi của tường lửa. Đó cũng là lỗ hổng sống sót qua mọi lần thử trên bàn.

Phân loại là cổng đầu tiên

Xem Windows nghĩ gì về các bộ điều hợp trước khi viết dù chỉ một quy tắc. Kết nối VPN gốc của Windows thường xuất hiện như truy cập từ xa. Máy khách bên thứ ba tự tạo bộ điều hợp ảo thường xuất hiện như có dây, nghĩa là việc chặn giới hạn ở bộ điều hợp có dây cũng chặn đường hầm.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundAction

Lệnh thứ ba cho biết liệu chặn đi ra mặc định đã có hiệu lực chưa, điều này thay đổi toàn bộ hình dạng thiết kế. Nếu mặc định đã là chặn, bạn đang viết quy tắc cho phép chứ không phải ngoại lệ cho một nền tảng dễ dãi, và đó là thế đứng dễ suy luận hơn nhiều.

Nếu bộ điều hợp đường hầm của bạn báo là có dây, chỉ tường lửa không phải công cụ đúng cho thiết kế thất bại đóng, và không mức chỉnh quy tắc nào thay đổi điều đó. Đây là trường hợp mà ý kiến thứ hai trong mọi chủ đề diễn đàn đều đúng.

Ngoại lệ điểm cuối cần cả tuyến chứ không chỉ quy tắc

Giả sử phân loại hoạt động. Ngoại lệ gồm hai phần, và chúng sống trong các hệ thống con khác nhau. Quy tắc tường lửa cho phép lưu lượng; tuyến máy chủ đưa nó ra qua giao diện đúng trong khi đường hầm xuống.

New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
  -Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32

Không có tuyến, ngoại lệ chỉ giúp khi tuyến mặc định vẫn trỏ tới cổng vật lý. Khi máy khách cài tuyến mặc định của riêng nó rồi chết, các gói được phép không có nơi đi hợp lý và kết nối không thể lập lại. Thất bại đó trông như máy khách hỏng và thực ra là tuyến bị thiếu.

Giữ ngoại lệ hẹp như máy khách cho phép. Một địa chỉ và một cổng thì xem xét được; một dải bao trùm toàn bộ mạng của nhà cung cấp thì không. Quy tắc rộng hơn đó cũng cho phép mọi thứ khác lưu trữ tại cùng nhà cung cấp, thường nhiều hơn ý định của bạn.

DNS và IPv6 là nơi nó thất bại mở

Phân giải tên là rò rỉ kinh điển. Nếu điểm cuối là tên máy chủ, máy khách phải phân giải trước khi đường hầm tồn tại, nghĩa là phải cho phép bộ điều hợp vật lý tới được bộ phân giải. Cùng quyền đó thả mọi tra cứu khác ra ngoài khi đường hầm xuống, và một tra cứu là đủ để lộ điều bạn sắp truy cập.

IPv6 là thứ hai. Quy tắc viết cho IPv4 không bao phủ họ còn lại, và nhiều máy khách chỉ cài tuyến IPv4. Vì vậy máy có kết nối IPv6 gốc vẫn có thể nói chuyện với internet trong khi phía IPv4 bị chặn chắc, và công tắc báo thành công suốt thời gian.

Hàng thứ ba đáng hiểu hơn là né tránh. Tường lửa quyết định về gói tin, không phải về việc ứng dụng yêu cầu dùng giao diện nào, và một chương trình liên kết tường minh có thể khó kiểm soát. Đó là lập luận cho công tắc phía máy khách hoạt động bên dưới ứng dụng, không phải cho thêm quy tắc.

Thử bằng cách dừng máy khách, không phải rút cáp

Bài thử có ý nghĩa duy nhất là bài mô phỏng thất bại bạn đang phòng. Dừng dịch vụ, giết tiến trình hoặc vô hiệu hóa bộ điều hợp do máy khách tạo, rồi thử tới internet và một tên:

Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443

Cả ba đều phải thất bại. Nếu cái đầu thành công, việc chặn không có hiệu lực; nếu cái thứ hai thành công ở nơi cái đầu thất bại, bạn bị rò rỉ DNS; nếu cái thứ ba thành công, IPv6 chưa được bao phủ. Mỗi kết quả chỉ đúng một trong các lỗ hổng trên.

Lặp lại bài thử sau khi ngủ và thức, vì hồ sơ tường lửa có thể đổi khi Windows quyết định mạng là công cộng hay riêng tư, và quy tắc giới hạn theo hồ sơ đi theo nó. Một thiết kế trụ được trên bàn và thất bại trên tàu là thiết kế mới thử một lần.

Nếu cổng phân loại hoặc yêu cầu DNS khiến cách chỉ-tường-lửa không khả thi, công tắc phía máy khách là câu trả lời trung thực. Nếu đường hầm kết thúc ở bộ định tuyến, chính sách nên thuộc về bộ định tuyến, vì một quy tắc ở đó bao phủ mọi thiết bị phía sau và không phụ thuộc cách Windows đặt tên bộ điều hợp.