Pourquoi une porte de pare-feu liée à l'état du VPN n'est pas une règle de ping réservée au tunnel

Imaginez une règle de pare-feu qui active l'ICMP echo pour l'adresse publique du serveur chaque fois qu'un profil VPN nommé est connecté. On la lit comme « ping uniquement par le tunnel », et cette lecture est fausse d'une manière qui compte. La règle ne restreint pas qui peut atteindre l'hôte ; elle change ce à quoi l'interface publique répond pendant qu'une autre connexion est active. Ce sont deux politiques différentes, et l'une d'elles élargit discrètement l'exposition.

La règle que vous croyez avoir écrite

L'exigence visée est généralement étroite : le système de supervision, ou l'unique administrateur du VPN, doit pouvoir confirmer que le serveur est vivant. Écrite comme une phrase, elle ressemble à un contrôle d'accès sur le tunnel. Écrite comme un objet de pare-feu, elle devient une condition sur le profil public, car c'est là que la requête echo arrive.

Dès que la condition est un état de connexion et non une adresse source, l'ensemble des expéditeurs autorisés n'est plus l'ensemble des pairs du VPN. Quiconque peut atteindre l'adresse publique peut envoyer une requête echo tant que la porte est ouverte. Le tunnel n'est pas devenu le chemin ; le tunnel est devenu l'interrupteur.

Ceux qui promeuvent cette idée ne mentent généralement pas sur l'effet recherché. Il leur fallait un contrôle qui ne réponde que lorsque le lien est sain, et la santé du lien était plus facile à observer via le VPN. L'erreur consiste à traiter un signal de disponibilité comme une décision d'accès, puis à l'automatiser.

Ce que la porte contrôle réellement

Cette conception fusionne deux choses indépendantes, et les séparer constitue l'essentiel du correctif. La première est la portée : quelle adresse locale, quelles adresses distantes, quel protocole et quel type ICMP. La seconde est la condition : si l'objet de règle est activé en ce moment. La portée est ce qu'un pare-feu évalue paquet par paquet ; la condition est ce qu'un script écrit dans le magasin de stratégie, et les deux se réconcilient sur des horloges totalement différentes.

Si l'exigence est réellement limitée aux pairs du VPN, la portée y répond sans aucune logique d'état de connexion : liez la règle à l'interface du tunnel ou à la plage d'adresses du tunnel, limitez les adresses distantes au pool de clients et précisez le type echo plutôt que « ICMP ». Cette règle reste correcte lorsqu'aucun VPN n'est actif et ne peut pas être ouverte par un profil étranger.

Si l'exigence est réellement une porte publique, dites-le dans le texte de la politique, car les critères d'acceptation changent. Une porte publique doit nommer le profil exact, définir ce que signifie « connecté » et indiquer que les expéditeurs publics sont dans la portée par conception. L'essentiel de la confusion disparaît au moment où quelqu'un est obligé d'écrire cette phrase.

Construisez l'objet une fois, puis basculez-le

Prévoyez à l'avance une seule règle dotée d'une identité stable, désactivée, et laissez le contrôleur changer uniquement son état d'activation. Créer des règles par nom d'affichage à chaque exécution, c'est ainsi qu'un magasin de stratégie finit avec cinq objets quasi identiques et aucun moyen fiable de les retirer.

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

Le nom est l'identifiant durable ; le nom d'affichage est une documentation qu'un humain peut modifier. Réconciliez sur -Name et le script cesse de produire des doublons. La même forme de commande couvre le cas IPv6 avec -Protocol ICMPv6 -IcmpType 128, qui est une règle distincte car les numéros de type echo diffèrent entre les deux familles.

Gardez la famille d'adresses et le type ICMP explicites pour une seconde raison : -Protocol ICMPv4 sans type autorise tous les messages ICMPv4 que le profil permet, y compris ceux que vous n'avez jamais eu l'intention d'accepter. Nommer le type 8 resserre la règle sur la requête echo, qui est la seule chose qu'envoie un contrôle d'accessibilité.

Là où l'automatisation contredit l'intention

Interroger un profil client toutes les quelques minutes ne peut pas produire de frontière immédiate. Entre la chute de la connexion et l'interrogation suivante, la règle répond encore sur l'adresse publique ; entre le rétablissement de la connexion et l'interrogation suivante, elle ne répond pas. Reconnaître ce décalage est honnête, affirmer que la conception impose un invariant strict ne l'est pas.

Il y a un piège de portée dans la vérification d'état elle-même. Get-VpnConnection signale les profils clients configurés sur la machine, par défaut pour l'utilisateur actuel et pour tous les utilisateurs avec -AllUserConnection. Il ne signale pas les utilisateurs distants actuellement connectés à un serveur RRAS ; c'est une autre observation avec une autre commande. Une porte bâtie sur la mauvaise n'est connectée à rien.

Couvrez ensuite les états que personne ne scénarise : démarrage avec la règle déjà activée depuis une exécution précédente, plantage du contrôleur alors que la porte est ouverte, et profil supprimé alors que sa règle reste active. Chacun exige un défaut défini, et le défaut sûr pour une autorisation publique est désactivé. Si l'exigence ne supporte vraiment pas la fenêtre d'interrogation, une règle liée à l'état est le mauvais instrument et l'application appartient au tunnel, pas à l'interface publique.

Enfin, testez la requête publique deux fois, une fois avec la connexion choisie active et une fois avec elle coupée, depuis un hôte qui n'est pas sur le VPN. Un ping réussi depuis l'intérieur du tunnel ne prouve rien sur cette politique, et c'est la mesure que la plupart des déploiements sautent.