AWS Client VPN en tunnel divisé : quelles routes publier

La console propose un commutateur de tunnel divisé, la décision ressemble donc à une case à cocher. Ce n'est pas le cas. Ce qui parvient réellement au client, c'est l'ensemble de routes publiées du point de terminaison, et cette liste décide quels préfixes privés utilisent le tunnel, si le trafic internet général reste local ou sort par AWS, et quel résolveur le client peut encore joindre. Trois questions tranchent la conception, et chacune peut recevoir une mauvaise réponse alors que la connexion aboutit quand même.

Un indicateur de tunnel divisé n'est pas une liste de destinations

AWS décrit le tunnel divisé comme l'ajout des routes du point de terminaison à la table de routage du client lors de l'établissement de la connexion. Une route vers le VPC privé limite le tunnel à cette destination ; tout le reste suit le chemin habituel du client. Une route par défaut est une instruction différente à l'effet différent, et c'est pourquoi la documentation sur le tunnel divisé déconseille de publier 0.0.0.0/0 sur un point de terminaison configuré pour ce mode : cela casse généralement la connectivité plutôt que de l'étendre. La table de routage du point de terminaison est la politique, et la table de routage du client est le résultat que vous pouvez inspecter.

Lisez ensemble la table de routage du point de terminaison et les routes installées du client. L'étiquette décrit une intention ; les routes décrivent ce qui se passe.

Première décision : le trafic internet général doit-il rester local ?

Si la navigation doit utiliser la connexion propre de l'utilisateur, ne publiez que les destinations privées dont le travail a besoin et arrêtez-vous là. N'ajoutez pas de route internet parce qu'un tutoriel de tunnel complet en incluait une, et ne supposez pas que la route supplémentaire améliore la sécurité. Elle change le chemin, elle n'ajoute pas de politique, et elle coûte généralement une latence que vous n'aviez pas prévue.

Si le trafic internet doit sortir par AWS, construisez l'architecture d'accès internet documentée : route du point de terminaison, règles d'autorisation, le chemin du sous-réseau associé, politique de sécurité et une sortie amont fonctionnelle. Une route par défaut seule n'apporte rien de tout cela.

Deuxième décision : quels préfixes privés, autorisés par qui ?

Publiez le plus petit ensemble de destinations qui sert la charge de travail réelle, et vérifiez que chaque sous-réseau associé peut y router. La cible de route du point de terminaison et le routage VPC du sous-réseau sont des couches différentes, et une route qui existe dans l'une ne prouve rien pour l'autre. L'autorisation est encore autre chose : une destination peut être joignable et néanmoins refusée parce que le groupe du client n'a aucune règle qui l'autorise.

Tester une seule session réussie ne prouve qu'un seul chemin. Vérifiez chaque sous-réseau associé, car une association de sous-réseau ajoutée plus tard est exactement là où se trouve généralement la route manquante.

Lorsqu'une destination doit être joignable par nom, notez que la question suivante est celle de la résolution de noms, pas celle de la route.

Troisième décision : quel résolveur suit le tunnel ?

Un client peut recevoir un serveur DNS joignable uniquement via le VPN, et ce résolveur ne fonctionne que si son adresse se trouve elle-même dans une route autorisée. Vérifiez les deux moitiés : l'adresse du résolveur suit une route publiée, et le serveur répond aux noms que l'application demande. Une requête qui réussit par adresse alors que le nom d'hôte échoue pointe vers le nommage, pas vers le routage, et déboguer le tunnel dans ce cas fait perdre l'après-midi.

Les noms publics devraient se résoudre comme avant la connexion, ce qui est une raison de plus d'être précis sur ce que vous publiez.

Modifiez l'ensemble de routes, puis vérifiez les deux mondes

AWS documente que la modification des routes sur un point de terminaison en tunnel divisé réinitialise les connexions des clients. Planifiez le changement en conséquence : appliquez-le, reconnectez-vous via le client pris en charge et relisez les routes installées au lieu de faire confiance à l'état appliqué avant la modification. Un état appliqué obsolète est la raison la plus fréquente pour laquelle un changement correct semble cassé.

N'acceptez la conception que lorsque une ressource privée et une destination publique se comportent comme prévu, par nom et par adresse, sur les familles d'adresses que vous prenez réellement en charge. Un tunnel qui authentifie n'est pas la même chose qu'un tunnel qui divise correctement.

Écrivez la liste des routes dans le runbook à côté du raisonnement, afin que la personne suivante distingue une exclusion intentionnelle d'une exclusion oubliée.