Une règle de domaine VPN casse quand un CDN change ses adresses

Vous copiez l’adresse d’une requête dans votre règle de routage, le site fonctionne, et une semaine plus tard, il ne fonctionne plus. Rien dans la règle n’a changé. Le service a déménagé vers une autre adresse de périphérie, le client a résolu un autre nom d’hôte, ou la session est passée en IPv6. La décision devant vous est de savoir si une règle fondée sur le nom ou une plage explicite est le bon instrument pour ce service, et trois conditions tranchent la question. Ce qui suit sépare le nom de l’adresse, car un seul des deux est stable.

Pourquoi une requête n’est pas un inventaire

Un réseau de diffusion de contenu répond avec une adresse choisie pour le résolveur, la région et le moment. Demandez deux fois depuis des réseaux différents et vous pouvez obtenir des réponses différentes. Demandez une fois et traitez la réponse comme la liste d’adresses du service, et la règle que vous écrivez est un instantané, pas une règle. C’est tout le problème de traiter une réponse DNS comme une configuration.

Il y a une deuxième lacune. Un seul nom d’hôte visible couvre rarement toute l’application, car la connexion, les médias et le trafic API utilisent souvent des noms distincts. Une règle construite à partir du nom d’hôte de la barre d’adresse peut couvrir la page et manquer la vidéo, ce qui se lit comme une défaillance partielle et non comme une erreur de routage.

La troisième lacune est la famille d’adresses. Une règle réservée à v4 ne dit rien de l’enregistrement AAAA que le client peut préférer.

Trois conditions qui décident règle de domaine ou plages

Premièrement, le service publie-t-il un ensemble stable de préfixes que vous pouvez posséder et documenter ? Si oui, les plages explicites sont honnêtes et bon marché. Sinon, une règle de domaine est le seul mécanisme capable de suivre le service.

Deuxièmement, le mécanisme de domaine de votre client se rafraîchit-il ? Une règle qui se résout une fois à la connexion et jamais ensuite est un instantané avec un meilleur habillage. Troisièmement, le mécanisme couvre-t-il les sous-domaines et les deux familles d’adresses, ou seulement les noms que vous avez saisis ?

Répondez à ces trois questions et le choix est généralement évident. Deviner produit une règle qui marche en test et échoue en production.

Testez une session, pas une page

Chargez la page, puis effectuez l’opération qui compte : se connecter, lancer la lecture, envoyer un fichier. Chacune peut joindre un hôte différent, et celle qui échoue est celle que votre règle a manquée.

Énumérez ce que la session contacte réellement plutôt que ce que la page affiche :

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

Gardez le résolveur visible pendant la comparaison, car une règle qui fonctionne depuis un résolveur et échoue depuis un autre vous parle de la réponse du CDN, pas du tunnel. Un TTL court signifie aussi que la réponse que vous avez notée a une durée de conservation.

Ce que chaque mécanisme couvre réellement

Les deux mécanismes semblent interchangeables sur une page de réglages et se comportent différemment en dessous.

Une route d’adresse du noyau fait correspondre des préfixes. Elle n’a aucune idée de ce qu’est un nom d’hôte, donc elle ne peut pas suivre un service qui change d’adresses. Une règle de domaine résout des noms et route le résultat ; elle suit le service mais dépend du résolveur, du comportement de rafraîchissement et de la gestion des sous-domaines par le client, donc une règle qui suit les noms doit être testée avec le résolveur que le client utilise réellement.

Aucune n’est un sur-ensemble de l’autre, c’est pourquoi les mélanger sans note crée de la confusion plus tard.

Revérifiez après un changement du service

Après une mise à jour du client ou un changement du service, relancez le même test de session. Une liste d’adresses qui fonctionnait auparavant est une preuve pour cette période, pas un inventaire permanent de l’infrastructure du service.

Notez quel mécanisme couvre quel nom d’hôte, et la date de la dernière vérification.

Cette note est la différence entre une règle que vous pouvez défendre et une règle que personne n’ose toucher. Si le service publie sa propre liste de préfixes, utilisez-la et citez la date. Sinon, dites-le, et gardez la règle de domaine avec son comportement de rafraîchissement écrit à côté.