L'accélération NAT matérielle casse-t-elle vos règles de routage VPN ?

Activer l'accélération NAT matérielle peut rendre une configuration VPN plus rapide, et elle peut aussi faire qu'une politique de routage cesse de s'appliquer à certains paquets sans la moindre erreur. Laquelle de ces deux choses se produit dépend de ce que le chemin rapide contourne, et cela varie selon le firmware, la version du noyau et le type d'accélération utilisé. Le menu des réglages vous dit rarement laquelle vous venez d'activer.

Deux affirmations méritent d'être séparées avant de blâmer l'accélérateur : qu'une règle a cessé d'être appliquée, et qu'un compteur a cessé d'être mis à jour. Ce ne sont pas les mêmes observations.

Trois accélérations différentes sont confondues

Le délestage de la transmission, l'accélération cryptographique et le délestage du canal de données du tunnel sont des mécanismes distincts qui partagent souvent un seul commutateur. Le délestage de la transmission permet aux flux établis d'éviter une partie de la pile normale, l'accélération cryptographique rend le travail de chiffrement moins coûteux, et le délestage du tunnel déplace l'encapsulation vers le matériel. Un routeur qui accélère le trafic routé ordinaire peut laisser le trafic du tunnel entièrement sur le chemin lent, ce qui est un résultat de performance et non un changement de politique. L'inverse existe aussi, où le trafic du tunnel est délesté tandis que la politique environnante est encore évaluée.

Les flowtables de Linux sont le cas documenté qui vaut le plus la peine d'être lu, puisque les flux établis peuvent être confiés à un chemin rapide. Leur comptabilité et leur gestion d'état diffèrent alors de la transmission classique, et c'est pourquoi les compteurs commencent à paraître étranges.

Un compteur qui cesse de bouger prouve peu

Les compteurs de règles comptent les paquets qui traversent la règle, et un flux délesté peut ne plus jamais la traverser après le premier paquet. Cela produit un compteur qui se fige alors que le trafic continue, et il ressemble exactement à un contournement si vous croyez le chiffre. Surveiller le compteur reste utile comme indice que le flux a quitté le chemin compté. Le reste du diagnostic doit venir de là où vont réellement les paquets.

L'inférence inverse échoue tout aussi mal. Un téléchargement rapide ne montre pas que vos règles d'exception et votre gestion des défaillances s'appliquent encore, car il exerce un flux et non la politique.

Trois conditions décident si le délestage casse la politique

La première condition est si le chemin rapide consulte le point d'accroche dont dépend votre politique, car une politique exprimée en marques et en routes survit plus souvent qu'une politique construite sur un filtrage paquet par paquet. La deuxième est si le firmware autorise seulement cette combinaison, parce que certaines versions désactivent automatiquement le délestage lorsqu'un tunnel ou une fonction de pare-feu est actif. La troisième est si le trafic est éligible, car l'accélération est généralement liée aux flux établis et peut exclure les paquets fragmentés ou inhabituels. Là où les trois favorisent l'accélération, la politique s'applique toujours, et là où la première échoue, aucun réglage ne la rétablit.

Lisez la documentation du fournisseur pour la combinaison que vous exécutez, et non pour le modèle de routeur en général. Les versions de firmware changent ces réponses en silence.

Testez la politique, pas le débit

Mesurez ce que la politique est censée garantir avant de mesurer sa vitesse. Les commandes ci-dessous montrent si une flowtable est installée, ce que voit le suivi des connexions et par quelle adresse le client sort. Comparez une nouvelle connexion après le changement, car une connexion établie peut conserver son ancien chemin.

nft list flowtables
conntrack -L | head -n 20
curl -sS --max-time 8 https://api.ipify.org; echo
ping -c 3 192.168.50.20

Une entrée de flowtable couvrant le trafic du tunnel vous indique que le chemin rapide est en jeu, et la table des connexions montre si le flux est suivi comme vous l'attendez. La vérification d'adresse confirme la sortie lorsque la politique concerne l'accès à internet, tandis que le ping confirme une destination privée qui doit rester joignable. Exécutez la même série avec l'accélération désactivée puis activée, et comparez les résultats plutôt que les durées.

Notez le réglage précédent pour que l'expérience reste réversible. Une instruction générique de désactiver le délestage partout compte comme un contournement, pas comme une constatation.