Por que unha porta de devasas ligada ao estado da VPN non é unha regra de ping só polo túnel

Imaxine unha regra de devasas que activa o ICMP echo para o enderezo público do servidor cada vez que hai un perfil de VPN conectado. Lese como «ping só polo túnel», e esa lectura é errónea dun xeito que importa. A regra non restrinxe quen pode chegar ao servidor; cambia o que responde a interface pública mentres outra conexión está activa. Son dúas políticas distintas, e unha delas amplía a exposición sen facer ruído.

A regra que crees que escribiches

O requisito previsto adoita ser estreito: o sistema de monitorización, ou o único administrador da VPN, debe poder confirmar que o servidor está vivo. Escrito como unha frase, soa a control de acceso no túnel. Escrito como un obxecto de devasas, convértese en unha condición no perfil público, porque é alí onde chega a solicitude echo.

Cando a condición é un estado de conexión e non un enderezo de orixe, o conxunto de remitentes permitidos xa non é o conxunto de pares da VPN. Calquera que poida chegar ao enderezo público pode enviar unha solicitude echo mentres a porta está aberta. O túnel non se converteu no camiño; o túnel converteuse no interruptor.

Quen promove esta idea normalmente non mente sobre o efecto que quería. Necesitaban unha comprobación que só respondese cando a ligazón está sa, e a saúde da ligazón era máis doada de observar a través da VPN. O erro é tratar un sinal de dispoñibilidade como unha decisión de acceso e despois automatizalo.

Que controla realmente a porta

Este deseño fusiona dúas cousas independentes, e separalas é a maior parte da corrección. A primeira é o alcance: que enderezo local, que enderezos remotos, que protocolo e que tipo de ICMP. A segunda é a condición: se o obxecto de regra está habilitado neste momento. O alcance é o que unhas devasas avalían por paquete; a condición é o que un script escribe no almacén de políticas, e ambos se concilian con reloxos completamente distintos.

Se o requisito é realmente só pares da VPN, o alcance respóndelle sen ningunha lóxica de estado de conexión: ligue a regra á interface do túnel ou ao rango de enderezos do túnel, limite os enderezos remotos ao grupo de clientes e especifique o tipo echo en lugar de «ICMP». Esa regra segue sendo correcta cando non hai ningunha VPN activa e non a pode abrir un perfil alleo.

Se o requisito é realmente unha porta pública, dígao no texto da política, porque os criterios de aceptación cambian. Unha porta pública debe nomear o perfil exacto, definir que significa «conectado» e declarar que os remitentes públicos están dentro do alcance por deseño. A maior parte da confusión desaparece no momento en que alguén se ve obrigado a escribir esa frase.

Constrúa o obxecto unha vez e despois conmúteo

Aprovisione de antemán unha soa regra cunha identidade estable, deshabilitada, e deixe que o controlador cambie só o seu estado de habilitación. Crear regras polo nome para mostrar en cada execución é como un almacén de políticas acaba con cinco obxectos case idénticos e sen forma fiable de quitalos.

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 duradeiro; o nome para mostrar é documentación que unha persoa pode editar. Concilie por -Name e o script deixa de producir duplicados. A mesma forma de comando cobre o caso IPv6 con -Protocol ICMPv6 -IcmpType 128, que é unha regra aparte porque os números de tipo echo difiren entre as dúas familias.

Manteña a familia de enderezos e o tipo de ICMP explícitos por unha segunda razón: -Protocol ICMPv4 sen un tipo permite todos os mensaxes ICMPv4 que o perfil admite, incluídos os que nunca quixo aceptar. Nomear o tipo 8 estreita a regra á solicitude echo, que é o único que envía unha comprobación de accesibilidade.

Onde a automatización contradí a intención

Sondar un perfil de cliente cada poucos minutos non pode producir unha fronteira inmediata. Entre a caída da conexión e a seguinte sondaxe, a regra segue respondendo no enderezo público; entre a subida da conexión e a seguinte sondaxe, non. Recoñecer ese atraso é honesto, e afirmar que o deseño impón un invariante estrito non o é.

Hai unha trampa de alcance na propia comprobación de estado. Get-VpnConnection informa dos perfís de cliente configurados na máquina, por defecto para o usuario actual e para todos os usuarios con -AllUserConnection. Non informa dos usuarios remotos que neste momento marcan cara a un servidor RRAS; esa é outra observación con outro comando. Unha porta construída sobre a incorrecta non está conectada a nada.

Logo cubra os estados que ninguén programa: arranque coa regra xa habilitada dunha execución anterior, caída do controlador coa porta aberta e perfil borrado mentres a súa regra segue viva. Cada un necesita un valor por defecto definido, e o valor seguro para un permiso público é deshabilitado. Se o requisito non tolera a xanela de sondaxe, unha regra ligada ao estado é o instrumento equivocado e a aplicación pertence ao túnel, non á interface pública.

Por último, probe a solicitude pública dúas veces, unha coa conexión seleccionada activa e outra con ela caída, desde un servidor que non estea na VPN. Un ping correcto desde dentro do túnel non demostra nada sobre esta política, e esa é a medición que a maioría dos despregamentos omite.