Hồ sơ tường lửa và lối ra VPN: vì sao công cộng không phải là đường đi
Hồ sơ tường lửa chọn bộ quy tắc nào được áp dụng. Nó không nói gì về việc giao diện nào đã chở gói tin, và một lệnh chặn rõ ràng thắng một quyền cho phép hẹp hơn.
Quy tắc nghe có vẻ chính xác: cho phép lưu lượng cục bộ trên hồ sơ riêng tư và chỉ lưu lượng VPN trên hồ sơ công cộng. Không phải vậy, vì hồ sơ mạng chọn bộ quy tắc tường lửa nào được áp dụng và không nói gì về việc bộ điều hợp nào đã chở gói tin. Coi tên hồ sơ là yêu cầu về đường đi chính là sai lầm khiến một thiết kế lối ra hạn chế trông như đã xong trong khi chưa xong.
Trước tiên hãy ghi lại các luồng, rồi quyết định cơ chế nào thực sự có thể thực thi từng luồng. Danh sách luồng đó là thứ duy nhất còn lại sau lần thay đổi quy tắc tiếp theo.
Danh mục chọn quy tắc, không chọn tuyến
Khi Windows phân loại một mạng là công cộng hay riêng tư, tường lửa áp dụng bộ quy tắc được cấu hình cho hồ sơ đó. Việc phân loại đi theo mạng mà bộ điều hợp đã tham gia, và bộ quy tắc quyết định điều gì được phép trên đó. Không một sự thật nào trong số đó phụ thuộc vào việc lưu lượng của ứng dụng có dùng đường hầm hay không. Chính sự độc lập đó là toàn bộ khó khăn.
Việc chọn đường do định tuyến thực hiện, thông qua số đo giao diện và tiền tố mà đường hầm cài đặt. Vì vậy một hồ sơ có thể được gắn nhãn công cộng trong khi kết nối của ứng dụng đi theo đường vật lý, và tường lửa vẫn báo rằng bộ quy tắc công cộng đã được áp dụng.
Vì thế một quy tắc giới hạn trong hồ sơ không thể chỉ có nghĩa là đường hầm. Hai thuộc tính đó do các thành phần khác nhau quyết định và cái này không thể thay thế cái kia.
| Flow | What decides it | What a rule can enforce |
|---|---|---|
| VPN client to its endpoint | Routing plus the outer transport | Allow the client process before the tunnel exists |
| Application to an internet host | Interface metric and prefix length | Block the process unless the tunnel interface is up |
| Application to a LAN host | Local subnet route | Allow one destination, not the whole category |
Một lệnh chặn rõ ràng đứng trên một quyền cho phép hẹp hơn
Hướng dẫn của Microsoft về quy tắc tường lửa phân biệt một quyền cho phép như ngoại lệ của hành động chặn mặc định với một lệnh chặn rõ ràng xung đột với quyền cho phép. Các lệnh chặn rõ ràng thắng xung đột đó, và các quy tắc ra ngoài cũng tuân theo cùng thứ tự ưu tiên.
Vì vậy công thức phổ biến là thêm một quy tắc chặn mọi thứ rồi dựa vào một quyền cho phép hẹp hơn đặt bên trên không làm điều mà tác giả của nó mong đợi. Tường lửa Windows không giải quyết xung đột theo thứ tự quy tắc do quản trị viên gán. Lệnh chặn chỉ đơn giản có hiệu lực, và ứng dụng đang kết nối báo hết thời gian chờ. Quy tắc trông như ngoại lệ chưa bao giờ tham gia cuộc chơi.
Hình thức được hỗ trợ là chính sách từ chối mặc định với các quy tắc cho phép đã được phê duyệt, trong đó mỗi quyền cho phép nêu tên một chương trình, dịch vụ hoặc đích đến đủ chính xác để có thể xem xét. Thiết kế đó vượt qua một cuộc kiểm toán, vì mọi ngoại lệ đều hiển thị và không ngoại lệ nào phụ thuộc vào thứ tự tạo ra chúng.
Hai quy tắc mâu thuẫn với nhau tệ hơn một quy tắc, vì hành vi kết quả vừa đúng vừa không thể giải thích cùng lúc.
Hãy cho chính sách ra ngoài một chủ sở hữu duy nhất
Một ứng dụng khách VPN được hỗ trợ đã duy trì hành vi chặn của riêng nó và các ngoại lệ điểm cuối của riêng nó. Thêm các quy tắc thủ công không phối hợp có thể khiến ứng dụng khách đó mắc kẹt ngoài đường hầm mà nó cần để thiết lập, hoặc để mở một đường thứ hai mà không ai nhận ra.
Quyết định ai sở hữu chính sách ra ngoài trước khi viết quy tắc: cấu hình của chính ứng dụng khách, một chính sách tường lửa được quản lý, hoặc một danh sách ngoại lệ cục bộ được ghi lại kèm chủ sở hữu. Sau đó dung hòa các lớp thay vì chồng chất thử nghiệm cho đến khi có thứ gì đó kết nối được. Chủ sở hữu có tên cũng là người bạn hỏi khi hai lớp không đồng ý.
Hãy giữ một kênh khôi phục trước khi thay đổi bất cứ điều gì. Một máy từ xa bị khóa ngoài đường quản lý của chính nó là kết quả tệ hơn khoảng trống chính sách mà bạn đang đóng. Quy tắc khôi phục dễ biện minh hơn khi được viết trước, và dễ tìm hơn khi một thay đổi đi sai vào giờ mà không ai thích.
Hãy thử bốn kết quả thay vì đọc nhãn
Một chính sách chỉ tốt bằng những trường hợp mà nó phân biệt, nên hãy coi nhãn hồ sơ là điểm khởi đầu chứ không phải kết quả. Bốn kết quả cho biết nó có hoạt động không: yêu cầu LAN dự định thành công, một yêu cầu internet được bao phủ thành công, một yêu cầu trực tiếp bị cấm thất bại, và trường hợp đường hầm hỏng hoạt động như thiết kế thay vì lặng lẽ lùi lại. Ghi bốn kết quả bên cạnh thay đổi quy tắc. Một kế hoạch kiểm thử với bốn trường hợp có tên đủ ngắn để chạy mọi lúc và đủ cụ thể để thất bại ầm ĩ.
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,InterfaceAlias Get-NetFirewallProfile | Select-Object Name,DefaultOutboundAction Get-NetFirewallRule -Direction Outbound -Enabled True | Where-Object Action -eq Block | Select-Object DisplayName,Profile
Lệnh đầu tiên cho thấy mỗi mạng được kết nối được phân loại như thế nào, điều thường không phải là điều người viết quy tắc giả định. Lệnh thứ hai cho thấy hành động mặc định theo hồ sơ, và lệnh thứ ba liệt kê các lệnh chặn ra ngoài đang bật, bao gồm cả những lệnh sẽ âm thầm vô hiệu hóa một quyền cho phép hẹp hơn.
Chạy lại bốn trường hợp sau khi mạng thay đổi, vì một hồ sơ có thể được phân loại lại khi máy tham gia một mạng khác. Một nhãn hồ sơ khớp không phải là bằng chứng rằng đường đi là đường bạn dự định.