Une route VPN par défaut dans la table 200 cache votre route LAN

Quatre vérifications séparent un défaut de table de politiques d’un défaut de routage : quelle règle a correspondu, quelle table cette règle a nommée, ce que contient cette table et quelle route y a gagné. La table principale n’est plus consultée dès qu’une table antérieure produit une route, si bien qu’une entrée LAN visible là peut être sans rapport avec le paquet que vous testez. Faites les vérifications dans l’ordre, et la route manquante apparaîtra à la troisième étape plutôt qu’à la quatrième.

La correspondance du préfixe le plus long se fait à l’intérieur d’une seule table ; elle ne compare pas les routes de toutes les tables comme une liste unique.

La recherche s’arrête à la première table qui répond

Prenez une politique où le trafic d’un sous-réseau consulte d’abord la table 200, où la table 200 contient une route par défaut via le tunnel et où la table principale contient le préfixe LAN. Un paquet destiné à une adresse LAN peut correspondre à cette route par défaut de la table 200 et s’arrêter là. Comme la recherche a produit une route, la règle ultérieure de la table principale n’a jamais l’occasion d’offrir son entrée plus spécifique. Le résultat est un paquet qui entre dans le tunnel alors qu’une route LAN parfaitement valable reste inutilisée.

Les règles antérieures et la recherche d’adresses locales de la machine s’appliquent toujours, donc le test doit utiliser la source, la marque et l’interface que porte le flux réel. Interrogez avec autre chose et le LAN peut être sélectionné correctement, ce qui masque précisément le défaut que vous traquez.

Placez l’exception LAN là où elle doit être

La table choisie peut porter les routes LAN, connectées et vers le point de terminaison dont elle a besoin, ce qui garde la politique autonome. Une autre conception utilise une règle antérieure explicite pour le préfixe LAN, ou une route de rejet délibérée qui remet un préfixe à une recherche ultérieure. Chacune est un schéma légitime avec un propriétaire différent. Choisissez selon la politique visée et selon qui maintient les routes, non selon laquelle est plus courte à taper.

Quel que soit le schéma, l’exception doit être visible là où la politique est définie. Une route ajoutée à la main et non consignée disparaîtra au prochain redémarrage et emportera le diagnostic avec elle.

Ne copiez pas la table principale en entier

Copier chaque route de la table principale dans la table de politiques ressemble à un correctif et crée un instantané. Un gestionnaire peut ajouter ou retirer des adresses et des interfaces dynamiquement, et la copie devient obsolète sans que personne ne le remarque. Gardez le cycle de vie des routes chez son propriétaire de configuration et régénérez la table à partir de la configuration plutôt qu’à partir d’un instant.

Une table copiée manque aussi son but, car elle reproduit le comportement de secours que la politique devait encadrer.

Vérifiez les réponses séparément des routes

Une fois que la recherche a choisi le chemin voulu, les réponses peuvent encore échouer pour des raisons sans rapport avec la table. La traduction peut être appliquée sur la mauvaise interface, la validation du chemin inverse peut rejeter un paquet arrivé par un chemin inattendu, ou le point de terminaison peut simplement ne pas répondre. Ce sont des défauts distincts avec des preuves distinctes, et aucun n’est réparé en modifiant des entrées de route.

Conservez la recherche pour ce flux exact des deux côtés du changement, afin que la correction reste visible. Désactiver globalement les contrôles de chemin inverse ou vider des règles n’apporte aucune route manquante et affaiblit des contrôles sans rapport.

Notez la règle, la table, la route gagnante et le chemin de réponse. Cette trace sépare une erreur de politique d’un service défaillant.