Comment acheminer le trafic SaaS vers le bon VPN client

Une plateforme SaaS se connecte à une douzaine de réseaux clients, et deux de ces clients utilisent tous deux 10.20.0.10 pour leur base de données principale. Un worker qui reçoit cette adresse dans une tâche n’a aucun moyen de savoir de quelle base de données la tâche parle, et une table de routage partagée l’enverra volontiers vers le tunnel que le préfixe désigne. La solution n’est pas plus de tunnels ; elle consiste à décider où l’identité du locataire entre dans le chemin et quel modèle d’isolation le plan d’adressage exige. Trois conditions tranchent le choix : si les préfixes clients se chevauchent, jusqu’où une erreur peut se propager et qui exploite le connecteur.

Deux bases de données clients, une adresse de destination

Une adresse IP est un emplacement, pas une identité. La requête doit porter un locataire que le serveur a vérifié, et ce locataire doit sélectionner le contexte réseau avant que la destination soit résolue.

Quand ce n’est pas le cas, la défaillance est silencieuse. La connexion réussit, la requête s’exécute et la réponse vient de la base de données du mauvais client parce que la table de routage n’avait qu’une entrée pour 10.20.0.10. Le DNS aggrave les choses : un nom en cache résolu dans le contexte du locataire A peut être réutilisé par une tâche exécutée pour le locataire B. Rien dans le paquet ne distingue les deux, donc aucune logique de nouvelle tentative ne répare cela.

Décidez d’abord du modèle d’isolation

Écrivez les trois conditions avant de comparer des produits. Le chevauchement décide si un espace d’adressage peut être partagé du tout ; le rayon d’impact décide si une erreur de routage est un ticket de support ou une violation ; la propriété opérationnelle décide si vous pouvez exploiter une flotte de connecteurs par locataire.

Si les préfixes sont distincts et que la politique autorise un hub contrôlé, une seule Transit Gateway avec des tables de routage par locataire est viable. L’association d’attachement choisit la table de routage utilisée pour le trafic entrant depuis cet attachement, et la propagation choisit quelles routes apparaissent dans une table. Un attachement de locataire associé uniquement à sa propre table et ne propageant que ses propres préfixes atteint le hub et rien d’autre. C’est une décision de routage, et elle ne reste correcte que tant que personne n’ajoute de route par défaut à la table partagée.

Si les préfixes se chevauchent, le routage seul ne peut pas les séparer. Il vous faut soit un contexte réseau distinct par locataire, soit un plan de traduction qui donne à l’espace de chaque client un sens non ambigu.

Ce que signifie réellement l’isolation Transit Gateway

L’association et la propagation sont les deux réglages qui comptent, et ils sont faciles à confondre. L’association répond dans quelle table un paquet de cet attachement est recherché ; la propagation répond quelles tables apprennent les routes de cet attachement. L’isolation vient du fait de rendre les deux spécifiques au locataire, pas de créer davantage d’attachements.

Une configuration par défaut tous-vers-tous est pratique et n’est pas de l’isolation. Des tables de routage séparées limitent la connectivité, mais elles ne donnent pas deux sens à une même adresse de destination inchangée dans le même contexte de routage. Si l’application résout 10.20.0.10 avant de connaître le locataire, la couche de routage a déjà perdu l’information dont elle aurait besoin.

AWS a ajouté le 23 octobre 2026 le NAT 1:1 au niveau de l’attachement pour Transit Gateway et Cloud WAN, ce qui change la réponse au chevauchement pour les attachements pris en charge. La documentation NAT de Transit Gateway décrit des mappages IPv4 statiques, sans état et à préfixe égal, avec les bits d’hôte préservés. Vérifiez les types d’attachement pris en charge et les contraintes régionales avant de concevoir autour de cela.

Liez la tâche à un locataire vérifié

Chaque tâche doit porter une identité de locataire vérifiée par le serveur, et cette identité doit sélectionner un enregistrement de connexion détenu par l’administrateur. L’enregistrement nomme le contexte réseau approuvé, l’adresse du service, la référence des identifiants et les opérations autorisées. Une requête non fiable ne doit jamais fournir son propre identifiant VPN, sa passerelle ou sa cible privée, car une connexion valide n’est pas une autorisation de sonder l’espace d’adressage de chaque client connecté.

Dans une conception à connecteurs isolés, le travail du locataire A va vers un connecteur spécifique à A qui s’exécute dans le VPC de A et ne peut atteindre que les ressources approuvées de A. Des conteneurs séparés sur un même hôte ne créent pas cette séparation à eux seuls ; les espaces de noms réseau, les routes et la politique de sortie doivent l’implémenter. Le connecteur a aussi besoin d’identifiants et de files d’attente limités au locataire, car une route privée ne limite ni un secret partagé ni un élément de travail partagé. Les workers applicatifs mutualisés conviennent tant que le contexte réseau et les identifiants sont choisis par locataire, et non par hôte.

Les contrôles de santé doivent nommer le locataire et l’étape : tunnel établi, route présente et une véritable requête de service réussie sont trois signaux différents. Un décompte agrégé des tunnels actifs masquera l’unique client dont le connecteur est cassé.

Testez les chemins qui doivent échouer

Exécutez trois tests avant le lancement. Une opération A autorisée doit réussir, une opération B autorisée doit réussir, et une tâche A délibérément dirigée vers le connecteur de B ou son alias traduit doit échouer fermée. Puis coupez un tunnel et confirmez que la tâche échoue uniquement pour ce locataire, sans retomber sur le sous-réseau du même numéro d’un autre client. La restauration doit aussi être testée, car une route obsolète ou des identifiants en cache peuvent survivre à la panne.

L’architecture peut être des workers mutualisés avec des connecteurs isolés, ou des ressources de locataire entièrement séparées. L’invariant est le même : le contexte de locataire vérifié sélectionne la route et les identifiants, et aucun changement de route n’accorde jamais de permission applicative entre locataires.