Une table VPN vide ne bloque rien à elle seule

Une règle de politique envoie les paquets marqués vers une table dédiée, et l’attente habituelle est que la perte de la route VPN les bloque. Le mécanisme fait autre chose. Lorsqu’une table ne contient aucune route correspondante, la recherche se poursuit vers la règle suivante au lieu de s’arrêter, et la table main conserve toujours une route par défaut ordinaire pour l’uplink. Le résultat est une configuration qui ressemble à fail-closed et se comporte en fail-open.

Rien n’est cassé ; c’est ainsi que le routage par politiques est spécifié.

La recherche continue quand une table n’a rien

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

Prenez cet ensemble de règles : une recherche marquée va vers la table 42, et une règle ultérieure envoie la même marque vers une table nommée default. Tant que la table 42 contient une route par défaut utilisable, la première recherche fournit le chemin. Quand cette route disparaît et que rien d’autre dans la table 42 ne correspond, la recherche ne devient pas un rejet ; le traitement passe à la règle suivante, et lorsque celle-ci ne trouve rien non plus, il atteint la table main. Rien dans cette séquence n’indique quelle règle a produit la réponse finale, donc une connexion qui fonctionne ressemble à une politique qui fonctionne.

La table 253, appelée conventionnellement default, est une table de routage ordinaire et elle est normalement vide. Son nom n’est pas une instruction de rejeter les paquets, et ce n’est pas la même chose qu’une route de destination par défaut à l’intérieur d’une table.

Les actions terminales terminent la recherche

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

Une règle terminale peut suivre la recherche VPN à la place d’une recherche dans une table vide. Avec la même marque, une action prohibit placée après la règle de la table 42 termine la recherche lorsque cette table ne donne rien, en renvoyant un rejet administratif au lieu d’offrir à la table main une nouvelle chance. Unreachable et blackhole sont aussi terminaux, avec un comportement d’erreur différent pour l’émetteur.

Une route de type throw est différente : à l’intérieur de cette table, elle se comporte comme si rien ne correspondait, donc les règles suivantes ont toujours leur tour. Cela rend throw utile pour un repli délibéré et incorrect comme bloc final.

Vérifiez avec la marque et l’interface réelles

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

Inspectez les règles et la table réelles plutôt qu’un schéma, puis interrogez le flux avec le contexte de source, de marque et d’entrée qu’il possède réellement. Une recherche en lecture seule visant une destination, à laquelle on indique l’adresse source, l’interface et la marque, rapporte la route que le noyau choisirait sans qu’un paquet ne sorte. Fournir une marque dans la requête ne prouve pas que le pare-feu marque le trafic réel ; c’est une vérification distincte des règles de marquage. Confirmez la valeur avec un compteur ou un journal avant de tirer des conclusions de la requête.

Les requêtes générées localement ont besoin de leur propre contexte, car leur chemin de marquage diffère souvent de celui du trafic transmis. Vérifiez-les avec l’interface de sortie que l’application utiliserait réellement.

Deux états de défaillance, pas un

Un état de défaillance est la disparition de la route VPN et la chute du trafic vers l’uplink. Un tunnel mort dont la route reste installée en est un autre : les paquets restent dirigés vers un chemin inutilisable au lieu de tomber, et le symptôme est une perte silencieuse plutôt qu’une connexion directe visible. Testez les deux, ainsi que le comportement au démarrage, à la reconnexion et à l’arrêt du service.

Une telle règle n’aide que tant qu’elle existe et tant que les paquets portent encore la marque qui la sélectionne. Un script d’arrêt qui supprime la règle, ou un chemin qui retire la marque, rétablit le comportement ouvert. Ces transitions méritent d’être répétées.

Appliquez la politique à IPv6 séparément et gardez les exceptions de point de terminaison approuvées explicites plutôt qu’implicites.