Perfís de firewall fronte á saída VPN: por que público non é un camiño
Un perfil de firewall escolle que conxunto de regras se aplica. Non di nada sobre que interface transportou o paquete, e un bloqueo explícito vence un permiso máis estreito.
A regra soa precisa: permitir o tráfico local no perfil privado e só o tráfico VPN no público. Non o é, porque un perfil de rede escolle que conxunto de regras de firewall se aplica e non di nada sobre que adaptador transportou un paquete. Tratar o nome do perfil como un requisito de camiño é o erro que fai que un deseño de saída restrinxida pareza rematado cando non o está.
Primeiro anote os fluxos e despois decida que mecanismo pode impor realmente cada un. Esa lista de fluxos é o único artefacto que sobrevive ao seguinte cambio de regras.
A categoría escolle regras, non rutas
Cando Windows clasifica unha rede como pública ou privada, o firewall aplica o conxunto de regras configurado para ese perfil. A clasificación segue a rede á que se uniu o adaptador, e o conxunto de regras decide que se permite nela. Ningún deses feitos depende de se o tráfico dunha aplicación usou o túnel. Esa independencia é toda a dificultade.
A elección de camiño faina o encamiñamento, mediante a métrica da interface e o prefixo que instala o túnel. Un perfil pode por tanto estar etiquetado como público mentres a conexión dunha aplicación toma o camiño físico, e o firewall seguirá informando de que se aplicou o conxunto de regras público.
Por iso unha regra limitada ao perfil non pode significar só túnel. As dúas propiedades décidenas compoñentes distintos e unha non pode substituír a outra.
| 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 |
Un bloqueo explícito prevalece sobre un permiso máis estreito
A guía de Microsoft sobre regras de firewall distingue un permiso como excepción a unha acción de bloqueo predeterminada dun bloqueo explícito que entra en conflito cun permiso. Os bloqueos explícitos gañan ese conflito, e as regras de saída obedecen a mesma precedencia.
Así que a receita popular de engadir unha regra que bloquea todo e confiar nun permiso máis estreito colocado por riba non fai o que o seu autor espera. O Firewall de Windows non resolve o conflito pola orde de regras asignada polo administrador. O bloqueo simplemente se aplica, e a aplicación que se conecta informa dun tempo de espera esgotado. A regra que parecía a excepción nunca estivo en xogo.
A forma admitida é unha política de denegación predeterminada con regras de permiso aprobadas, onde cada permiso nomea un programa, un servizo ou un destino coa precisión suficiente para poder revisarse. Ese deseño sobrevive a unha auditoría, porque cada excepción é visible e ningunha depende da orde en que se creou.
Dúas regras que se contradín son peores que unha soa regra, porque o comportamento resultante é correcto e inexplicable ao mesmo tempo.
Dea á política de saída un único propietario
Un cliente VPN compatible xa mantén o seu propio comportamento de bloqueo e as súas propias excepcións de punto final. Engadir regras manuais non coordinadas pode deixar ese cliente fóra do túnel que necesita para configurarse, ou deixar aberto un segundo camiño que ninguén notou.
Decida quen é dono da política de saída antes de escribir regras: a propia configuración do cliente, unha política de firewall xestionada ou unha lista local de excepcións documentada cun propietario. Despois concilie as capas en lugar de apilar experimentos ata que algo se conecte. Un propietario con nome é tamén a quen se pregunta cando dúas capas discrepan.
Conserve unha canle de recuperación antes de cambiar nada. Unha máquina remota bloqueada fóra da súa propia ruta de xestión é un resultado peor que o oco de política que estaba pechando. A regra de recuperación é máis fácil de xustificar cando está escrita de antemán, e máis fácil de atopar cando un cambio sae mal a unha hora que a ninguén lle gusta.
Probe catro resultados en lugar de ler a etiqueta
Unha política é tan boa como os casos que distingue, así que trate a etiqueta do perfil como un punto de partida e non como un resultado. Catro resultados dinnos se funciona: a solicitude LAN prevista ten éxito, unha solicitude de internet cuberta ten éxito, unha solicitude directa prohibida falla, e o caso de fallo do túnel compórtase como se deseñou en lugar de retroceder en silencio. Anote os catro resultados xunto ao cambio de regras. Un plan de probas con catro casos nomeados é o bastante curto para executalo cada vez e o bastante concreto para fallar ruidosamente.
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
O primeiro comando mostra como se clasifica cada rede conectada, o que a miúdo non é o que supuxo a persoa que escribiu a regra. O segundo mostra a acción predeterminada por perfil, e o terceiro enumera os bloqueos de saída habilitados, incluídos os que anularán en silencio un permiso máis estreito.
Execute de novo os catro casos tras un cambio de rede, porque un perfil pode reclasificarse cando a máquina se une a outra rede. Unha etiqueta de perfil coincidente non é proba de que o camiño fose o que vostede pretendía.