Accès intermittent avec AWS Client VPN : auditez chaque sous-réseau associé

Un utilisateur se connecte, ouvre l’application interne et obtient une réponse ; un collègue sur le même point de terminaison reçoit un délai d’attente depuis un ordinateur portable identique sur le même Wi-Fi. Ce schéma est la signature d’un point de terminaison client VPN avec plus d’un sous-réseau associé, où les chemins ne sont pas équivalents. Je déroule cela depuis la console vers l’extérieur, car deux onglets décident si le reste de l’enquête vaut la peine. Rien dans la configuration du client ne l’explique.

Partez du point de terminaison et listez les associations

Dans la console VPC, ouvrez Client VPN endpoints, choisissez le point de terminaison et lisez l’onglet Associations. Chaque association est un sous-réseau dans une zone de disponibilité, et le client atterrit sur celui que le service choisit lors de l’établissement de la connexion. Notez les identifiants de sous-réseau et la table de routage que chacun utilise réellement, car ces deux listes constituent la comparaison que vous allez faire.

Si le point de terminaison n’affiche qu’une seule association, cette théorie est fausse et le client est le meilleur suspect.

Comparez la table de routage du point de terminaison à chaque association

Ouvrez l’onglet Route table sur le même point de terminaison. Chaque CIDR de destination y a une cible, et pour un client VPN la cible est une association et non une passerelle. AWS exige une entrée de destination pour chaque sous-réseau associé, donc une route qui ne cible qu’un seul d’entre eux rend l’accès dépendant de l’endroit où la session a atterri. Vérifiez la destination qui vous intéresse vraiment, puis sa règle d’autorisation, car une route fournit le chemin et une règle décide qui peut l’utiliser.

Une fois les deux couches tabulées, la panne est difficile à manquer.

La deuxième ligne est tout le bogue dans la plupart des tickets. La route du point de terminaison est présente, donc personne ne regarde plus loin, et le paquet meurt un saut plus tard à l’intérieur du VPC.

Suivez chaque sous-réseau jusqu’à sa table de routage effective

Un sous-réseau sans association explicite à une table de routage hérite de la table principale du VPC. Lisez la table réellement en vigueur, pas celle dont le nom semble correct, et comparez destination et cible plutôt que l’étiquette de la ligne.

Le guide AWS sur l’accès intermittent présente cela comme une couverture de routes entre associations, ce qui est le bon modèle. Le point de terminaison amène le paquet à un sous-réseau, et la table de ce sous-réseau doit encore savoir où vit le réseau de l’application.

Corrigez la ligne manquante dans la table qui la possède. Copier une table de routage entière depuis un sous-réseau qui fonctionne copie aussi des choix d’internet, d’appliance et d’isolation qui n’étaient jamais destinés à celui-ci, et cet échange est généralement pire que la panne avec laquelle vous avez commencé.

Vérifiez les règles d’autorisation, puis le chemin de retour

Les règles d’autorisation sont par destination et par groupe, et évaluées séparément des routes. Une destination avec des routes partout mais sans règle pour le groupe de l’utilisateur se comporte comme un trou noir avec une table de routage qui semble saine.

Le chemin de retour mérite la même attention. Une connexion de peering a besoin d’une route dans le VPC de l’application pointant vers le CIDR du client, de règles de groupe de sécurité autorisant le trafic aux deux extrémités, et d’ACL réseau qui ne le rejettent pas. L’accessibilité à sens unique, où ping fonctionne et la poignée de main TCP non, pointe généralement vers une ACL ou un groupe de sécurité plutôt que vers le VPN.

Les groupes de sécurité du point de terminaison lui-même se trouvent sur les interfaces réseau élastiques de l’association, donc une règle autorisant le port de l’application depuis le CIDR du client doit être attachée à l’association, pas seulement à l’instance.

Vérifiez par une reconnexion, pas par une requête chanceuse

Avec un tunnel divisé, les routes du point de terminaison sont poussées lors de l’établissement de la connexion, donc un ensemble de routes modifié n’atteint jamais un client qui reste connecté. Déconnectez-vous et reconnectez-vous via le client pris en charge, puis confirmez que les nouvelles routes sont présentes sur la machine.

Enfin, corrélez le journal des connexions avec l’adresse reçue par le client, et répétez le test assez de fois pour toucher plus d’une association. Une seule requête réussie après une correction prouve qu’un chemin fonctionne, et le ticket portait sur l’autre.