WireGuard sur AWS ECS

AWS ECS (Elastic Container Service) est une façon pratique de faire tourner des conteneurs dans le cloud. Et il est facile de faire tourner WireGuard en tant que conteneur sur ECS (avec quelques importantes précautions) — cet article vous montrera comment.

Dans cet article, nous allons exécuter WireGuard comme une tâche ECS qui permet un accès distant “point à cloud” à notre infrastructure AWS interne. Nous utiliserons l’image Pro Custodibus de WireGuard, et la configurerons ainsi que le réseau environnant similairement au scénario d’hôte bastion couvert par l’article Point to Cloud WireGuard Avec des Sous-réseaux Privés AWS :

Cette configuration particulière vous permet, depuis votre poste de travail local, d’accéder aux ressources réseau dans le même AWS VPC (Virtual Private Cloud) que le conteneur WireGuard. Le conteneur WireGuard transfert le trafic de votre poste de travail local vers le VPC, masquant votre trafic comme s’il avait originaire sur l’hôte EC2 du conteneur (dans cet exemple, ayant une adresse IP de 10.10.20.95 dans le VPC).

Avec cette configuration, car le trafic réseau transféré semble provenir de l’hôte EC2, les règles du groupe de sécurité qui s’appliquent à l’hôte EC2 s’appliquent également au trafic transféré. Ainsi, pour permettre à votre poste de travail local d’accéder à une application interne dans le VPC protégée par un certain groupe de sécurité (dans cet exemple, l’application en cours d’exécution sur le port TCP 8080 à l’adresse 10.10.21.130, protégée par le groupe de sécurité sg-0abcdef1234567890), vous devez simplement autoriser l’accès entrant à ce groupe de sécurité depuis l’hôte EC2 du conteneur WireGuard (ou d’un groupe de sécurité utilisé par l’hôte, comme sg-1234567890abcdef0 dans cet exemple).

Préparation de l’Hôte

Lors de la préparation pour exécuter WireGuard sur ECS, gardez à l’esprit ces deux points importants :

1. WireGuard peut être exécuté uniquement avec le type d’instance EC2 (pas sur Fargate).
2. Le module noyau WireGuard doit être présent sur l’hôte EC2 lui-même.

Le module noyau WireGuard fait partie de chaque version du noyau Linux 5.6 et ultérieure, donc si vous gérez vos propres instances ECS conteneurisées et utilisez un noyau relativement moderne, tout est en ordre. Vous pouvez vérifier la version du noyau d’un hôte EC2 en exécutant la commande suivante sur celui-ci :

$ uname -r
5.15.0-1005-aws

Dans l’exemple ci-dessus, nous utilisons Ubuntu 22.04, qui utilise la version du noyau Linux 5.15. Comme la version du noyau est supérieure à 5.6, nous n’avons rien à faire pour cet hôte — il fonctionnera parfaitement les conteneurs WireGuard tels quels.

Cependant, si vous utilisez une version inférieure au noyau Linux 5.6, vous devrez installer manuellement le module du noyau WireGuard sur l’hôte. Cela peut souvent nécessiter la compilation du module du noyau WireGuard à partir des sources sur l’hôte. En particulier, pour Amazon Linux 2 avec une ancienne version de noyau 4.14 en particulier, consultez la section dédiée à elle dans l’article Installer WireGuard sur Amazon Linux.

Déploiement du Conteneur

Tant que l’hôte ECS a le module du noyau WireGuard, le déploiement d’un conteneur WireGuard en tant que tâche ECS sur celui-ci est simple. Cependant, la définition de la tâche doit d’abord être configurée avec la capacité Linux NET_ADMIN ajoutée. Ceci ne peut pas être fait via l’interface utilisateur de la console AWS — vous devez utiliser un outil qui expose les paramètres avancés de la définition de tâche ECS, comme le SDK AWS, ou l’AWS CLI, ou AWS CloudFormation (ou divers autres outils similaires). Nous utiliserons l’AWS CLI dans cet article.

Suivez ces étapes pour déployer l’image de conteneur procustodibus/wireguard en tant que tâche ECS :

