Bloquer IPsec sans casser le Wi-Fi Calling du téléphone

La demande arrive toujours sous la même forme : fermez IPsec en bordure parce qu'il transporte des tunnels que personne n'a approuvés, et la première plainte vient de quelqu'un dont le téléphone a cessé de passer des appels en Wi-Fi. Les deux faits sont vrais en même temps, et aucun des deux ne justifie d'abandonner le contrôle. Ce dont le pare-feu a besoin, c'est d'une exception de service avec une fonction nommée, une source bornée, des destinations documentées et un responsable. Cinq étapes en font une règle qu'un inconnu pourra réviser l'an prochain.

Nommez le service avant de nommer le protocole

Un téléphone de bureau sur un service SIP et un combiné qui fait le Wi-Fi Calling de l'opérateur ne partagent pas de profil réseau, et VoIP comme terme de pare-feu ne décrit ni l'un ni l'autre. Les données de ports et de destinations doivent venir du fournisseur ou de l'opérateur qui exploite le service, pas d'une liste de ports mémorisée appartenant à un autre système téléphonique. C'est la différence entre une règle qui protège une fonction et une règle qui protège un mot.

La référence des ports de service d'Apple liste UDP 500 et 4500 pour le Wi-Fi Calling, soit exactement la paire que la plupart des blocages globaux d'IPsec écartent. Écrivez le nom de la fonction dans l'enregistrement de changement à côté de ces ports. Ajoutez la version ou la date de la référence utilisée, car les tableaux des fournisseurs sont modifiés. Une règle qui nomme le service pour lequel elle existe peut être révisée ; une règle qui nomme une catégorie de protocole ne le peut pas.

Écrivez l'exception comme un contrat, pas comme une faveur

L'exception énonce la fonction autorisée, les classes d'appareils qui l'utilisent, le transport nécessaire et les destinations que documente la partie responsable. Elle porte aussi un responsable et une date de revue, car les points de terminaison de l'opérateur et les modèles de combinés changent sans prévenir l'équipe du pare-feu. Confiez la revue à une personne plutôt qu'à un nom d'équipe qui survivra à l'équipe. Gardez une formulation assez précise pour qu'un inconnu puisse reconstruire la règle à partir du seul enregistrement.

Placez l'exception dans le même cycle que le reste de la politique de bordure, afin qu'un opérateur qui déplace une destination ou un parc qui change de modèle de combiné soit remarqué lors de la revue et non lors de la panne suivante. Bouclez avec la personne qui a signalé les appels en panne, car elle seule peut confirmer la correction sans rouvrir le tunnel que le blocage devait fermer. Cette confirmation appartient aussi à l'enregistrement, avec une date.

Une autorisation permanente étiquetée comme dépannage téléphonique temporaire est indéfendable deux ans plus tard. Une autorisation liée à un service identifié a une échéance qui se renouvelle volontairement.

Bornez la source honnêtement

Limiter l'exception à un segment d'appareils gérés est nettement plus solide que d'ouvrir le protocole à chaque portable du bâtiment. Si le réseau ne peut pas identifier ce segment, écrivez-le au lieu de laisser entendre que la règle connaît les appareils. Le meilleur résultat au moindre coût est de réutiliser une frontière qui existe déjà pour une autre raison, de sorte que l'exception hérite d'un contrôle au lieu d'en inventer un. Filtrer par adresse n'est pas une authentification d'appareil, et l'enregistrement de changement ne doit pas suggérer le contraire.

Une adresse source ou une adresse matérielle ne prouve pas un combiné physique. Que l'une ou l'autre ait un sens dépend entièrement des autres contrôles à l'intérieur de ce segment. Si l'argument de la règle repose sur une adresse MAC, vérifiez ce qui empêche un utilisateur de la changer avant que la règle ne parte.

Acceptez ce qu'une règle de ports ne peut pas vous dire

Les ports identifient des points de terminaison de transport, pas une intention métier. Quand un service d'appel approuvé et un tunnel non approuvé passent tous deux par UDP 4500, aucune règle fondée sur les ports ne les sépare. Une règle qui prétend le faire paraît précise et ne l'est pas, ce qui est pire qu'une règle qui admet sa propre forme. C'est une limite du mécanisme, pas une erreur de la personne qui l'a écrite.

Dites-le à côté de la règle et associez l'exception à l'application dont le réseau dispose, comme la gestion des appareils ou une liste de destinations autorisées. Exprimez ensuite l'exception aussi étroitement que l'outil le permet, par exemple avec des règles nftables qui nomment le segment et la paire de ports et placent le refus général après elles :

nft add rule inet edge forward ip saddr 10.40.0.0/24 udp dport { 500, 4500 } counter accept
nft add rule inet edge forward udp dport { 500, 4500 } counter drop

nftables évalue dans l'ordre et s'arrête à la première correspondance, donc l'acceptation bornée doit se trouver au-dessus du refus général. Inversez les deux et l'exception ne fait rien en silence.

Validez la fonction et le refus

Exécutez la validation approuvée sur un appel Wi-Fi ordinaire, depuis la classe d'appareil pour laquelle l'exception existe, et confirmez qu'un client exclu échoue toujours. N'utilisez jamais les appels d'urgence comme cas de test, en aucune circonstance. Inspectez ensuite la règle déployée, car un compteur bloqué à zéro est la preuve la plus rapide que l'exception n'a jamais correspondu :

nft -a list chain inet edge forward

Incluez une reconnexion ou un changement de réseau dans le test, et répétez-le depuis un démarrage à froid, le téléphone rejoignant le réseau au lieu d'être déjà attaché. Si le compteur bouge alors que les appels échouent encore, le problème a quitté le pare-feu et relève de la liste de destinations de l'opérateur.