Porque um portão de firewall ligado ao estado da VPN não é uma regra de ping só pelo túnel

Imagine uma regra de firewall que ativa o ICMP echo para o endereço público do servidor sempre que um perfil de VPN nomeado está ligado. Lê-se como «ping apenas pelo túnel», e essa leitura está errada de uma forma que importa. A regra não restringe quem pode chegar ao anfitrião; altera o que a interface pública responde enquanto outra ligação está ativa. São duas políticas diferentes, e uma delas alarga em silêncio a exposição.

A regra que julga ter escrito

O requisito pretendido costuma ser estreito: o sistema de monitorização, ou o único administrador na VPN, deve poder confirmar que o servidor está vivo. Escrito como uma frase, soa a controlo de acesso no túnel. Escrito como um objeto de firewall, torna-se uma condição no perfil público, porque é aí que chega o pedido echo.

Assim que a condição é um estado de ligação e não um endereço de origem, o conjunto de remetentes permitidos deixa de ser o conjunto de pares da VPN. Qualquer pessoa que alcance o endereço público pode enviar um pedido echo enquanto o portão está aberto. O túnel não passou a ser o caminho; o túnel passou a ser o interruptor.

Quem promove esta ideia normalmente não mente sobre o efeito que queria. Precisava de uma verificação que só respondesse quando a ligação está sã, e a saúde da ligação era mais fácil de observar através da VPN. O erro é tratar um sinal de disponibilidade como uma decisão de acesso e depois automatizá-lo.

O que o portão controla realmente

Este desenho funde duas coisas independentes, e separá-las é a maior parte da correção. A primeira é o âmbito: que endereço local, que endereços remotos, que protocolo e que tipo de ICMP. A segunda é a condição: se o objeto da regra está ativado neste momento. O âmbito é o que uma firewall avalia por pacote; a condição é o que um script escreve no armazém de políticas, e os dois conciliam-se em relógios completamente diferentes.

Se o requisito for realmente apenas pares da VPN, o âmbito responde a isso sem qualquer lógica de estado de ligação: ligue a regra à interface do túnel ou ao intervalo de endereços do túnel, limite os endereços remotos ao conjunto de clientes e especifique o tipo echo em vez de «ICMP». Essa regra mantém-se correta quando não há VPN ativa e não pode ser aberta por um perfil alheio.

Se o requisito for realmente um portão público, diga-o no texto da política, porque os critérios de aceitação mudam. Um portão público tem de nomear o perfil exato, definir o que significa «ligado» e declarar que os remetentes públicos estão no âmbito por desenho. A maior parte da confusão desaparece no momento em que alguém é obrigado a escrever essa frase.

Construa o objeto uma vez e depois comute-o

Preveja antecipadamente uma única regra com uma identidade estável, desativada, e deixe o controlador mudar apenas o seu estado de ativação. Criar regras pelo nome de apresentação em cada execução é como um armazém de políticas acaba com cinco objetos quase idênticos e sem forma fiável de os remover.

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

O nome é o identificador duradouro; o nome de apresentação é documentação que uma pessoa pode editar. Reconcilie por -Name e o script deixa de produzir duplicados. A mesma forma de comando cobre o caso IPv6 com -Protocol ICMPv6 -IcmpType 128, mas é uma regra separada porque os números do tipo echo diferem entre as duas famílias.

Mantenha a família de endereços e o tipo de ICMP explícitos por uma segunda razão: -Protocol ICMPv4 sem tipo permite todas as mensagens ICMPv4 que o perfil admite, incluindo as que nunca quis aceitar. Nomear o tipo 8 estreita a regra ao pedido echo, e é a única coisa que uma verificação de acessibilidade envia.

Onde a automatização contradiz a intenção

Inquirir um perfil de cliente a cada poucos minutos não pode produzir uma fronteira imediata. Entre a queda da ligação e o inquérito seguinte a regra ainda responde no endereço público; entre a subida da ligação e o inquérito seguinte não responde. Reconhecer esse atraso é honesto; afirmar que o desenho impõe um invariante estrito não é.

Há uma armadilha de âmbito na própria verificação de estado. Get-VpnConnection comunica os perfis de cliente configurados na máquina, por predefinição para o utilizador atual e para todos os utilizadores com -AllUserConnection. Não comunica os utilizadores remotos que neste momento estão ligados a um servidor RRAS; essa é outra observação com outro comando. Um portão construído sobre a errada não está ligado a nada.

Depois cubra os estados que ninguém programa: arranque com a regra já ativada de uma execução anterior, queda do controlador com o portão aberto e perfil apagado enquanto a sua regra continua viva. Cada um exige um valor predefinido definido, e o valor seguro para uma autorização pública é desativado. Se o requisito não tolera a janela de inquérito, uma regra ligada ao estado é o instrumento errado e a aplicação pertence ao túnel, não à interface pública.

Por fim, teste o pedido público duas vezes, uma com a ligação escolhida ativa e outra com ela desligada, a partir de um anfitrião que não esteja na VPN. Um ping bem-sucedido de dentro do túnel não prova nada sobre esta política, e é essa a medição que a maioria das implementações salta.