LAN derrière une session AWS Client VPN : ce qui est transféré

Le portable se connecte au point de terminaison AWS Client VPN, atteint le sous-réseau privé et tout semble sain. Le poste de travail du même LAN n’atteint rien, alors que l’hôte Linux possède aussi une interface de pont et que les deux machines sont sur le même câble. Rien n’est mal configuré dans le tunnel ; la pièce manquante est le routage, et le pont est une fausse piste.

Étendre une session Client VPN à un LAN est un rôle de passerelle. Ce n’est pas un segment Ethernet étiré dans un service géré.

L’hôte fonctionne et le LAN non

L’interface de tunnel de la machine Linux a une adresse dans le CIDR du client Client VPN, et le point de terminaison a poussé des routes pour les plages du VPC. Une requête faite sur cette machine est du trafic généré localement : elle choisit une route, sort par le tunnel et obtient une réponse. Ce chemin ne touche jamais le code de transfert, l’interface LAN ni aucune règle de pare-feu qui régit le transit.

Le trafic d’un autre appareil du LAN est un flux différent. Il arrive sur l’interface LAN, a besoin d’une route qui pointe vers le tunnel, a besoin du transfert activé, a besoin d’un pare-feu qui l’autorise et a besoin que la réponse revienne par le même hôte. Quatre exigences, et le test réussi sur le portable n’en prouve aucune. Depuis le poste de travail, la panne paraît étrange : le tunnel est monté, les identifiants sont valides, et la destination ne répond tout simplement jamais. Le défaut est local au chemin de transfert de la passerelle, pas au service.

Tous les clients ne peuvent pas être une passerelle

AWS indique que son application de bureau Client VPN ne prend pas en charge le transfert IP, et que d’autres clients pourraient le faire. Cette restriction décide de l’architecture avant qu’aucune commande ne soit tapée. Si le seul client disponible est l’application de bureau officielle, une passerelle Linux qui transfère pour le LAN n’est pas une configuration que vous pouvez terminer, et aucun masquerading n’y changera rien.

Le client de remplacement doit aussi correspondre à la méthode d’authentification du point de terminaison et à la politique que vous comptez appliquer. Les points de terminaison basés sur des certificats, un annuaire et SAML n’acceptent pas les mêmes configurations client, et un client tiers qui s’authentifie mais ignore les routes poussées n’est pas une amélioration.

Traitez le choix du client comme faisant partie de la revue de conception. Il détermine si le modèle de transfert LAN est disponible, et il détermine quelle identité le point de terminaison voit pour chaque appareil derrière la passerelle. Consignez le client et la configuration du point de terminaison contre laquelle il a été testé. Un changement de client six mois plus tard peut retirer silencieusement la capacité que la conception supposait.

Acheminez le LAN vers le tunnel et traduisez-le

Avec un client pris en charge en place, le reste est du travail de passerelle ordinaire. Les appareils du LAN ont besoin d’une route pour la plage du VPC pointant vers l’hôte Linux, et l’hôte a besoin du transfert activé. Si vous voulez que le VPC voie le trafic comme le client connecté et non comme une adresse LAN arbitraire, traduisez la source à la sortie.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Limitez la règle à l’interface de tunnel et à la plage du VPC, comme ci-dessus, plutôt que de masquer tout ce que l’hôte transfère. La règle plus étroite est plus facile à raisonner, et elle ne modifie pas silencieusement un trafic qui devait conserver son adresse source d’origine.

Faites arriver la route du LAN automatiquement si vous pouvez : une option DHCP, une annonce de routeur ou une route statique poussée par ce qui gère le LAN. Une route qui n’existe que sur une machine de test fera paraître la conception cassée au moment où quelqu’un d’autre l’essaie.

La réponse a aussi besoin d’un chemin

Une fois la requête arrivée au VPC, la réponse doit revenir par les mêmes états de traduction et trouver la route du LAN sur la passerelle. Cette partie fonctionne généralement quand la règle de masquerading est en place, parce que la correspondance vit sur l’hôte qui l’a effectuée. Elle casse quand le côté VPC a une route qui envoie la réponse ailleurs, et c’est pourquoi la route du CIDR client et l’association de sous-réseau sur le point de terminaison comptent toutes les deux.

Regardez les compteurs, pas seulement le ping. Une règle de masquerading à zéro paquet vous dit que la requête n’a jamais atteint l’interface de tunnel, ce qui renvoie à la route du LAN ou à la table de routage du client lui-même. Une règle avec des paquets mais sans réponses pointe vers le côté VPC, les règles d’autorisation ou un groupe de sécurité qui n’accepte pas la source traduite. Lisez les deux directions avant de changer quoi que ce soit, car un compteur qui ne croît que d’un côté est un chemin à sens unique, pas un chemin lent.

Rappelez-vous que le point de terminaison est un service géré. Il n’y a aucun fichier de configuration serveur à modifier ni aucune directive client-config à ajouter, donc les instructions écrites pour un serveur OpenVPN auto-géré avec des routes de sous-réseau client personnalisées ne se transposent pas. Sur AWS, les leviers sont l’association de sous-réseau, les règles d’autorisation et les tables de routage du VPC.

L’identité partagée est la partie à laquelle la politique doit répondre

Chaque appareil derrière la passerelle utilise la session VPN de la passerelle. Les règles d’autorisation du point de terminaison accordent l’accès à un utilisateur ou à un groupe, et du point de vue du service il y a exactement un utilisateur sur cette session. Le transfert local ne multiplie pas cette identité en authentification par appareil, et il n’étend pas les contrôles de posture des appareils à l’imprimante du coin.

Cela peut être acceptable, ou cela peut être la raison pour laquelle la conception est rejetée. Cela dépend de ce que les ressources du VPC supposent sur qui appelle. Une identité partagée qui correspond au modèle d’autorisation convient ; une qui transforme silencieusement une session authentifiée unique en accès à tout le LAN est une constatation qui attend d’être rédigée.

Si l’exigence est réellement de connecter tout un site à un VPC, comparez une conception site à site prise en charge avant d’étendre un client d’accès distant. La sémantique diffère, et une session client traduite par NAT est un pauvre substitut d’une liaison de site quand le VPC doit initier des connexions vers le LAN.

Décidez le client, la route, la traduction et l’histoire d’identité dans cet ordre. Chacun contraint le suivant, et l’ordre explique pourquoi l’hôte fonctionne alors que le LAN ne fonctionne pas.