Les règles de pare-feu NEW seules ne ferment pas tous les chemins WAN

Rejeter les nouvelles connexions sortantes sur le WAN ressemble à une politique de fermeture en cas d’échec, mais c’est une promesse plus étroite qu’il n’y paraît. Les paquets appartenant à des flux déjà existants n’y correspondent pas, et beaucoup de réponses non plus. Cet écart est facile à manquer parce que la règle se lit comme si elle couvrait l’interface et non un état de connexion sur celle-ci. Et lire la correspondance d’état comme un verdict produit précisément un faux sentiment de fermeture.

L’état est une condition de correspondance, pas un verdict

Le suivi des connexions classe les paquets selon ce que le pare-feu a déjà vu, et non selon ce que l’application croit. Un flux observé dans les deux sens est établi, et ses paquets ultérieurs le restent même lorsque la route en dessous passe d’un tunnel à la liaison montante ordinaire. La réponse à une connexion entrante peut aussi être du trafic établi. Ces paquets ne redeviennent jamais nouveaux.

C’est pourquoi une règle limitée aux nouvelles connexions ne peut pas établir que chaque paquet protégé est bloqué. Elle laisse les autres états à ce que le reste du jeu de règles en fait, ce qui peut être une acceptation placée plus tôt dans la chaîne.

Lisez la règle dans son environnement

Une acceptation large du trafic établi et associé placée avant le blocage laisse passer un paquet avant même que le blocage soit évalué. Retirer la condition d’état d’une règle ultérieure n’y changera rien, car l’évaluation ne l’atteint jamais. L’ordre décide du résultat, et la correspondance d’état décide quels paquets atteignent cet ordre.

Inspectez le jeu de règles effectif plutôt que le fichier que vous avez modifié, y compris les sauts vers d’autres chaînes et tout ce que la plateforme génère. Sur un routeur géré par iptables, l’affichage de la chaîne montre les définitions de règles, et les chaînes qu’elle référence doivent aussi être suivies. Un système nftables natif exige l’examen de son propre jeu de règles et des priorités de hooks, car le micrologiciel génère rarement des chaînes identiques.

Les compteurs indiquent quelle règle a réellement correspondu, et ils sont généralement plus instructifs qu’une capture de paquets prise après la décision. Une règle dont le compteur est à zéro n’a pas été atteinte, quoi qu’en suggère sa position.

Exprimez l’interdiction indépendamment de l’état

Si un groupe de clients ne doit jamais atteindre internet hors du tunnel, dites-le directement au lieu de l’approximer avec un seul état. La règle doit sélectionner sur la source, la sortie et la destination sans dépendre de l’état de connexion, et elle doit se trouver là où aucune acceptation antérieure ne peut la contourner. L’accès de gestion et les exceptions du réseau local reçoivent alors leurs propres règles explicites, de sorte que l’intention est visible dans la politique.

Choisir reject plutôt que drop change la façon dont le trafic correspondant échoue, et n’élargit pas l’ensemble des paquets que la règle sélectionne. Une connexion refusée et un délai silencieux sont des symptômes différents qui pointent vers la même sélection.

Une politique qui autorise délibérément les réponses à un accès initié à distance via le WAN est défendable. Il faut simplement la décrire ainsi plutôt que la présenter comme un isolement total uniquement par le tunnel.

Vérifiez qui se trouve réellement dans le groupe

L’exemple couvre le trafic IPv4 transféré depuis un préfixe sur une interface. Il ne dit rien sur IPv6, sur une seconde liaison montante ni sur le trafic que le routeur lui-même origine. Un routeur agissant comme résolveur DNS envoie ses propres requêtes amont, et celles-ci ne passent pas du tout par la chaîne forward.

Confirmez que les clients protégés ont encore des adresses dans le préfixe choisi, car un appareil qui en est sorti est direct par accident et non par politique. Élargir le blocage à tout le LAN sans revoir la conception des exceptions tend aussi à supprimer votre propre chemin d’administration.

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

Ensuite, testez un ancien flux à côté d’un nouveau. Une nouvelle tentative de connexion et un transfert bidirectionnel déjà actif se comportent différemment sous cette règle, et seul le test des deux montre quelle politique vous avez réellement.