AWS Client VPN ou un VPN sur EC2 : un manuel d’exploitation

Les deux options donnent à votre équipe un VPN d’accès distant, donc la question intéressante n’est pas laquelle existe, mais laquelle vous pouvez exploiter. La différence, c’est qui possède le point de terminaison à 3 heures du matin et à quels contrôles vous avez accès quand quelque chose casse. Suivez les cinq étapes ci-dessous dans l’ordre, car chacune peut terminer la comparaison plus tôt. Sauter l’étape d’inventaire, c’est justement comme les équipes finissent par migrer deux fois.

Étape 1 : écrire l’exigence avant la facture

Il vous faut cinq faits sur une page : qui s’authentifie et contre quoi, quelles plateformes clientes doivent fonctionner, quelles destinations privées sont joignables, quelle disponibilité vous avez promise et à quoi le trafic ressemble réellement. Sans cela, chaque comparaison ultérieure tourne au débat sur une liste de fonctionnalités.

Soyez précis sur les destinations. « Accès au VPC » signifie généralement trois choses différentes : le CIDR du VPC, un réseau appairé et une plage locale derrière un Transit Gateway. Un point de terminaison géré atteint les trois, mais chacun a besoin d’une route et d’une règle d’autorisation, et chacun est une ligne distincte dans votre exigence.

Étape 2 : énumérer ce qui tourne déjà

Avant de concevoir quoi que ce soit, listez les points de terminaison existants et tout serveur hébergé sur EC2 avec ses groupes de sécurité. Ces appels sont en lecture seule et sans danger depuis un compte disposant des autorisations describe.

aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpn

Lisez la sortie comme une carte de ce que les clients atteignent déjà. Une règle d’autorisation manquante explique une panne qui ressemble à un problème de routage, et un point de terminaison associé à un seul sous-réseau explique pourquoi une panne de zone a fait tomber tout le service.

Notez aussi les groupes de sécurité attachés à toute instance auto-hébergée. Ces règles font partie du modèle d’accès, et elles sont la première chose qui casse en silence quand quelqu’un reconstruit une instance à partir d’un modèle.

Étape 3 : répartir les responsabilités

Le service géré possède la flotte de points de terminaison, son correctif et sa disponibilité dans la région. Vous possédez l’enrôlement des identités, les règles d’autorisation, les chemins réseau derrière le point de terminaison, la configuration des journaux et la décision du nombre de sous-réseaux à associer.

L’auto-hébergement inverse cela. Vous possédez le système d’exploitation invité, le démon VPN et sa configuration, les certificats et les clés, les sauvegardes, la supervision et la restauration. Le modèle de sécurité d’EC2 place la sécurité de l’invité et de l’application chez le client, et un serveur VPN est un invité comme un autre.

Écrivez la répartition sous forme de tableau avec des noms dans la colonne de droite. Si aucun nom n’apparaît à côté du renouvellement des certificats, c’est le constat, et il compte plus que l’écart horaire.

Étape 4 : comparer avec une charge de travail que vous savez décrire

Le coût suit la forme, pas la taille. Pour l’option gérée, comptez les heures d’association des points de terminaison, les heures de connexion des clients, le transfert et les services d’identité et de journalisation que vous activez. Pour l’auto-hébergement, comptez le calcul, le stockage, le réseau, les licences et le temps d’ingénierie qui maintient le serveur à jour. Mettez les deux jeux de chiffres dans une même feuille avec le même horizon. Une comparaison sur trois ans qui ignore les heures de correctif favorisera toujours le serveur que vous possédez déjà.

Les comparaisons de performance exigent la même discipline. Une session de bureau interactive, un gros transfert et cinquante petites requêtes simultanées sollicitent des parties différentes du chemin : le processeur pour le chiffrement, la capacité réseau de l’instance, la pile propre du client et la destination. Testez avec des clients représentatifs et la même tâche sur les deux conceptions.

Une instance plus grande ne prouve pas qu’un transfert sera plus rapide, et une session réussie n’est pas un plan de capacité. Traitez tout folklore hérité sur les familles d’instances comme une hypothèse à tester, pas comme une règle d’achat.

Étape 5 : basculer avec un retour arrière que vous avez exécuté

Faites tourner les deux points de terminaison en parallèle pendant une période définie, distribuez d’abord le nouveau profil client à un petit groupe et ne touchez pas aux règles d’autorisation de l’ancien point de terminaison tant que le groupe n’a pas utilisé le nouveau pour du vrai travail. Le retour arrière est un changement de profil, pas une reconstruction, alors décidez maintenant où vit l’ancien profil.

Vérifiez dans cet ordre : l’authentification réussit, le client reçoit les routes attendues, une destination autorisée répond et une destination non autorisée échoue, et les journaux montrent les deux événements. Si une étape échoue, arrêtez-vous et corrigez cette étape au lieu de passer au groupe de clients suivant. Notez le résultat de chaque vérification, car une bascule dont on se souvient seulement comme « ça a marché » ne se débogue pas un mois plus tard.

Après la bascule, planifiez les vérifications ennuyeuses : l’expiration des certificats, le nombre d’associations, les règles d’autorisation qui ne correspondent plus à un groupe et le nombre de connexions par rapport à votre attente. Le guide d’administration de Client VPN est la référence pour les éléments de point de terminaison, d’authentification et de routage que vous avez configurés.