Quel paquet une politique VPN à double WAN doit-elle cibler ?

Les demandes d’acheminer le VPN par le second lien décrivent au moins deux tâches différentes, et la politique qui corrige l’une ne touche pas l’autre. Dans la première, le transport chiffré entre deux extrémités passe à une autre adresse WAN. Dans la seconde, le flux applicatif déchiffré d’un utilisateur connecté sort vers un autre saut suivant. Les deux sont légitimes, les deux utilisent le routage, et chacune exige une correspondance sur un paquet qui existe au point où la décision est prise. Suivez les vérifications ci-dessous dans l’ordre, car la première détermine quel paquet les règles suivantes doivent nommer.

Nommez les deux conversations

Imaginez un télétravailleur rattaché à une passerelle de bureau, qui ouvre HTTPS vers un serveur applicatif interne. Deux conversations indépendantes sont sur le fil, et elles ont des adresses différentes à chaque extrémité. La conversation externe circule entre les deux extrémités du VPN : de l’adresse de la passerelle à l’adresse du pair, avec le protocole et le port que le déploiement a négociés. La conversation interne va de l’adresse attribuée au client à l’adresse du serveur applicatif sur le port 443.

Le port de destination de l’application n’est pas le port de transport du VPN, et aucune quantité de politique sur TCP 443 ne déplacera le tunnel. De même, une règle qui redirige l’adresse de transport du pair ne dit rien de l’endroit où va la requête HTTP de cet utilisateur après le déchiffrement. Notez les deux conversations avec leurs adresses réelles avant de toucher à une règle, car l’essentiel de la confusion dans ce domaine vient du fait de nommer l’une et de configurer l’autre.

Trouvez où votre politique voit réellement le paquet

La correspondance doit être évaluée dans la chaîne et l’espace de noms où le paquet est encore sous la forme que vous avez décrite. Une règle accrochée à l’entrée du LAN voit le paquet interne, non chiffré, avant qu’il ne soit routé vers le tunnel. Une règle appliquée au trafic d’origine locale voit les paquets que la passerelle génère elle-même, et elle ne couvre pas automatiquement le trafic que la passerelle ne fait que transmettre. La sortie encapsulée est encore un troisième cas, généralement traité sur l’interface qui porte le tunnel et non du côté du LAN.

C’est pourquoi le même extrait de configuration se comporte différemment sur deux plateformes : les points d’accroche diffèrent, et le point d’ancrage de politique d’un constructeur peut se situer avant ou après l’étape de chiffrement. Lisez le chemin du paquet pour le produit précis plutôt que de supposer l’ordre d’après le schéma d’un autre constructeur.

Confirmez le transport négocié

Pour IPsec encapsulé en UDP, RFC 3948 place ESP à l’intérieur d’UDP et utilise un marqueur non-ESP pour que IKE reste distinguable sur le port partagé. L’ESP simple est un protocole IP, pas un port TCP ou UDP, donc une règle de pare-feu écrite sur un numéro de port ne le ciblera pas du tout. Cette distinction décide si votre politique WAN a besoin d’une règle UDP, d’une règle de protocole, ou des deux.

Les valeurs négociées l’emportent sur les valeurs mémorisées. Lisez les ports et adresses actuels de l’association depuis l’équipement au lieu d’ajouter TCP 4500 ou un ancien port constructeur au cas où, ce qui capte du trafic sans rapport et masque le véritable problème de classification.

Vérifiez le chemin de retour avant de vous engager

Un succès sortant prouve la moitié d’une conception. Un paquet qui revient vers le pool de clients distants n’est plus visible sous l’adresse du client dès que l’encapsulation la remplace : la destination externe est l’adresse de transport du pair. Si le second lien atteint ce pair par un opérateur différent, sa traduction et son filtrage peuvent diverger du premier, et l’association devra peut-être être reconstruite plutôt que migrée.

L’état de traduction d’adresses réseau est la victime habituelle d’un changement de WAN. Notez le lien retenu, l’adresse source externe attendue, la traduction utilisée et l’accessibilité du pair en retour, puis gardez le transport joignable sans l’envoyer dans le tunnel qu’il porte.

Vérifiez les deux couches avec deux captures

Une capture sur l’interface WAN et une à l’intérieur du tunnel tranchent la question plus vite que n’importe quelle comparaison de configuration. Exécutez-les depuis la passerelle pendant qu’un client approuvé effectue une seule requête, et conservez les deux fichiers.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

La première capture doit montrer la conversation externe quittant l’interface que vous vouliez, avec l’adresse source attendue. La seconde doit montrer la conversation interne une seule fois, non dupliquée, avec l’adresse du client comme source et le serveur applicatif comme destination. La recherche de route confirme quelle table le routeur utiliserait pour ce couple source et destination, et c’est là qu’une erreur de politique apparaît d’ordinaire. Si l’une des captures n’apparaît pas, le point de décision est ailleurs que là où la règle a été accrochée, et la correction appartient à cet endroit et non à une correspondance plus large.