Pourquoi votre règle de tunnel divisé a cessé de correspondre à un service

Le tunnel divisé échoue généralement de deux façons. Soit le trafic qui devrait passer dans le tunnel le contourne, soit le trafic qui devrait rester dehors est attiré à l’intérieur. La défaillance due à une règle périmée est la première, et c’est la plus déroutante, parce que la règle est appliquée exactement telle qu’elle est écrite. Ce qui a changé, c’est la destination : le service répond désormais sur une adresse que la règle n’a jamais nommée, et rien dans le tunnel n’est en cause.

Ce que la règle fixe et ce que le DNS renvoie

Une règle de tunnel divisé est une affirmation statique sur des destinations, généralement exprimée sous forme de préfixe, de route ou de liste d’adresses. Elle est évaluée contre la destination du paquet au moment de l’envoi. Un nom d’hôte est une requête qui renvoie un ensemble d’adresses avec une durée de vie et un cache, et la réponse peut varier selon le résolveur, le type de requête et la minute.

Ces deux objets ne négocient jamais entre eux. La règle continue de correspondre au préfixe qui lui a été donné, le service continue de changer l’adresse qu’il distribue, et l’écart entre eux s’élargit en silence. C’est pourquoi le symptôme apparaît après une migration de fournisseur ou un renouvellement de certificat plutôt qu’après un changement de configuration. Personne n’a modifié le tunnel, donc personne ne regarde le tunnel, et le diagnostic dérive vers l’application au lieu de la politique.

Trois façons dont la correspondance se casse

Le cas évident est un service déplacé : l’opérateur lui a donné une nouvelle adresse, le DNS a suivi, et l’exception non. Le deuxième est une famille d’adresses que la règle n’a jamais couverte, ce qui arrive quand un nom commence à renvoyer des enregistrements AAAA qu’une exception réservée à IPv4 ignore. Le troisième est une différence de résolveur : une vue interne et une vue publique peuvent renvoyer des adresses différentes pour le même nom, donc l’adresse qu’utilise votre application n’est pas celle avec laquelle vous avez testé.

Une connexion mise en cache est une quatrième variante et elle est facile à manquer. L’application parle peut-être encore à une adresse qu’elle a résolue il y a une heure, ce qui signifie que votre recherche récente et sa socket ouverte ne sont pas d’accord sur l’endroit où vit le service.

Lisez la destination que l’application utilise réellement

Interrogez le système d’exploitation et la table des sockets, pas un onglet de navigateur. La recherche répond à quoi le nom se résout maintenant, et la table des sockets montre l’adresse à laquelle le processus est connecté, qui peut être plus ancienne. Exécutez les deux avant de former une théorie, car la différence entre elles est elle-même la réponse dans environ la moitié des cas.

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

Comparez ensuite avec ce que couvre la règle. Si l’adresse actuelle tombe hors de l’exception et que la requête échoue toujours, vous avez trouvé la cause sans toucher à la configuration du tunnel. Si l’application est connectée à une adresse qui correspond à la règle et que la requête échoue toujours, le problème se situe au-delà du tunnel et ce n’est pas la bonne investigation.

Réparez le mécanisme, pas le symptôme

Si le produit prend en charge un routage maintenu basé sur les domaines, utilisez-le et suivez son comportement documenté de rafraîchissement et de portée. Cela remplace une supposition statique par une réponse maintenue, au prix de dépendre du bon fonctionnement de la fonctionnalité telle que documentée.

Si la conception repose sur une liste statique, donnez-lui un propriétaire et un plan de mise à jour. Ce plan doit indiquer comment l’adresse est découverte, qui approuve le changement et à quelle vitesse la liste est censée suivre une migration de fournisseur. Une liste sans propriétaire est une future panne à la cause connue.

N’élargissez pas l’exception à un grand réseau voisin juste pour attraper chaque adresse vue pendant un test court. Ce n’est pas une correction ; c’est un changement permanent de la frontière de sécurité, et il laissera tranquillement des services sans rapport contourner le tunnel aussi longtemps que la règle existera.

Vérifiez les deux moitiés de l’intention

Une conception de tunnel divisé a deux intentions, et une correction doit préserver les deux. Le service protégé doit passer par le tunnel, et les catégories exclues doivent continuer à le contourner. Testez une nouvelle connexion vers la destination réparée, puis testez quelque chose qui est censé rester dehors.

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

Notez la nouvelle adresse, le mécanisme choisi et la date. Cette note est ce qui empêche la personne suivante de conclure que le VPN a ignoré au hasard sa propre configuration.