Quand IPsec tombe, une route de secours n’est pas une politique de repli

Un site perd son tunnel, et la table de routage montre toujours un chemin parfaitement utilisable vers la destination via Internet. Quelqu’un propose de basculer dessus et appelle ce changement une correction de routage. Le paquet pourrait emprunter ce chemin ; la question que personne n’a posée est de savoir s’il est autorisé à arriver sans protection. Ce sont des réponses différentes venant de tables différentes, et les confondre est la façon dont une panne devient un incident.

Deux résultats qui se ressemblent dans une table de routage

La joignabilité dit qu’un paquet a un endroit où aller. Une politique de sécurité dit ce qui doit arriver à ce paquet en chemin, et les deux sont appliqués par des mécanismes différents. Une route peut exister pour un flux que la politique doit écarter, et cette combinaison n’est pas une erreur de configuration. C’est la séparation des deux questions qui rend un plan de panne vérifiable.

Ainsi, un chemin de panne n’est une conception qu’une fois que quelqu’un a décidé lequel des résultats autorisés s’applique. Tant que cette décision n’existe pas, la route de secours est une tentation plutôt qu’un plan.

Le modèle de politique a trois verdicts, pas deux

L’architecture IPsec sépare le trafic qui doit être écarté, le trafic autorisé à contourner la protection et le trafic qui doit être protégé. Ce sont trois instructions distinctes, et celle du milieu est une exemption délibérée, pas un mode de défaillance. C’est les lire par paire qui produit le faux choix entre un tunnel et une route ouverte.

Une association manquante ne promeut pas silencieusement une règle de protection en contournement. La politique dit toujours protéger, donc le paquet attend ou meurt, et ce comportement est le contrôle qui fonctionne comme écrit, pas la preuve que la politique est cassée.

Écrivez l’exigence de votre flux comme l’une de trois phrases : arrêtez-vous jusqu’à ce qu’un chemin protégé existe, basculez vers un autre chemin protégé, ou utilisez un chemin séparément autorisé à fonctionner sans IPsec. Seule la troisième change le contrat de sécurité, et elle a besoin d’un propriétaire qui peut la signer. Cette phrase va dans le registre des changements, pas dans la mémoire de quelqu’un. Les relecteurs approuvent la deuxième phrase et refusent la troisième, et les deux décisions sont raisonnables quand elles sont visibles.

Un contournement est un contrat que les deux extrémités signent

Un chemin alternatif a besoin d’adresses routables, d’une admission explicite là où il arrive et d’un chemin de retour qui fonctionne dans les deux sens. Les adresses privées du site ne deviennent pas joignables parce qu’une route par défaut pointe quelque part.

L’authentification compte autant que l’adressage. Le trafic qui saute le tunnel et arrive à une frontière qui attend une protection est rejeté même lorsqu’il atterrit sur la bonne interface, donc la politique de réception doit accepter cette forme exprès. Une exemption que l’extrémité distante n’a jamais acceptée est une panne avec des étapes en plus.

Retirer un sélecteur ou assouplir une carte pour faire fonctionner le secours n’est pas une exemption maîtrisée. Cela élargit ce qui est exempté, laisse l’extrémité distante appliquer autre chose et peut changer la règle de traduction qui correspond au flux.

La traduction et l’admission changent l’arithmétique

La traduction peut présenter une autre vue des adresses, mais les correspondances aller et retour doivent s’accorder avec le chemin alternatif. Une correspondance unidirectionnelle produit une connexion qui s’ouvre puis se bloque. Une demi-correspondance est pire que rien, car elle ressemble à un progrès.

L’admission est la seconde moitié. Le côté récepteur doit avoir une règle explicite pour ce trafic, sa propre journalisation et un moyen de distinguer à trois heures du matin une exemption approuvée d’une erreur.

La restauration fait partie de la conception

Notez comment la défaillance est détectée, quelle politique choisit le remplacement et ce qu’il advient des sessions qui tournaient quand elle a eu lieu. Une nouvelle connexion peut réussir après la bascule tandis qu’une plus ancienne garde un état lié à une adresse qui ne s’applique plus.

Préférez un autre chemin protégé chaque fois que l’exigence est une protection continue. Là où une exception sans protection est vraiment nécessaire, bornez-la par des sources, des destinations, des services et une durée, et notez comment elle est retirée.

Testez les deux états, pas seulement la panne

L’acceptation couvre le cas du tunnel en échec et celui qui est restauré, avec un contrôle applicatif sur chacun. Le résultat intéressant n’est pas que les paquets ont continué de circuler, mais qu’ils n’ont circulé que sous le contrat choisi par l’organisation.

Ajoutez aussi le test de retrait. Une exception que personne ne peut désactiver est devenue silencieusement une politique permanente, et c’est exactement ce contre quoi la règle d’origine protégeait. Mettez-lui une date d’expiration et un relecteur nommé, sinon l’exemption survivra à tous ceux qui l’ont comprise.