1. Configurer le fichier de configuration WireGuard
2. Ajuster vos groupes de sécurité
3. Définir la tâche WireGuard
4. Exécuter la tâche WireGuard
5. Afficher les journaux du conteneur

Configurer le fichier de configuration WireGuard

La méthode la plus simple pour configurer un fichier de configuration WireGuard à utiliser par un conteneur ECS est de le stocker sur un volume AWS EFS (Elastic File System) et de monter ce volume dans le conteneur afin que le fichier de configuration apparaisse dans le répertoire /etc/wireguard du conteneur. Vous pouvez également prendre d’autres approches, comme configurer l’hôte EC2 avec le fichier de configuration sur un volume local et mapper ce volume local dans le conteneur ; ou créer une image personnalisée WireGuard qui récupère la configuration à partir d’une autre source de données (comme le Stockage paramétrique AWS SSM, le Gestionnaire de secrets AWS Secrets Manager, le Stockage Amazon S3, etc) ; mais EFS est la plus simple, donc nous montrerons ici.

Nous allons supposer que vous avez déjà un cluster ECS et un système de fichiers EFS configurés — si ce n’est pas le cas, suivez les quatre premières étapes du tutoriel d’AWS Utiliser des systèmes de fichiers EFS avec Amazon ECS pour les configurer. Dans cet article, nous utiliserons fs-1234567890abcdef0 comme ID de ce système de fichiers EFS.

Avec le système de fichiers EFS configuré, copiez le fichier de configuration WireGuard suivant dans le système de fichiers sous un sous-répertoire dédié à la tâche ECS que nous définirons à l’étape suivante :

# /prod/infra/wg-p2s/conf/wg0.conf

# paramètres locaux pour le conteneur
[Interface]
PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA=
Address = 10.0.0.2/32
ListenPort = 51820

# masquage d'adresses IP
PreUp = iptables -t nat -A POSTROUTING ! -o %i -j MASQUERADE
# pare-feu pour les pairs WireGuard à partir d'autres hôtes
PreUp = iptables -A FORWARD -o %i -m state --state ESTABLISHED,RELATED -j ACCEPT
PreUp = iptables -A FORWARD -o %i -j REJECT

# paramètres distants pour mon poste de travail
[Peer]
PublicKey = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
AllowedIPs = 10.0.0.1/32

Consultez l’article Configuration Point to Site WireGuard pour une explication détaillée de chaque paramètre de configuration WireGuard utilisé ci-dessus.

$ wg genkey > the-container.key
$ wg genkey > my-workstation.key

$ wg pubkey < the-container.key > the-container.pub
$ wg pubkey < my-workstation.key > my-workstation.pub

Dans cet exemple, nous utiliserons /prod/infra/wg-p2s/conf comme répertoire dédié sur le système de fichiers EFS pour ce fichier de configuration WireGuard. Si vous avez le système de fichiers monté à /mnt/efs/fs1 sur une instance EC2 et que vous avez enregistré le fichier ci-dessus localement sur cette instance au chemin ~/wg0.conf, vous pouvez exécuter les commandes suivantes depuis cette instance pour créer le répertoire dédié et copier le fichier de configuration dans celui-ci :

$ sudo mkdir -p /mnt/efs/fs1/prod/infra/wg-p2s/conf
$ sudo cp ~/wg0.conf /mnt/efs/fs1/prod/infra/wg-p2s/conf/.

Ajustez vos groupes de sécurité

Un conteneur WireGuard utilisant le fichier de configuration ci-dessus fournira une connectivité à partir des pairs WireGuard distants vers tout ce que l’instance EC2 qu’il héberge peut accéder, similaire au serveur WireGuard du Point to Cloud WireGuard With AWS Private Subnets article. Comme avec le serveur WireGuard de cet article, nous pouvons utiliser les groupes de sécurité VPC pour contrôler l’accès vers et depuis l’instance EC2 hébergeante.

Au minimum, nous devrons ajouter une règle de groupe de sécurité qui permet un accès entrant au port UDP 51820 de l’hôte EC2, afin d’autoriser les pairs WireGuard distants à se connecter. Si l’hôte EC2 était protégé par un groupe de sécurité avec un ID de sg-1234567890abcdef0, nous pourrions utiliser la commande AWS CLI suivante pour ajouter cette règle :

