Pointage vers la cloud WireGuard avec les sous-réseaux privés d'AWS
|
Important
|
Traduction d’un article du site Pro Custodibus Le contenu de cette page est la traduction Française de l’article Point to Cloud WireGuard With AWS Private Subnets de Justin Ludwig |
Point to Cloud WireGuard Avec des sous-réseaux privés d’AWS
Cet article explique comment configurer WireGuard pour permettre l’accès distant aux clients à une application web interne, où l’application est située dans un sous-réseau privé d’AWS (Amazon Web Services). C’est une situation courante, décrite en détail dans l’article VPC Avec des sous-réseaux publics et privés (NAT) de la documentation utilisateur AWS.
Dans cet article, nous allons d’abord construire un exemple de réseau virtuel privé cloud (VPC), puis déployer une instance d’hôte serveur WireGuard dans ce VPC (ainsi qu’une instance EC2 web-app exemple). Grâce au serveur WireGuard, nous nous connecterons à partir de notre poste de travail local à une application interne exemple, qui s’exécute dans un sous-réseau privé du VPC. Le diagramme suivant illustre cette situation :
Le serveur WireGuard de cette situation, situé dans le sous-réseau public de la zone de disponibilité (AZ) B du diagramme ci-dessus, permet à votre poste de travail local d’accéder aux sous-réseaux privés du VPC comme si votre poste de travail était physiquement situé au sein du VPC lui-même. Le serveur WireGuard agit en tant qu’hôte bastion (aussi connu sous le nom de serveur relais ou boîte-jump) pour le VPC, fournissant une fonctionnalité similaire à l’hôte bastion dans la structure d’architecture Linux Bastion Hosts sur le Cloud AWS.
L’avantage de l’utilisation d’un serveur WireGuard au lieu d’un hôte Linux générique pour votre bastion est que vous pouvez facilement vous connecter au bastion à partir de tout appareil client qui peut exécuter WireGuard (comme un ordinateur Windows ou un téléphone mobile) — et vous n’êtes pas limité à SSH ; vous pouvez facilement vous connecter à toute application réseau en cours d’exécution sur les serveurs internes de votre VPC. De plus, vous pouvez utiliser les groupes de sécurité AWS pour limiter l’accès du hôte bastion aux applications spécifiques dans le VPC, ainsi que pour utiliser le pare-feu interne du serveur WireGuard lui-même pour personnaliser l’accès par utilisateur.
Nous configurerons le réseau WireGuard dans cet article avec une Topologie Point à Site, où le serveur WireGuard (avec une adresse IP de 10.0.0.2 dans le diagramme ci-dessus) fournit la traduction d’adresse réseau (NAT) au VPC pour les autres pairs du réseau (comme votre poste de travail, avec une adresse IP de 10.0.0.1 dans le diagramme ci-dessus). C’est la méthode la plus simple pour activer l’accès à un VPC, sans nécessiter des modifications de routage au VPC lui-même. Vous pouvez accorder plus d’appareils clients l’accès au VPN WireGuard (Réseau privé virtuel) en ajoutant des pairs supplémentaires à la configuration du serveur WireGuard.
Comme le VPC que nous allons créer pour cet article est simplement un VPC AWS multi-Zone standard avec des sous-réseaux publics et privés, si vous avez déjà configuré un VPC similaire, vous pouvez sauter les cinq premières sections et commencer à la section Créer des groupes de sécurité :
Si vous avez déjà enregistré une paire de clés SSH pour la région AWS où se trouve le VPC, vous pouvez sauter la section Enregistrer un paire de clés SSH ; et si vous exécutez déjà une application interne dans le VPC, vous pouvez sauter la section Démarrer une instance d’application Web.
Notez également que si vos applications internes n’ont pas besoin de passerelles NAT AWS, elles n’auront pas besoin non plus de les utiliser avec WireGuard — dans ce cas, vous pouvez sauter l’étape Créer des passerelles NAT. Je l’ai inclus uniquement parce qu’il fait partie de la référence architecture AWS (permettant à vos applications internes d’accéder à des services arbitraires sur Internet public, comme le “Rando API” hypothétique dans le diagramme ci-dessus).
Créer un VPC
Connectez-vous au console AWS, puis accédez au service VPC (tapez VPC dans la barre de recherche AWS et cliquez sur le résultat “VPC” sous “Services”). Utilisez le menu déroulant région en haut à droite de la page pour sélectionner la région où vous allez créer le VPC. Dans cet exemple, je vais utiliser la région “Ohio” (aka us-east-2).
Dans la barre latérale, cliquez sur le lien Vos VPCs :
Cliquez ensuite sur le bouton Créer un VPC :
Entrez une étiquette Nom ; je l’appellerai my-vpc-01. Entrez un bloc CIDR IPv4 ; j’utiliserai 10.10.0.0/16 pour cet exemple. Pour le bloc CIDR IPv6, si vous prévoyez d’utiliser des adresses IPv6 internes, sélectionnez « Bloc CIDR IPv6 fourni par Amazon » ; sinon, sélectionnez « Aucun bloc CIDR IPv6 » (je ne vais pas utiliser l’IPv6 pour cet exemple).
Toutes les instances de calcul que vous souhaitez exécuter dans le VPC (y compris les instances EC2 que vous créez et gériez, ainsi que toutes les instances créées et gérées automatiquement par AWS en tant qu’partie de ses services, comme pour les bases de données, les équilibreurs de charge, les passerelles, etc.) seront attribuées une adresse IP interne à partir du bloc IPv4, donc assurez-vous de choisir un bloc qui aura suffisamment d’adresses IP disponibles pour tous les services que vous souhaitez exécuter (généralement quelque chose entre un bloc /24 avec 256 adresses potentielles et un bloc /16 avec 65536 adresses potentielles est la taille appropriée).
Assurez-vous également que le bloc IPv4 que vous choisissez ne se chevauche pas avec d’autres blocs IPv4 que vous utilisez internement — et en particulier, assurez-vous qu’il ne se chevauche pas avec les adresses IPv4 que vous utiliserez pour votre VPN WireGuard (dans cet exemple, je vais utiliser le bloc 10.0.0.0/24 pour mon VPN WireGuard). Consultez RFC 6890 pour tous les blocs IPv4 de « Utilisation privée » disponibles.
Cliquez sur le bouton Créer un VPC une fois que vous avez choisi vos blocs d’adresses IP :
Créer des sous-réseaux publics et privés
Pour mon exemple de VPC, je veux utiliser deux zones de disponibilité, us-east-2a et us-east-2b. Par conséquent, je vais créer 4 sous-réseaux : un sous-réseau public pour ma zone A, un sous-réseau privé pour ma zone A, un sous-réseau public pour ma zone B, et un sous-réseau privé pour ma zone B. Je vais attribuer un bloc CIDR IPv4 /24 à chaque sous-réseau et les étiqueter avec des noms comme suit :
| Nom | Type | Zone de disponibilité |
|---|---|---|
public-subnet-a |
Public | us-east-2a |
private-subnet-a |
Privé | us-east-2a |
public-subnet-b |
Public | us-east-2b |
private-subnet-b |
Privé | us-east-2b |
Cliquez sur le bouton Créer un sous-réseau pour chaque sous-réseau que vous souhaitez créer. Entrez les détails appropriés, y compris le nom du sous-réseau, le bloc CIDR IPv4, et la zone de disponibilité.
Répétez ce processus pour chaque sous-réseau que vous avez défini dans le tableau ci-dessus.
| isponibilité | Bloc CIDR IPv4 | ||
|---|---|---|---|
| public-a-my-vpc-01 | public | A | 10.10.10.0/24 |
| private-a-my-vpc-01 | privé | A | 10.10.11.0/24 |
| public-b-my-vpc-01 | public | B | 10.10.20.0/24 |
| private-b-my-vpc-01 | privé | B | 10.10.21.0/24 |
Pour commencer à créer ces sous-réseaux, dans la barre latérale de la console AWS, cliquez sur le lien Sous-réseaux :
Ensuite, cliquez sur le bouton Créer un sous-réseau :
Sélectionnez l’ID de VPC du VPC que vous venez de créer ; le mien est vpc-066dcccf4d8026199 :
Ensuite, entrez une étiquette Nom de sous-réseau, sélectionnez une Zone d’ disponibilité et choisissez un Bloc CIDR IPv4. Cliquez sur le bouton Créer un sous-réseau pour créer le sous-réseau :
Répétez ce processus pour chaque sous-réseau.
Créer une passerelle Internet
Dans AWS, ce qui rend les sous-réseaux publics “publics” est qu’ils ont leur accès à Internet routé via une passerelle Internet AWS (IGW), qui permet de nouvelles connexions entrantes aux instances EC2 dans le sous-réseau depuis l’Internet. Tous les sous-réseaux d’un VPC peuvent partager la même IGW (mais des VPCs distincts ne peuvent pas partager la même IGW), donc je vais créer une seule IGW pour mon exemple de VPC.
Dans la barre latérale de la console AWS, cliquez sur le lien Passerelles Internet :
Ensuite, cliquez sur le bouton Créer une passerelle Internet :
Entrez une étiquette Nom ; j’ai appelée la mienne my-vpc-01-igw. Cliquez sur le bouton Créer une passerelle Internet pour la créer :
Retournez à la page principale des Passerelles Internet, sélectionnez la IGW (dans cet exemple, igw-0718ee0266312bffa) et sélectionnez l’action Attacher au VPC :
Sélectionnez le VPC (dans cet exemple, vpc-066dcccf4d8026199), puis cliquez sur le bouton Attacher la passerelle Internet :
Créer des passerelles NAT
Pour les sous-réseaux privés nécessitant un accès à Internet sortant (par exemple, pour permettre l’installation ou la mise à jour de logiciels à partir de dépôts d’Internet publics), vous devez soit :
- Configurer une passerelle NAT AWS pour le sous-réseau (IPv4 uniquement)
- Configurer une instance NAT personnalisée AWS pour le sous-réseau ou la VPC
- Configurer une passerelle NAT à sortie seule d’Internet AWS pour la VPC (IPv6 uniquement)
Pour cet exemple, je vais créer une passerelle NAT (NGW) pour chacun de mes sous-réseaux privés. Notez que avec le prix actuel des VPC AWS, 2 passerelles NAT dans la région Ohio vous coûteront $65 par mois (plus $0,05/GB pour tous les données transférées à travers elles).
Cependant, notez que cette étape est complètement facultative — si aucune des instances EC2 de vos sous-réseaux privés n’a besoin d’accès à Internet sortant, vous ne devrez pas avoir besoin de passerelles NAT (et vous ne les aurez pas pour WireGuard non plus).
Dans la barre latérale du console AWS, cliquez sur le lien Passerelles NAT :
Ensuite, cliquez sur le bouton Créer une passerelle NAT :
Entrez un Nom pour la NGW ; j’ai nommé la passerelle pour mon sous-réseau privé dans la zone A `private-a-my-vpc-01-
ngw, et celle pour mon sous-réseau privé dans la zone B private-b-my-vpc-01-ngw`. Pour Sous-réseau, sélectionnez le sous-réseau public de la région d’ disponibilité — par exemple, si je veux une NGW à utiliser pour le sous-réseau privé de ma zone A, je devrais en réalité créer la NGW dans le sous-réseau public de la zone A (la passerelle elle-même doit être routable vers Internet publique). Une fois que vous avez sélectionné le sous-réseau correct, cliquez sur le bouton Allouer une adresse IP élastique (ce qui allouera une adresse IP publique fixe pour la NGW à utiliser) :
Cliquez sur le bouton Créer une passerelle NAT :
Répétez ce processus pour les autres sous-réseaux privés.
Créer des tables de routage
Maintenant nous allons diriger l’accès à Internet via la passerelle NAT que nous venons de créer pour les sous-réseaux publics, et les passerelles NAT que nous venons de créer pour les sous-réseaux privés. Nous allons créer une seule table de routage pour tous les sous-réseaux publics combinés, et une table de routage individuelle pour chaque sous-réseau privé, comme suit :
| Nom | Sous-réseaux | Passerelle |
|---|---|---|
| public-routes-my-vpc-01 | public-a-my-vpc-01, public-b-my-vpc-01 | my-vpc-01-igw |
| private-a-routes-my-vpc-01 | private-a-my-vpc-01 | private-a-my-vpc-01-ngw |
| private-b-routes-my-vpc-01 | private-b-my-vpc-01 | private-b-my-vpc-01-ngw |
Dans la barre latérale de navigation de la console AWS, cliquez sur le lien Tables de routage :
Ensuite, cliquez sur le bouton Créer une table de routage :
Entrez un Étiquette Nom, sélectionnez le VPC, puis cliquez sur le bouton Créer :
Répétez ce processus jusqu’à ce que vous ayez une table de routage pour tous les sous-réseaux publics et une pour chaque sous-réseau privé.
Ensuite, retournez à la page principale des Tables de routage, sélectionnez la table de routage publique (public-routes-my-vpc-01 dans mon exemple), cliquez sur l’onglet Routes, puis cliquez sur le bouton Modifier les routes :
Cliquez sur le bouton Ajouter une route pour ajouter une nouvelle ligne. Entrez 0.0.0.0/0 dans le champ Destination, et l’ID de la passerelle NAT dans le champ Cible (le mien est igw-0718ee0266312bffa). Ensuite, cliquez sur le bouton Enregistrer les routes :
Ensuite, cliquez sur l’onglet Associations de sous-réseau de la table de routage publique, puis cliquez sur le bouton Modifier les associations de sous-réseau :
Sélectionnez les sous-réseaux publics ; dans mon exemple, ils sont public-a-my-vpc-01 et public-b-my-vpc-01. Ensuite, cliquez sur le bouton Enregistrer :
Sélectionnez ensuite la table de route privée pour la zone A (private-a-routes-my-vpc-01 dans mon exemple), cliquez sur l’onglet Routes, puis cliquez sur le bouton Modifier les routes :
Cliquez sur le bouton Ajouter une route pour ajouter une autre ligne. Entrez 0.0.0.0/0 dans le champ Destination, et l’ID de la GWN pour la zone A dans le champ Cible (le mien est nat-031f54e5f2013ee25). Ensuite, cliquez sur le bouton Enregistrer les routes :
Sélectionnez ensuite l’onglet Associations de sous-réseau de la même table de route privée pour la zone A et cliquez sur le bouton Modifier les associations de sous-réseau :
Sélectionnez les sous-réseaux privés ; dans mon exemple, ils sont private-a-my-vpc-01 et private-b-my-vpc-01. Ensuite, cliquez sur le bouton Enregistrer :
Créer les groupes de sécurité
Jusqu’à présent, nous n’avons rien fait de spécifique à WireGuard — nous avons simplement créé un VPC AWS standard avec des sous-réseaux publics et privés. Nous allons maintenant créer un groupe de sécurité personnalisé (SG) pour le serveur WireGuard que nous démarrerons dans l’un des sous-réseaux publics, et un groupe de sécurité personnalisé pour l’application interne que nous démarrerons dans l’un des sous-réseaux privés. Le premier SG permettra d’accéder au serveur WireGuard depuis Internet, tandis que le deuxième SG permettra d’accéder à l’application interne depuis le serveur WireGuard (et bloquera tout autre accès).
Alors, dans la barre de navigation gauche de la console AWS, cliquez sur le lien Groupes de sécurité :
Ensuite, cliquez sur le bouton Créer un groupe de sécurité :
Entrez ensuite le Nom du groupe de sécurité ; j’ai appelé ce premier groupe wg-bastion. Entrez une Description, et sélectionnez la VPC (la mienne est vpc-066dcccf4d8026199) :
Cliquez ensuite sur le bouton Ajouter une règle dans la section « Règles entrantes » de la page deux fois pour ajouter deux lignes. Pour la première ligne, sélectionnez SSH pour le Type, et ajoutez 0.0.0.0/0 comme Source. Pour la deuxième ligne, sélectionnez Custom UDP pour le Type, définissez 51820 comme Plage de ports, et ajoutez 0.0.0.0/0 comme Source :
Cela permettra d’accéder à SSH et au WireGuard au serveur WireGuard depuis n’importe où sur Internet. Si vous savez que le serveur WireGuard ne devra être accessible qu’à partir d’une ou plusieurs adresses IP statiques ou de blocs (comme les adresses IP publiques à partir desquelles le trafic de vos bureaux corporatifs sort sur Internet), remplacez ces adresses IP ou blocs par 0.0.0.0/0.
Après avoir fait cela, cliquez sur le bouton Créer un groupe de sécurité en bas de la page :
Retournez à la page principale des Groupes de sécurité et cliquez à nouveau sur le bouton Créer un groupe de sécurité :
Entrez ensuite le nom du groupe de sécurité pour le deuxième groupe ; j’ai appelé le mien access-from-wg-bastion. Entrez une description, et sélectionnez la VPC (la mienne est vpc-066dcccf4d8026199) :
Ensuite, cliquez sur le bouton Ajouter une règle dans la section « Règles entrantes » de la page pour ajouter une ligne. Sélectionnez Tous les trafics pour le Type, et ajoutez le groupe de sécurité wg-bastion (dans mon cas, sg-076543a823999d58d) comme la Source :
Cela permettra d’admettre tous les trafics du serveur WireGuard à notre application interne personnalisée. Si vous savez que vos applications internes n’auront besoin d’exposer qu’un certain nombre de ports spécifiques (comme par exemple les ports TCP 443 ou 8080), au lieu d’autoriser tous les trafics avec une seule règle, ajoutez une règle séparée pour chaque port que vous devez exposer ; et définissez la source de chaque règle sur le même groupe de sécurité wg-bastion.
Pour mon exemple d’application, je devrais en fait exposer uniquement les ports TCP 22 (pour permettre à mon SSH de me connecter à l’instance EC2 exécutant l’application exemple, pour la configurer) et 8080 (utilisé par l’application exemple elle-même). Donc je pourrais configurer les « Règles entrantes » du groupe access-from-wg-bastion comme suit, au lieu de cela :
Quelle que soit la méthode, après avoir ajusté vos règles entrantes en conséquence, cliquez sur le bouton Créer le groupe de sécurité à la bas de la page :
Enregistrer une paire de clés SSH
Naviguez ensuite vers le service EC2 (tapez EC2 dans la barre de recherche AWS et cliquez sur le résultat « EC2 » sous « Services »).
Si vous n’avez pas déjà enregistré une paire de clés SSH à utiliser pour les nouvelles instances lancées dans cette région (us-east-2 dans cet exemple), vous devez le faire maintenant. Dans la barre latérale, cliquez sur le lien Paires de clés :
Ensuite, sélectionnez l’action Importer une paire de clés :
Entrez un Nom pour le paire de clés (je utilise une combinaison de mon nom et du dispositif sur lequel la paire de clés est stockée : justin-j2). Cliquez sur le bouton Parcourir, puis sélectionnez le fichier id_rsa.pub contenant la clé publique du couple de clés SSH que vous utiliserez pour accéder aux nouvelles instances EC2. Ensuite, cliquez sur le bouton Importer la paire de clés :
Démarrage de l’instance du serveur WireGuard
Pour démarrer le serveur WireGuard, dans la barre latérale, cliquez sur le lien Instances :
Ensuite, cliquez sur le bouton Démarrer les instances :
Pour l’image Amazon Linux 2 AMI (HVM), SSD Volume Type, sélectionnez son bouton radio 64-bit (Arm), puis cliquez sur son bouton Sélectionner :
Sélectionnez le type d’instance t4g.nano (de la famille d’instances t4g). Ensuite, cliquez sur le bouton Suivant : Configurer les détails de l’instance :
Sélectionnez le VPC que nous avons créé précédemment (my-vpc-01) pour le réseau, et un sous-réseau public de ce VPC (public-b-my-vpc-01) pour le sous-réseau. Ensuite, sélectionnez Activer pour l’option Attribuer automatiquement une adresse IP publique. Ensuite, cliquez sur le bouton Suivant : Ajouter du stockage :
Sur la page suivante (“Ajouter du stockage”), les paramètres par défaut sont tous corrects, donc cliquez sur le bouton
Suivant : Ajouter des étiquettes
Ajoutez une étiquette Name à cette page, avec la valeur définie sur quelque chose qui vous aidera à identifier le but de l’instance. Pour moi, c’est wireguard-server. Ensuite, cliquez sur le bouton Suivant : Configurer le groupe de sécurité :
Sélectionnez le bouton radio Sélectionner un groupe de sécurité existant, puis choisissez le groupe de sécurité wg-bastion. Ensuite, cliquez sur le bouton Examiner et démarrer :
Sur la page suivante, cliquez sur le bouton Démarrer :
Ensuite, sélectionnez la paire de clés SSH que vous avez enregistrée dans la section précédente (ou qui avait été enregistrée précédemment) ; pour moi, c’est justin-j2. Ensuite, cliquez sur le bouton Démarrer les instances :
Cliquez sur le bouton Afficher les instances sur la page “Statut du démarrage” pour afficher la nouvelle instance EC2 lancée :
Configurer le serveur WireGuard
Jusqu’à ce stade, nous avons simplement lancé une instance EC2 générique exécutant Amazon Linux 2. Nous devons effectuer un changement de configuration sur l’instance EC2 (pour qu’elle puisse agir comme un routeur), et ensuite nous pouvons nous connecter au serveur et installer WireGuard.
Dans la console AWS, sélectionnez la nouvelle instance, puis sélectionnez l’action Modifier le contrôle source/destination à partir du sous-menu Réseau des actions :
Cochez la case Arrêter sur cette page. Ensuite, cliquez sur le bouton Enregistrer :
Cela nous permettra d’utiliser cette instance EC2 pour transférer le trafic à partir de l’extérieur vers d’autres instances EC2 dans le VPC (spécifiquement, les instances exécutant nos applications internes).
Maintenant copiez l’adresse Publique IPv4 de l’instance (18.217.226.255 dans cet exemple) :
Ouvrez un terminal et connectez-vous à l’instance depuis votre poste de travail local (ajoutez le drapeau -i au commande ssh si vous devez spécifier le chemin vers la paire de clés SSH avec laquelle vous avez lancé l’instance) :
justin@jws:~$ ssh ec2-user@18.217.226.255
L'authenticité de l'hôte '18.217.226.255 (18.217.226.255)' ne peut pas être établie.
empreinte numérique de la clé ED25519 est SHA256:Xqy9YXRw4Bt0Ar6n+jlNf+Mb4bhmyq1aKPsKitg8MbE.
Êtes-vous sûr de vouloir continuer à vous connecter (oui/non/[empreinte numérique]) ? oui
Avertissement : l'hôte '18.217.226.255' (ED25519) a été ajouté permanemment à la liste des hôtes connus.
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___
https://aws.amazon.com/amazon-linux-2/
[ec2-user@ip-10-10-20-95 ~]$
Sur le serveur, installez WireGuard. Si le serveur exécute Amazon Linux 2, comme dans cet exemple, suivez les étapes de l’article Installer WireGuard sur Amazon Linux. Sinon, suivez les instructions d’installation de WireGuard pour votre plateforme de serveur choisie.
Une fois que vous avez installé WireGuard, exécutez sudo wg pour vérifier que l’installation a réussi — si elle est réussie, sa sortie initiale sera vide (si ce n’est pas le cas, vous verrez des erreurs) :
$ sudo wg
Maintenant générez une clé WireGuard sur le serveur :
$ wg genkey > server.key
$ wg pubkey < server.key > server.pub
$ cat server.key
ABBBBBBBBBBBBBBBBBBBBBB
$ cat server.pub
fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Et générez également une clé WireGuard sur votre poste de travail local (si vous n’avez pas encore installé WireGuard sur votre poste de travail, faites-le maintenant) :
justin@jws:~$ wg genkey > my-workstation.key
justin@jws:~$ wg pubkey < my-workstation.key > my-workstation.pub
justin@jws:~$ cat my-workstation.key
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
justin@jws:~$ cat my-workstation.pub
/TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
Transférez la clé publique de votre poste de travail local au serveur et la clé publique du serveur à votre poste de travail :
justin@jws:~$ scp my-workstation.pub ec2-user@18.217.226.255:.
justin@jws:~$ scp ec2-user@18.217.226.255:server.pub .
Maintenant créez un nouveau fichier sur le serveur à /etc/wireguard/wg0.conf, et y placez le contenu suivant :
# /etc/wireguard/wg0.conf
# paramètres locaux pour le Serveur WireGuard
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51820
# Transfert d'adresses IP
PreUp = sysctl -w net.ipv4.ip_forward=1
# Masquage d'adresse IP
PreUp = iptables -t mangle -A PREROUTING -i wg0 -j MARK --set-mark 0x30
PreUp = iptables -t nat -A POSTROUTING ! -o wg0 -m mark --mark 0x30 -j MASQUERADE
PostDown = iptables -t mangle -D PREROUTING -i wg0 -j MARK --set-mark 0x30
PostDown = iptables -t nat -D POSTROUTING ! -o wg0 -m mark --mark 0x30 -j MASQUERADE
# Pare-feu local pour les pairs de WireGuard
PreUp = iptables -A INPUT -i wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
PreUp = iptables -A INPUT -i wg0 -j REJECT
PostDown = iptables -D INPUT -i wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
PostDown = iptables -D INPUT -i wg0 -j REJECT
# Pare-feu pour les pairs de WireGuard à partir d'autres hôtes
PreUp = iptables -A FORWARD -o wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
PreUp = iptables -A FORWARD -o wg0 -j REJECT
PostDown = iptables -D FORWARD -o wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
PostDown = iptables -D FORWARD -o wg0 -j REJECT
# Paramètres distants pour la station de travail de Justin
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32
Remplacez la valeur PrivateKey par la clé privée générée sur le serveur (server.key), et la valeur PublicKey par la clé publique générée sur votre station de travail locale (my-workstation.pub).
Pour une explication détaillée de tous les paramètres dans ce fichier, consultez l'article [Configuration Point to Site](/blog/2020/11/wireguard-point-to-site-config/) ("Host β" dans cet article est équivalent au serveur bastion WireGuard de cet article). Les commandes de pare-feu dans ce fichier empêcheront les clients d'utiliser le tunnel WireGuard pour se connecter directement aux autres services sur le serveur, ou à d'autres clients WireGuard que vous ajouterez plus tard (ignorez ces commandes de pare-feu si vous *voulez* permettre un tel accès). Comme nous utilisons les groupes de sécurité AWS pour contrôler l'accès du serveur WireGuard aux autres services dans le VPC, nous n'avons pas besoin d'ajouter de commandes de pare-feu supplémentaires sur le serveur pour contrôler l'accès au trafic WireGuard transféré à partir du serveur vers le VPC.
Activez l'interface wg0 WireGuard que nous venons de configurer en exécutant les commandes suivantes sur le serveur :
```bash
$ sudo systemctl enable wg-quick@wg0.service
$ sudo systemctl start wg-quick@wg0.service
Avec l’interface active, lorsque vous exécutez sudo wg sur le serveur, vous devriez voir la sortie suivante :
$ sudo wg
interface: wg0
public key: fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
private key: (hidden)
listening port: 51820
peer: /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
allowed ips: 10.0.0.1/32
Configurer le client WireGuard
Maintenant, configurez votre poste de travail local pour se connecter au serveur WireGuard.
nnecter au serveur via WireGuard. Créez un nouveau fichier sur votre poste de travail local à /etc/wireguard/my-vpc-01.conf, et placez le contenu suivant dans celui-ci :
# /etc/wireguard/my-vpc-01.conf
# paramètres locaux pour le poste de travail Justin
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32
# paramètres distants pour le serveur WireGuard
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Endpoint = 18.217.226.255:51820
AllowedIPs = 10.10.0.0/16
Remplacez la valeur PrivateKey par la clé privée que vous avez générée sur votre poste local (my-workstation.key), et la valeur PublicKey par la clé publique que vous avez générée sur le serveur (server.pub). Remplacez également la valeur Endpoint par l’adresse IPv4 publique réelle du serveur, et la valeur AllowedIPs par le bloc CIDR IPv4 réel de la VPC.
Activez l’interface my-vpc-01 WireGuard que nous avons configurée sur votre poste local :
justin@jws:~$ sudo systemctl enable wg-quick@my-vpc-01.service
justin@jws:~$ sudo systemctl start wg-quick@my-vpc-01.service
Maintenant, si vous exécutez sudo wg sur votre poste local, elle devrait inclure la sortie suivante :
justin@jws:~$ sudo wg
interface: my-vpc-01
public key: /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
private key: (hidden)
listening port: 56789
peer: fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
endpoint: 18.217.226.255:51820
allowed ips: 10.10.0.0/16
Déploiement de l’Instance d’Application Web
Revenez à la console AWS pour le service EC2, sur la page principale Instances, cliquez sur le bouton Launch instances :
Comme avec le serveur WireGuard, cliquez sur le bouton Select de l’image Amazon Linux 2 AMI (HVM), SSD Volume Type — après avoir sélectionné d’abord le bouton radio 64-bit (Arm) :
Sélectionnez le type t4g.nano (de la famille d’instances t4g). Ensuite, cliquez sur le bouton Next: Configure Instance Details :
Sélectionnez la VPC que nous avons créée précédemment (my-vpc-01) pour le réseau — mais cette fois-ci, sélectionnez l’un de ses sous-réseaux privés (j’ai choisi private-b-my-vpc-01) pour le sous-réseau, et désactivez l’option Auto-assign Public IP. Ensuite, cliquez sur le bouton Next: Add Storage :
Sur la page suivante (“Add Storage”), les valeurs par défaut sont toutes correctes, donc cliquez sur le bouton Next: Add Tags :
Ajoutez une étiquette Name sur la page suivante, avec la valeur définie à quelque chose qui vous aidera à identifier le but de l’instance. Pour moi, c’est internal-application. Ensuite, cliquez sur le bouton Suivant : Configurer le groupe de sécurité :
Sélectionnez la case à cocher Select an existing security group (Sélectionner un groupe de sécurité existant) et choisissez le groupe de sécurité access-from-wg-bastion. Ensuite, cliquez sur le bouton Revoir et lancer :
Sur la page suivante, cliquez sur le bouton Lancer :
Ensuite, sélectionnez la paire de clés SSH que vous avez enregistrée dans la section précédente (ou qui avait été enregistrée précédemment) ; pour moi, c’est justin-j2. Ensuite, cliquez sur le bouton Lancer les instances :
Cliquez sur le bouton Afficher les instances sur la page “Statut d’installation” pour afficher la nouvelle instance EC2 lancée :
 :
Ouvrez un terminal et connectez-vous à l’instance depuis votre poste de travail local (ajoutez le drapeau -i au commande ssh si vous devez spécifier le chemin du paire de clés SSH avec lequel vous avez lancé l’instance) :
justin@jws:~$ ssh ec2-user@10.10.21.130
The authenticity of host '10.10.21.130 (10.10.21.130)' can't be established.
ED25519 key fingerprint is SHA256:jIZRUEvDbNfhyE+ihx400dWKamVmjk2Qf220tsZExLE.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.10.21.130' (ED25519) to the list of known hosts.
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
[ec2-user@ip-10-10-21-130 ~]$
Cette session SSH sera routée via la connexion WireGuard entre mon poste de travail local et le serveur WireGuard que j’ai configuré dans une section précédente, puis depuis ce serveur WireGuard jusqu’à l’instance EC2 interne que je viens de configurer. Ce routage se produit automatiquement car :
- Dans l’interface WireGuard que j’ai configurée pour mon poste de travail local dans la section Configurer le client WireGuard, j’ai défini la valeur
AllowedIPspour le serveur WireGuard sur10.10.0.0/16(un bloc qui contient l’adresse IP de l’application interne, 10.10.21.130). - J’ai activé cette interface avec
wg-quick(via la commandesudo systemctl start wg-quick@my-vpc-01.service), ce qui configure automatiquement les routes sur mon poste de travail pour correspondre à la valeurAllowedIPspour chaque pair de l’interface. - Dans le fichier de configuration
wg0que j’ai configuré pour le serveur WireGuard dans la section Configurer le serveur WireGuard, j’ai utilisé plusieurs commandesPreUp(exécutées parwg-quick) pour configurer le sous-système réseau Linux sur le serveur afin d’autoriser le transfert de trafic réseau et d’appliquer la masquerade (ou NAT) au trafic WireGuard transféré vers le VPC.
Enfin, sur le serveur de l’application interne, exécutez les commandes suivantes pour démarrer l’exemple d’application web (qui fournit les listes de répertoires d’un répertoire fictif via un serveur Web Python en cours d’exécution sur le port 8080) :
$ mkdir -p dummydir && cd dummydir
$ python -m http.server 8080
Pour accéder à l’application interne depuis votre poste de travail local, exécutez cette commande (en utilisant l’adresse IP privée du serveur de l’application interne) :
$ curl 10.10.21.130:8080
Si vous voyez une sortie HTML à partir de cela, votre tunnel WireGuard vers l’application interne fonctionne ! Comme la session SSH ci-dessus, cette requête HTTP sera routée via le tunnel WireGuard entre votre poste de travail local et le serveur WireGuard, puis du serveur WireGuard à travers le réseau interne du VPC jusqu’à l’application interne.
Dépannage du tunnel WireGuard
Si vous essayez de vous connecter à l’application interne comme indiqué ci-dessus, mais que la connexion s’emballe ou que vous recevez une erreur comme « Connexion refusée » ou « Aucun chemin vers l’hôte », exécutez d’abord sudo wg sur votre poste de travail local :
justin@jws:~$ sudo wg
interface: my-vpc-01
public key : /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
private key : (masquée)
listening port : 56789
peer : fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
endpoint : 18.217.226.255:51820
allowed IPs : 10.10.0.0/16
latest handshake : 49 seconds ago
transfer : 20,65 KiB received, 29,90 KiB sent
Vous devriez voir l’interface my-vpc-01 listée (si ce n’est pas le cas, suivez les instructions pour Configurer le client WireGuard ci-dessus).
). Vous devriez également voir des données both sent and received dans le champ de transfert pour la pair du serveur bastion WireGuard.
Si vous ne voyez aucun champ de transfert listé pour la pair, vous avez probablement un problème de routage sur votre poste de travail local. Assurez-vous d’abord que l’adresse IP du serveur interne auquel vous essayez de vous connecter (10.10.21.130 dans cet exemple) est dans les blocs d’adresses IP listés dans le champ adresses IP autorisées. Si ce n’est pas le cas, corrigez votre fichier my-vpc-01.conf pour inclure l’CIDR IPv4 de votre VPC dans la valeur AllowedIPs pour la pair du serveur bastion, puis redémarrez l’interface (via la commande sudo systemctl restart wg-quick@my-vpc-01.service).
Si le champ adresses IP autorisées est bon, essayez d’utiliser la commande ip route pour vérifier le chemin vers l’application interne depuis votre poste de travail. Vous devriez voir quelque chose comme ceci :
justin@jws:~$ ip route get 10.10.21.130
10.10.21.130 dev my-vpc-01 src 10.0.0.1 uid 1000
cache
Si le résultat de la commande indique que l’un autre dispositif que my-vpc-01 sera utilisé, vous devez ajuster les tables de routage sur votre poste de travail.
Sinon, si le champ de transfert pour la pair liste des données envoyées, mais aucune reçue, exécutez sudo wg sur le serveur WireGuard :
$ sudo wg
interface: wg0
public key: fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
private key: (hidden)
listening port: 51820
peer: /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
endpoint: 198.51.100.1:52780
allowed ips: 10.0.0.1/32
latest handshake: 1 minute, 57 seconds ago
transfer: 30.13 KiB received, 20.88 KiB sent
Vous devriez voir l’interface wg0 listée (si ce n’est pas le cas, suivez les instructions pour Configurer le serveur WireGuard ci-dessus). Vous devriez également voir des données envoyées et reçues dans le champ de transfert pour votre pair de poste de travail.
Si vous ne voyez aucun champ de transfert listé, vous avez soit mal configuré la clé privée, la clé publique ou l’option Endpoint sur le client (consultez les instructions pour Configurer le client WireGuard ci-dessus); soit mal configuré la clé privée, la clé publique ou l’option ListenPort sur le serveur (consultez les instructions pour Configurer le serveur WireGuard ci-dessus); soit il y a une configuration de réseau VPC qui bloque le trafic sur le port UDP 51820 depuis votre poste de travail local au serveur WireGuard (voir la section suivante pour dépanner).
Si le champ de transfert montre des données envoyées et reçues, alors le tunnel WireGuard lui-même fonctionne correctement, mais soit le serveur WireGuard ne route pas le trafic interne vers la VPC, soit une configuration de réseau VPC bloque le trafic entre le serveur WireGuard et le serveur d’application. Suivez les étapes de Dépannage de base de l’article de configuration du Point à Site pour vérifier si c’est le premier cas (“Host β” dans cet article est équivalent au serveur bastion WireGuard dans cet article). Sinon, consultez la section suivante.
Dépanner le réseau VPC
Voici quatre domaines à vérifier dans la console AWS si il semble que votre trafic WireGuard soit bloqué par certains équipements de réseau AWS :
Vérification source/destination EC2
L’instance EC2 utilisée par votre bastion WireGuard doit avoir sa vérification source/destination AWS désactivée. Cette option est activée par défaut pour empêcher l’instance de transférer les paquets qu’elle reçoit d’un hôte à un autre.
Pour afficher cette option pour une instance EC2, accédez à la console AWS et allez dans le service EC2. Sélectionnez l’instance en question et cliquez sur “Actions” > “Instance state” > “Change source/destination check”. Assurez-vous que l’option est désactivée.
Si vous rencontrez des problèmes avec cette vérification, consultez la documentation AWS pour plus d’informations sur la vérification source/destination.
ance, sélectionnez l’instance sur la page principale des Instances EC2, puis sélectionnez l’action Modifier la vérification source/destination sous le menu déroulant Réseau :
Pour le bastion WireGuard, la case à cocher Arrêter doit être cochée :
Groupes de sécurité VPC
Les règles d’entrée du groupe de sécurité utilisé par votre bastion WireGuard (wg-bastion dans cet exemple) doivent au moins permettre l’accès au port UDP 51820 (ou ce que vous avez configuré comme valeur ListenPort sur le serveur WireGuard) à partir de l’adresse IP publique de votre poste de travail local. Pour cet exemple, j’ai configuré le groupe de sécurité pour permettre à la fois UDP 51820 et TCP 22 depuis n’importe où (0.0.0.0/0):
(La règle TCP 22 me permet de me connecter directement au serveur WireGuard ; si vous n’en avez pas besoin, vous pouvez l’omettre.)
Les règles de sortie du groupe de sécurité du bastion doivent au moins permettre l’accès à votre serveur d’application interne sur le(s) port(s) que l’application utilise (dans cet exemple, l’application utilise le port TCP 8080 ; et j’ai également utilisé le port TCP 22 pour me connecter au serveur d’application depuis le serveur WireGuard). Cependant, dans cet exemple, je n’ai simplement pas modifié la règle par défaut, qui permet tout le trafic à toutes les destinations :
Les Règles entrantes pour le groupe de sécurité utilisé par votre application interne (access-from-wg-bastion dans cet exemple) doivent au moins inclure l’accès au port utilisé par l’application (TCP 8080 dans cet exemple) à partir du groupe de sécurité bastion (wg-bastion) :
(La règle TCP 22 m’a permis d’accéder au serveur d’application via le serveur WireGuard ; si vous n’en avez pas besoin, vous pouvez l’omettre.)
Les Règles sortantes pour le groupe de sécurité de l’application ne comptent pas (d’un point de vue de WireGuard). Pour cet exemple, j’ai simplement conservé la règle par défaut, qui permet tout le trafic à toutes les destinations — mais vous pourriez la supprimer sans perturber votre accès à l’application via WireGuard (mais notez que, selon votre application, si vous supprimez la règle par défaut, vous pourriez avoir besoin de remplacer celle-ci avec d’autres règles qui permettraient à l’application d’accéder à d’autres services réseau spécifiques, comme les bases de données, les partages de fichiers, les API externes, etc) :
ACL du réseau VPC
Pour cet exemple, j’ai simplement conservé l’ACL du réseau VPC par défaut (NACL) pour tous les sous-réseaux, qui permet tout le trafic entrant et sortant (c’est-à-dire qu’il ne limite pas ce que mes groupes de sécurité autorisent ou interdisent déjà) :
Utiliser les groupes de sécurité au lieu des ACL du réseau pour restreindre le trafic dans un VPC est généralement une approche beaucoup plus maintenable.
Si vous utilisez cependant des ACL, notez que vous aurez besoin d’au moins accorder les règles suivantes (ou des règles qui les subordonnent) aux différents sous-réseaux de votre VPC pour rendre cet exemple fonctionnel ; y compris les règles entrantes suivantes aux sous-réseaux publics de votre VPC (où 198.51.100.1 serait l’adresse IP publique de votre poste de travail, et 10.10.21.130 est l’adresse IP privée de l’application interne) :
| NACL | Type | Protocol | Port range | Source |
|---|---|---|---|---|
| Public Inbound | SSH | TCP | 22 | 198.51.100.1 |
| Public Inbound | Custom UDP | UDP | 51820 | 198.51.100.1 | | Public Inbound | Custom TCP | TCP | 1024-65535 | 10.10.21.130 |
And the following outbound rules to your public subnets:
| NACL | Type | Protocol | Port range | Destination |
|---|---|---|---|---|
| Public Outbound | Custom TCP | TCP | 1024-65535 | 198.51.100.1 |
| Public Outbound | Custom UDP | UDP | 1024-65535 | 198.51.100.1 |
| Public Outbound | Custom TCP | TCP | 8080 | 10.10.21.130 |
And the following inbound rules to your private subnets (where 10.10.20.95 is the private IP address of the WireGuard bastion):
| NACL | Type | Protocol | Port range | Source |
|---|---|---|---|---|
| Private Inbound | SSH | TCP | 22 | 10.10.20.95 |
| Private Inbound | SSH | TCP | 8080 | 10.10.20.95 |
And the following outbound rule to your private subnets:
| NACL | Type | Protocol | Port range | Destination |
|---|---|---|---|---|
| Private Outbound | Custom TCP | TCP | 1024-65535 | 10.10.20.95 |
Tables de routage VPC
Les Routes pour vos sous-réseaux publics doivent envoyer le bloc d’adresses IPv4 complet du sous-réseau VPC localement (10.10.0.0/16 dans cet exemple), et être en mesure de se connecter à votre poste de travail via une passerelle Internet :
Les Routes pour chaque sous-réseau privé doivent également envoyer le bloc d’adresses IPv4 complet du sous-réseau VPC localement (10.10.0.0/16 dans cet exemple). Il n’a pas besoin de pouvoir se connecter à quoi que ce soit d’autre ; mais s’il a une passerelle NAT attachée, sa table de routage ressemblerait à ceci :
Date : 2/2/2021
by Justin Ludwig translated by: Patrice Le Guyader