Règles VPN sur le routeur : associer la source et la destination

Les pages d’achat de routeurs présentent le routage VPN comme une simple case à cocher, et cette formule cache trois questions différentes. La règle correspond-elle à l’appareil qui envoie le trafic, au serveur qui le reçoit, ou aux deux ? Que devient le trafic qui ne correspond à aucun des deux ? Et lorsque deux règles se chevauchent, laquelle l’emporte ? Écrire la réponse sous forme de paire source et destination transforme une vague liste de fonctions en conception testable.

Le nom de la fonction cache deux extrémités

Un lecteur multimédia qui doit utiliser le tunnel est une correspondance de source. Un préfixe de bureau privé qui doit être joignable par le tunnel est une correspondance de destination. Un poste de travail qui ne doit utiliser le tunnel que pour un service est les deux, et cette intersection est le cas que la plupart des firmwares grand public gèrent mal.

Écrivez l’exigence sous forme de paire avant de comparer les produits. C’est cette paire que vous testerez plus tard.

Un produit qui propose une liste d’appareils ou une liste globale de destinations ne peut peut-être pas exprimer « uniquement cet appareil, uniquement ces destinations ». L’écart n’est pas cosmétique : une règle de destination globale envoie le trafic de tous les appareils vers ce site par le tunnel, et une règle d’appareil envoie tout le trafic de cet appareil. Ni l’une ni l’autre n’est l’exigence. Testez ce cas avec deux appareils avant de faire confiance à l’écran.

Construisez la règle comme une intersection

Un tableau garde la conception honnête. Placez le scénario à gauche, puis nommez séparément la correspondance d’émetteur et celle de cible :

La troisième ligne est la plus intéressante, car elle exige les deux moitiés à la fois. Si le firmware ne peut exprimer qu’un seul axe, l’exigence doit être scindée en deux règles ou déplacée vers un appareil capable de le faire.

Gardez l’identité de la source stable. Une réservation DHCP, un segment dédié ou un mécanisme d’identité d’appareil fonctionnent, mais une adresse qui change à l’expiration du bail ne fonctionne pas. Incluez IPv6, car une adresse IPv4 n’identifie pas tout le trafic d’un appareil.

La priorité décide du chevauchement

Le chevauchement de règles est normal. Une règle d’appareil large et une règle de destination étroite peuvent décrire un même flux, et l’ordre de priorité documenté décide laquelle l’emporte. Un écran de réglages séduisant ne vous dit pas cet ordre.

Lisez le manuel pour l’ordre et pour le cas sans correspondance, puis testez les deux avec du trafic que vous pouvez observer :

ip rule show
ip route get 203.0.113.10

Si la documentation n’indique pas l’ordre, supposez que la règle la plus étroite peut ne pas l’emporter et concevez en conséquence. Deux règles qui ne peuvent pas entrer en conflit sont plus faciles à maintenir qu’une règle astucieuse dont la priorité n’est pas documentée.

Les noms ont besoin d’une politique de rafraîchissement

Une destination écrite comme un domaine ajoute un problème de maintenance. Le routeur doit la résoudre, rafraîchir le mappage, gérer plusieurs adresses et sous-domaines et composer avec le DNS applicatif qui contourne le résolveur attendu.

Copier un seul résultat de recherche dans une règle IP est un instantané, pas une politique de domaine.

Décidez de l’ancienneté tolérée d’une réponse avant que la règle soit fausse, et de ce que fait le routeur quand la résolution échoue. Une règle qui conserve la dernière adresse connue peut survivre à une migration de service ; une règle qui supprime l’entrée peut arrêter silencieusement le tunnel. L’un ou l’autre comportement est acceptable s’il est consigné à côté de la règle.

Définissez l’état indisponible

Une préférence de route n’impose pas un trafic uniquement VPN. Lorsque le tunnel est arrêté, le routeur peut bloquer le flux, l’envoyer en direct ou utiliser un autre tunnel, et chaque choix a une signature de panne différente.

Décidez lequel l’exigence demande, puis vérifiez-le en arrêtant le tunnel et en observant le flux :

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10

Le trafic émis par le routeur lui-même est un périmètre distinct. Le transfert DNS, les vérifications de mise à jour et la supervision peuvent lancer de nouveaux flux depuis le routeur lui-même au lieu d’hériter de la correspondance de source de l’appareil. Tenez compte de ces flux explicitement, sinon ils apparaîtront comme des fuites inexpliquées dans les journaux.