$ aws ec2 authorize-security-group-ingress \
    --group-id sg-1234567890abcdef0 \
    --protocol udp \
    --port 51820 \
    --cidr 0.0.0.0/0

Nous devons également configurer les règles du groupe de sécurité qui permettront l’accès à partir de l’hôte EC2 du conteneur WireGuard aux autres ressources réseau internes auxquelles nous voulons nous connecter via WireGuard (si ces règles ne sont pas déjà en place). Dans notre scénario d’exemple, nous voulons être en mesure d’accéder à une application web interne qui s’exécute sur le port TCP 8080 sur une autre instance EC2 dans le VPC. Cette autre instance EC2 est protégée par un groupe de sécurité avec l’ID sg-0abcdef1234567890, donc nous exécuterions la commande AWS CLI suivante pour ajouter une règle permettant d’accéder à cette application :

$ aws ec2 authorize-security-group-ingress \
    --group-id sg-0abcdef1234567890 \
    --protocol tcp \
    --port 8080 \
    --source-group sg-1234567890abcdef0

Définir la Tâche WireGuard

Avec le fichier de configuration WireGuard placé sur le système de fichiers EFS et le groupe de sécurité de notre hôte EC2 mis à jour pour permettre l’accès à son port UDP 51820, nous pouvons définir une tâche ECS pour notre conteneur WireGuard avec le JSON suivant :

{
    "family": "wg-p2s",
    "containerDefinitions": [
        {
            "name": "wireguard",
            "image": "procustodibus/wireguard",
            "cpu": 16,
            "memory": 16,
            "portMappings": [
                {
                    "hostPort": 51820,
                    "containerPort": 51820,
                    "protocol": "udp"
                }
            ],
            "mountPoints": [
                {
                    "containerPath": "/etc/wireguard",
                    "sourceVolume": "wireguard-configuration"
                }
            ],
            "linuxParameters": {
                "capabilities": {
                    "add": ["NET_ADMIN"]
                }
            }
        }
    ],
    "volumes": [
        {
            "name": "wireguard-configuration",
            "efsVolumeConfiguration": {
                "fileSystemId": "fs-1234567890abcdef0",
                "rootDirectory": "/prod/infra/wg-p2s/conf"
            }
        }
    ]
}

Passons à cette définition de tâche, paramètre par paramètre :

family

Nom de la tâche. Vous pouvez lui donner le nom que vous souhaitez — il doit être unique dans votre compte AWS.

containerDefinitions.name

Nom du conteneur au sein de la tâche. Vous pouvez lui donner le nom que vous souhaitez — il doit être unique dans cette tâche.

containerDefinitions.image

Nom de l’image WireGuard à télécharger.

containerDefinitions.cpu

Unités de CPU (sur 1024) réservées pour le conteneur. Sauf si vous prévoyez d’envoyer une grande quantité importante de trafic à travers ce conteneur WireGuard, il n’y a pas besoin de réserver beaucoup de unités de CPU.

containerDefinitions.memory

Mois de mémoire réservée pour le conteneur. Le conteneur ECS minimal nécessite environ 6 Mo pour fonctionner ; ce conteneur WireGuard ne nécessite pas beaucoup plus que cela.

containerDefinitions.portMappings.hostPort

Port WireGuard, comme exposé à la VPC. Cela doit correspondre au port Endpoint que vous avez configuré dans votre client WireGuard. (Ou si, au lieu d’autoriser un accès direct à l’hôte EC2, vous allez placer une NLB (Network Load Balancer) devant, comme dans l’article High Availability WireGuard on AWS, cela doit correspondre au paramètre de port du groupe cible du load-balancer.)

containerDefinitions.portMappings.containerPort

Port WireGuard, comme exposé par le conteneur. Cela doit correspondre au ListenPort de la configuration serveur WireGuard que nous avons configurée plus haut.

containerDefinitions.portMappings.protocol

Toujours udp pour WireGuard.

containerDefinitions.mountPoints.containerPath

Mappe le répertoire racine du volume wireguard-configuration (défini dans la section volumes de la définition de tâche) au répertoire /etc/wireguard sur le conteneur. Le répertoire racine du volume wireguard-configuration doit contenir le fichier de configuration WireGuard wg0.conf que nous avons défini ci-dessus.

