EC2 Windows : client VPN, serveur VPN ou passerelle AWS ?
Une instance EC2 Windows peut exécuter un logiciel VPN, mais un client, un serveur auto-géré et une passerelle AWS sont des rôles différents avec des propriétaires différents.
Une équipe a besoin d'une connectivité VPN pour une application qui s'exécute sur une instance EC2 Windows, trouve un logiciel client compatible, l'installe, puis demande pourquoi le reste du VPC ne peut pas l'utiliser. L'installation a fonctionné ; le rôle n'a jamais été décidé. Un logiciel exécuté dans un invité peut être un client qui rejoint le réseau de quelqu'un d'autre, un serveur qui accepte d'autres clients, ou aucun des deux produits VPN gérés par AWS, et chaque rôle laisse un travail différent à votre charge.
Le symptôme est généralement le mauvais rôle
Le symptôme courant est un tunnel qui fonctionne et résout le mauvais problème. Un client dans la VM donne à cette VM un chemin sortant ; il ne donne pas à votre ordinateur portable, à votre bureau ou à un autre sous-réseau un moyen d'entrer. Un serveur dans la VM donne aux autres un moyen d'entrer, mais vous possédez désormais l'écouteur, l'authentification et le transfert.
Les services gérés déplacent l'exploitation du service vers AWS et vous laissent la conception. Site-to-Site VPN connecte des réseaux via une passerelle client et une passerelle AWS, et Client VPN donne aux appareils distants un point de terminaison géré. Dans les deux cas, les routes, les règles d'autorisation et la source d'identité relèvent de votre configuration, et aucun des deux produits n'installe un client à usage général dans un invité Windows.
Quatre formes sont possibles, et le tableau les sépare selon ce qui se connecte à quoi et qui porte la charge opérationnelle.
| Role | What connects | Who owns the VPN software |
|---|---|---|
| Client in the Windows VM | This VM dials out into someone else's network | You, plus the software vendor |
| Server in the Windows VM | Inbound clients and sites attach to this VM | You, end to end |
| AWS Site-to-Site VPN | Two networks meet through a customer gateway and an AWS gateway | AWS operates the tunnels; you own the peer and route design |
| AWS Client VPN | User devices attach to an endpoint AWS operates | AWS operates it; you own the access rules |
Lisez la ligne, pas le nom du produit : la même instance Windows peut se trouver dans deux lignes différentes selon le logiciel qui y est exécuté.
Client dans la VM : la VM rejoint un réseau
Un client sortant doit faire vérifier la version de Windows, l'architecture et les exigences de pilotes avant toute installation. Le client modifiera les routes et le DNS de l'instance, ce qui peut affecter des services déjà en cours, y compris le chemin que vous utilisez pour l'administration à distance. Notez le nom de l'adaptateur et la métrique d'interface définie par le client, car la nouvelle interface peut primer sur l'ancienne. Si l'instance est gérée par un gestionnaire de sessions plutôt que par SSH ou RDP, confirmez que ce chemin fonctionne toujours après la connexion du client.
Décidez quel trafic le client doit transporter avant de l'activer. Un tunnel complet peut capturer la session de gestion et vous verrouiller dehors, et un tunnel divisé peut laisser l'instance atteindre le réseau privé pendant que son autre trafic prend une autre sortie. Testez avec un second chemin de gestion disponible, et notez les routes que le client installe pour qu'un changement ultérieur soit explicable.
Serveur dans la VM : d'autres clients le rejoignent
Pour un serveur auto-géré, vous possédez l'écouteur, le certificat ou le matériel de clé, la base d'utilisateurs et les règles de transfert. Si le serveur transfère le trafic d'autres clients, l'instance devient un routeur, et cela exige un transfert au niveau de l'invité plus des changements de routes et de groupes de sécurité au niveau AWS.
Testez l'écouteur depuis l'invité puis depuis un autre sous-réseau, puis testez un hôte pour lequel l'instance transfère. Un service local sain ne prouve rien sur le chemin transféré, alors notez les deux résultats dans la note de changement.
Les passerelles gérées conservent le service, pas votre conception d'accès
AWS Site-to-Site VPN documente les rôles de tunnel de la passerelle client et de la passerelle AWS, et l'achat de cette connexion ne remplace pas toutes les conceptions d'accès à distance. Client VPN documente un point de terminaison géré avec des personas de client, tandis que les règles d'autorisation et les routes cibles restent les vôtres. AWS maintient le point de terminaison et ses certificats en fonctionnement ; qui peut atteindre quelle application reste une règle d'autorisation que vous écrivez et maintenez.
Choisissez entre les produits sur cinq axes : quel rôle chacun joue, quels protocoles il accepte, quelle source d'identité il attend, comment le trafic est transféré et comment la disponibilité est fournie. Ignorez tout chiffre de débit isolé cité dans un fil de forum, car la capacité publiée évolue avec le service. Et ne supposez pas qu'une paire de tunnels gérés change le comportement d'un client invité quelconque.
Choisissez le rôle avant le produit
Écrivez une phrase qui nomme la direction : cette VM rejoint un réseau, cette VM accepte des clients, ou une passerelle AWS relie des réseaux définis.
Cette phrase décide de la liste restreinte de produits, du propriétaire du logiciel et des modes de défaillance que vous allez déboguer. Si l'exigence est que des utilisateurs distants atteignent une application, un client installé dans la VM de l'application est la mauvaise forme. Si l'exigence est qu'une VM atteigne un réseau partenaire, une passerelle site à site gérée est plus de machinerie que la tâche n'en demande. Les deux réponses sont légitimes ; une seule correspond à la phrase que vous avez écrite.