Routage VPN par domaine ou routes IP : lequel choisir ?

Une route IP correspond à un préfixe d'adresse, et le noyau l'applique sans poser d'autres questions. Une règle VPN par domaine correspond à un nom, ce qui signifie que quelque chose dans la pile doit décider quelles adresses ce nom désigne actuellement et garder cette décision à jour. Ce sont des mécanismes différents, avec des modes de défaillance différents, et les fournisseurs emploient le même mot pour les deux. Les comparer dans des listes de fonctionnalités passe à côté de l'essentiel ; comparez-les sur ce qui se passe quand la réponse change.

La séparation utile est entre une règle qui résout et une règle qui ne résout pas.

Sur quoi chaque règle correspond réellement

Une règle de préfixe correspond aux adresses de destination d'une table de routage. Rien ne se résout, rien n'expire, et la correspondance est exacte pour chaque paquet. Une règle de domaine correspond à la demande d'un nom par une application, que RFC 1034 définit comme un arbre d'étiquettes plutôt qu'une adresse. Certains produits résolvent le nom une fois et installent les adresses obtenues comme routes, ce qui fait de la règle une règle IP assortie d'un minuteur de rafraîchissement.

Sachez laquelle des deux vous avez avant de déboguer, car la panne n'a pas du tout la même allure dans chaque cas.

Où vit la règle de domaine dans la pile

Si le produit met en œuvre les règles de domaine via un proxy local, le trafic doit atteindre ce proxy, et les applications qui ignorent le proxy système contournent entièrement la règle. S'il les met en œuvre en résolvant les noms et en ajoutant des routes, les adresses ne sont fraîches que jusqu'au dernier rafraîchissement. S'il s'accroche au résolveur, le comportement DNS devient une partie de la politique de routage, et un résolveur de secours peut l'annuler en silence.

Lisez le modèle du fournisseur plutôt que l'étiquette du réglage. Deux clients dotés d'une case nommée Split Tunnel peuvent faire trois choses différentes.

Comparez ce qui casse

Trois choses cassent différemment. Rotation des adresses : un nom d'hôte CDN peut se résoudre en un ensemble d'adresses différent en quelques minutes, si bien qu'une liste copiée vieillit mal. Portée des sous-domaines : une règle pour example.com peut couvrir api.example.com ou non, et la documentation est généralement explicite sur ce point. Échec de résolution : quand le résolveur échoue, un client qui résout peut se rabattre sur le tunnelisation du trafic ou sur son envoi direct.

Seule la deuxième est une question de configuration. Les deux autres sont des questions de conception sur ce que le produit accepte de deviner.

Quand le préfixe est la meilleure réponse

Pour un sous-réseau privé stable, un préfixe explicite est plus clair, plus rapide et plus facile à auditer. Il survit aussi à une panne du résolveur, car rien n'a besoin d'être résolu. Recourez à une règle de domaine quand le service est hébergé, quand les adresses tournent ou quand vous ne pouvez vraiment pas énumérer l'ensemble des destinations. N'y recourez pas simplement parce que le nom d'hôte est ce que vous connaissez par hasard.

Une liste statique devinée est le pire des deux : elle a l'air maintenue et rate silencieusement du trafic le jour où le fournisseur ajoute un hôte.

Vérifiez avec une requête fraîche

Testez avec une requête à froid après une reconnexion normale, car une page en cache peut ne jamais toucher la règle. Résolvez le nom, puis vérifiez où la connexion est réellement passée. dig +short app.example.com donne l'ensemble d'adresses actuel, et la liste des connexions du client vous indique quelle interface a porté le flux.

Répétez après l'intervalle de rafraîchissement que documente le produit. Si l'ensemble d'adresses dérive et que la règle ne suit pas, vous avez trouvé le comportement réel.

Gardez aussi la politique du résolveur séparée. Une règle de domaine a besoin de données de nom correctes, mais elle ne décide pas à elle seule quel résolveur répond à la requête.