containerDefinitions.mountPoints.sourceVolume

Nom du volume contenant le fichier de configuration WireGuard. Vous pouvez lui donner n’importe quel nom — il suffit qu’il corresponde au nom défini dans la section volumes.

containerDefinitions.linuxParameters.capabilities.add

Doit inclure NET_ADMIN pour WireGuard. Ce paramètre ne peut pas être configuré via l’interface utilisateur de la console AWS (c’est pourquoi nous devons définir cette tâche en JSON).

volumes.name

Nom du volume contenant le fichier de configuration WireGuard. Vous pouvez lui donner n’importe quel nom — il suffit qu’il corresponde au paramètre containerDefinitions.mountPoints.sourceVolume défini ci-dessus.

volumes.efsVolumeConfiguration.fileSystemId

ID du système de fichiers EFS contenant le fichier de configuration WireGuard.

volumes.efsVolumeConfiguration.rootDirectory

Chemin à partir du racine du système de fichiers EFS vers le répertoire contenant le fichier de configuration WireGuard. Dans la section Configurer le Fichier de Configuration WireGuard ci-dessus, nous avons placé le fichier de configuration dans le répertoire /prod/infra/wg-p2s/conf.

Si vous enregistrez cette définition de tâche JSON sous le nom de fichier wg-p2s.json sur votre poste local, vous pouvez ensuite exécuter la commande AWS CLI suivante à partir du même répertoire pour inscrire la définition de tâche auprès d’AWS :

$ aws ecs register-task-definition --cli-input-json file://wg-p2s.json

Exécutez la Tâche WireGuard

Une fois que la tâche a été enregistrée, nous pouvons l’exécuter sur les hôtes du cluster que nous avons préparés ci-dessus. Si le nom de ce cluster est par exemple prod-infra, nous pouvons exécuter la version 1 de cette tâche avec la commande AWS CLI suivante :

$ aws ecs run-task --cluster prod-infra --task-definition wg-p2s:1

La sortie de cette commande comprendra des informations sur la tâche, y compris le nom complet ARN (Amazon Resource Name) de l’hôte ECS dans lequel la tâche a été lancée (en tant que propriété containerInstanceArn) :

{
    "tasks": [
        {
            "availabilityZone": "us-west-2b",
            "clusterArn": "arn:aws:ecs:us-west-2:012345789012:cluster/prod-infra",
            "containerInstanceArn": "arn:aws:ecs:us-west-2:012345789012:container-instance/prod-infra/18796a629c6c4e9595db03b074bcf34a",
            "containers": [
                {
                    "containerArn": "arn:aws:ecs:us-west-2:012345789012:container/prod-infra/ada8d3f7c14c4dc48556f1a34b745447/99071183-d5d8-458c-8d32-93821079936e",
                    "taskArn": "arn:aws:ecs:us-west-2:012345789012:task/prod-infra/ada8d3f7c14c4dc48556f1a34b745447",
                    "name": "wireguard",
                    "image": "procustodibus/wireguard",
                    "lastStatus": "PENDING",
                    "networkInterfaces": [],
                    "cpu": "16",
                    "memory": "16"
                }
            ],
            ...

Nous pouvons utiliser ce ARN d’instance de conteneur pour rechercher des informations sur l’ID EC2 du hôte :

$ aws ecs describe-container-instances \
    --cluster prod-infra \
    --container-instances arn:aws:ecs:us-west-2:012345789012:container-instance/prod-infra/18796a629c6c4e9595db03b074bcf34a \
    --query containerInstances[].ec2InstanceId \
    --output text
i-0123456789abcdef0

Et avec l’ID EC2 du hôte, nous pouvons rechercher son adresse IP publique :

$ aws ec2 describe-instances \
    --instance-ids i-0123456789abcdef0 \
    --query Reservations[].Instances[].PublicIpAddress \
    --output text
203.0.113.2

Une fois que la tâche est en cours d’exécution, vous pouvez vous connecter au conteneur WireGuard à partir de votre poste de travail avec le fichier de configuration WireGuard suivant :

# /etc/wireguard/wg-prod.conf

# paramètres locaux pour mon poste de travail
[Interface]
PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE=
Address = 10.0.0.1/32

# paramètres distants pour le conteneur WireGuard
[Peer]
PublicKey = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
Endpoint = 203.0.113.2:51820
AllowedIPs = 10.10.0.0/16

Consultez l’article Configuration Point à Site WireGuard pour une explication détaillée de chaque paramètre utilisé dans cette configuration ; mais notez que :

• La PrivateKey utilisée dans ce fichier de configuration doit correspondre à la configuration PublicKey pour un certain pair listé dans le fichier de configuration du conteneur (lorsque vous générez une clé WireGuard pour un client dans cette situation, vous placez la clé privée dans la configuration locale du client et la clé publique dans la configuration distante du conteneur).
• L’Address utilisé dans ce fichier de configuration doit être le même que la configuration AllowedIPs pour le même pair dans le fichier de configuration du conteneur (dans cet exemple, nous avons utilisé 10.0.0.1 pour mon poste de travail).
• La PublicKey utilisée dans ce fichier de configuration doit correspondre à la configuration PrivateKey pour la configuration du conteneur (lorsque vous générez la clé WireGuard pour le serveur, vous placez la clé privée dans la configuration du serveur et copiez la clé publique dans toutes les configurations des clients).
• L’Endpoint utilisé dans ce fichier de configuration doit être l’adresse IP publique (ou entrée DNS publique) de l’hôte EC2 exécutant le conteneur WireGuard, avec le port correspondant au hostPort de la définition de la tâche. (Ou si vous utilisez un NLB, cela doit être l’adresse IP et le port du écouteur NLB.)
• Les AllowedIPs utilisés dans ce fichier de configuration doivent être le bloc CIDR de la VPC dans laquelle le conteneur est en cours d’exécution (ce qui indique au client d’utiliser la connexion WireGuard pour accéder à tout hôte dans la VPC). Si vous souhaitez utiliser la connexion WireGuard pour accéder uniquement à quelques sous-ensembles de cette plage d’adresses, vous pouvez spécifier ces sous-ensembles plutôt que le bloc complet (par exemple, 10.10.20.123/32, 10.10.21.0/24 au lieu du bloc complet 10.10.0.0/16).

Assuming you avez installé WireGuard sur votre poste de travail local, vous pouvez enregistrer le fichier de configuration ci-dessus sous /etc/wireguard/wg-prod.conf, et exécuter la commande suivante sur votre poste de travail pour démarrer la connexion WireGuard avec le conteneur distant :

$ sudo wg-quick up wg-prod

Dans notre exemple de scénario, nous avons une application web en cours d’exécution sur le port 8080 d’une instance EC2, avec une adresse IP de 10.10.21.130 dans le VPC. Elle est protégée par un groupe de sécurité sg-0abcdef1234567890, et comme nous l’avons fait dans la section précédente Ajuster vos groupes de sécurité, nous avons accordé à l’hôte du conteneur l’accès à celui-ci. Ainsi, vous pouvez accéder à cette application web depuis votre poste de travail local simplement en naviguant vers http://10.10.21.130:8080 dans un navigateur ; ou en exécutant la commande cURL suivante :

$ curl 10.10.21.130:8080
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
...

Afficher les journaux du conteneur

Avec la définition de tâche minimale que nous avons configurée dans la section précédente Définir la tâche WireGuard, les journaux du conteneur ne sont disponibles qu’en SSH sur l’hôte du conteneur, et en exécutant la commande suivante (utilisez la commande docker ps pour identifier l’ID du conteneur à utiliser au lieu de 1234567890ab) :

$ sudo docker logs 1234567890ab

 * /proc est déjà monté
 * /run/lock: création de répertoire
 * /run/lock: correction du propriétaire
   OpenRC 0.44.7.88ce4d9bb0 démarre Linux 4.14.275-207.503.amzn2.x86_64 (x86_64) [DOCKER]

* Service dépendances de cache ... [ ok ]
Avertissement : `/etc/wireguard/wg0.conf' est accessible au monde
[#] iptables -t nat -A POSTROUTING ! -o wg0 -j MASQUERADE
[#] iptables -A FORWARD -o wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
[#] iptables -A FORWARD -o wg0 -j REJECT
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.0.0.2 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -4 route add 10.0.0.1/32 dev wg0
 * Démarrage de l'interface WireGuard wg0 ... [ ok ]

Vous devrez peut-être envoyer ces journaux à un service de journalisation centralisé. Si vous utilisez AWS CloudWatch pour les journaux, vous pouvez le faire en ajoutant la configuration logConfiguration suivante à la définition du conteneur WireGuard dans votre fichier JSON de définition de tâche :

{
    "family": "wg-p2s",
    "containerDefinitions": [
        {
            "name": "wireguard",
            ...
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-group": "/prod/infra/wg-p2s",
                    "awslogs-region": "us-west-2",
                    "awslogs-stream-prefix": "ecs"
                }
            }
        }
    ],
    ...
}

Définissez l’option awslogs-group sur le groupe de journaux que vous souhaitez utiliser, l’option awslogs-region sur la région dans laquelle la tâche est définie, et l’option awslogs-stream-prefix sur un préfixe que vous souhaitez. Si vous utilisez un groupe de journaux qui n’a pas encore été créé, assurez-vous de le créer d’abord ; par exemple via cette commande AWS CLI :

$ aws logs create-log-group --log-group-name /prod/infra/wg-p2s

Une fois que vous avez fait cela, vous pourrez “taper” les journaux du conteneur la prochaine fois que vous le démarrerez :

$ aws logs tail /prod/infra/wg-p2s --follow
2022-05-06T00:24:05.055000+00:00 ecs/wireguard/57322a73f6a64d6d8164da05f071bc39  * /proc est déjà monté
2022-05-06T00:24:05.057000+00:00 ecs/wireguard/57322a73f6a64d6d8164da05f071bc39  * /run/lock: création de répertoire
2022-05-06T00:24:05.057000+00:00 ecs/wireguard/57322a73f6a64d6d8164da05f071bc39  * /run/lock: correction de l'owner
2022-05-06T00:24:05.248000+00:00 ecs/wireguard/57322a73f6a64d6d8164da05f071bc39    OpenRC 0.44.7.10dab8bfb7 démarre Linux 4.14.275-207.503.amzn2.x86_64 (x86_64) [DOCKER]
2022-05-06T00:24:05.248000+00:00 ecs/wireguard/57322a73f6a64d6d8164da05f071bc39  * Mise en cache des dépendances de service ... [ ok ]
2022-05-06T00:24:05.344000+00:00 ecs/wireguard/57322a73f6a64d6d8164da05f071bc39 Avertissement : `/etc/wireguard/wg0.conf' est accessible au monde
2022-05-06T00:24:05.349000+00:00 ecs/wireguard/57322a73f6a64d6d8164da05f071bc39 [#] iptables -t nat -A POSTROUTING ! -o wg0 -j MASQUERADE
2022-05-06T00:24:05.351000+00:00 ecs/wireguard/57322a73f6a64d6d8164da05f071bc39 [#] iptables -A FORWARD -o wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
2022-05-06T00:24:05.352000+00:00 ecs/wireguard/57322a73f6a64d6d8164da05f071bc39 [#] iptables -A FORWARD -o wg0 -j REJECT
2022-05-06T00:24:05.576000+00:00 ecs/wireguard/57322a73f6a64d6d8164da05f071bc39 [#] ip link add wg0 type wireguard
2022-05-06T00:24:05.577000+00:00 ecs/wireguard/57322a73f6a64d6d8164da05f071bc39 [#] wg setconf wg0 /dev/fd/63
2022-05-06T00:24:05.578000+00:00 ecs/wireguard/57322a73f6a64d6d8164da05f071bc39 [#] ip -4 address add 10.0.0.2/32 dev wg0
2022-05-06T00:24:05.581000+00:00 ecs/wireguard/57322a73f6a64d6d8164da05f071bc39 [#] ip link set mtu 1420 up dev wg0
2022-05-06T00:24:05.585000+00:00 ecs/wireguard/57322a73f6a64d6d8164da05f071bc39 [#] ip -4 route add 10.0.0.1/32 dev wg0
2022-05-06T00:24:05.586000+00:00 ecs/wireguard/57322a73f6a64d6d8164da05f071bc39  * Démarrage de l'interface WireGuard wg0 ... [ ok ]

Dépannage

Si vous voyez une erreur not supported dans les journaux du conteneur WireGuard lors de son démarrage, comme suit :

[#] ip link add wg0 type wireguard
RTNETLINK answers: Not supported
Unable to access interface: Protocol not supported

Cela signifie que l’hôte n’a pas le module noyau WireGuard installé. Consultez la section Préparation de l’Hôte au début de cet article pour savoir ce faire.

Si vous voyez une erreur operation not permitted dans les journaux du conteneur WireGuard lors de son démarrage, comme suit :

getsockopt failed strangely: Operation not permitted
Unable to access interface: Operation not permitted

Cela signifie que le conteneur n’a pas la permission de configurer une interface WireGuard. Assurez-vous d’avoir accordé au conteneur la capacité Linux NET_ADMIN, comme montré dans la section Définir la Tâche WireGuard.

Si les journaux du conteneur indiquent que l’interface WireGuard a démarré correctement, mais que vous ne pouvez pas accéder à rien dans le VPC du conteneur lorsque vous essayez de connecter le client WireGuard sur votre poste de travail local au conteneur WireGuard, exécutez la commande suivante sur votre poste de travail local pour vérifier l’état de vos interfaces WireGuard :

$ sudo wg
interface: wg-prod
  public key: /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU=
  private key: (hidden)
  listening port: 54918

```plaintext
pair: fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds=
  endpoint: 203.0.113.2:51820
  allowed IPs: 10.10.0.0/16
  latest handshake: 3 minutes, 24 seconds ago
  transfer: 2.21 KiB received, 6.02 KiB sent

Si votre connexion au conteneur WireGuard n’affiche pas une entrée latest handshake, cela signifie que la connexion WireGuard au conteneur n’a jamais été établie. Vérifiez à nouveau :

1. La PrivateKey utilisée dans votre fichier de configuration locale correspond à la configuration PublicKey pour un certain pair listé dans le fichier de configuration du conteneur.
2. L’Address utilisé dans votre fichier de configuration locale est le même que la configuration AllowedIPs pour le même pair dans le fichier de configuration du conteneur.
3. La PublicKey utilisée dans votre fichier de configuration locale correspond à la configuration PrivateKey pour le conteneur.
4. L’Endpoint utilisé dans votre fichier de configuration locale est l’adresse IP publique (ou l’entrée DNS publique) de l’hôte EC2 exécutant le conteneur WireGuard, avec le port correspondant au hostPort de la définition de la tâche. (Ou si vous utilisez un NLB, c’est l’adresse IP et le port du écouteur NLB.)
5. Les groupes de sécurité utilisés par l’hôte EC2 (et le Network ACL de son sous-réseau) permettent un accès entrant à partir de votre adresse IP publique au port UDP correspondant au hostPort de la définition de la tâche. (Ou si vous utilisez un NLB, les groupes de sécurité utilisés par l’hôte EC2 permettent un accès entrant à partir du bloc CIDR complet du VPC au hostPort de la définition de la tâche ; et les groupes de sécurité utilisés par le NLB permettent un accès entrant à partir de votre adresse IP publique au port d’écouteur du NLB.)

Si votre connexion au conteneur WireGuard affiche une entrée latest handshake, cela signifie que la connexion WireGuard au conteneur fonctionne. Vérifiez bien que les groupes de sécurité (et les ACL du réseau) des ressources auxquelles vous essayez de vous connecter autorisent l’accès à partir de l’hôte EC2 du conteneur. Dans la section Configurer le fichier de configuration WireGuard, nous avons configuré le conteneur pour masquer toutes les connexions qu’il transfère depuis le réseau WireGuard — donc le trafic transféré par le conteneur de votre poste de travail au VPC apparaîtra au VPC et à tous les autres services AWS comme s’il provenait directement de l’hôte EC2 du conteneur.

5/9/2022

par Justin Ludwig

• WireGuard
• Cloud
• AWS
• Containers
• Point to Site