Utilisation de WireGuard pour créer un réseau de superposition

Si vous ne souhaitez pas gérer d’infrastructure distincte pour une passerelle API, vous pouvez créer un réseau de superposition entre votre exécuteur et un service de votre réseau privé, en exécutant WireGuard aux deux emplacements.

Cette approche présente divers inconvénients :

Pour atteindre l’instance de WireGuard s’exécutant sur votre service privé, vous avez besoin d’une adresse IP et d’un port bien connus que votre workflow peut référencer : il peut s’agir d’une adresse IP et d’un port publics, d’un mappage de port sur une passerelle réseau ou d’un service qui met à jour dynamiquement le DNS.
Dans la mesure où WireGuard ne prend pas en charge NAT-T (NAT Traversal) par défaut, vous devez identifier un moyen de fournir ce service.
Dans la mesure où cette connexion est de type un-à-un, si vous avez besoin de haute disponibilité ou d’un débit élevé, vous devez la superposer à WireGuard.
Vous devez générer et stocker de manière sécurisée les clés de l’exécuteur et de votre service privé. Dans la mesure où WireGuard utilise le protocole UDP, votre réseau doit prendre en charge le trafic UDP.

Il existe également certains avantages, car vous pouvez exécuter WireGuard sur un serveur existant pour ne pas avoir à gérer d’infrastructure distincte. De plus, il est bien pris en charge sur les exécuteurs hébergés par GitHub.

Exemple : Configuration de WireGuard

Cet exemple de workflow configure WireGuard pour la connexion à un service privé.

Pour cet exemple, l’instance de WireGuard s’exécutant sur le réseau privé présente la configuration suivante :

Adresse IP de réseau de superposition : 192.168.1.1
Adresse IP et port public : 1.2.3.4:56789
Clé publique : examplepubkey1234...

L’instance de WireGuard dans l’exécuteur GitHub Actions présente la configuration suivante :

Adresse IP de réseau de superposition : 192.168.1.2
La clé privée est stockée sous forme de secret GitHub Actions sous WIREGUARD_PRIVATE_KEY

name: WireGuard example

on:
  workflow_dispatch:

jobs:
  wireguard_example:
    runs-on: ubuntu-latest
    steps:
      - run: sudo apt install wireguard

      - run: echo "${{ secrets.WIREGUARD_PRIVATE_KEY }}" > privatekey

      - run: sudo ip link add dev wg0 type wireguard

      - run: sudo ip address add dev wg0 192.168.1.2 peer 192.168.1.1

      - run: sudo wg set wg0 listen-port 48123 private-key privatekey peer examplepubkey1234... allowed-ips 0.0.0.0/0 endpoint 1.2.3.4:56789

      - run: sudo ip link set up dev wg0

      - run: curl -vvv http://192.168.1.1

Pour plus d’informations, consultez Démarrage rapide de WireGuard ainsi que « Utilisation de secrets dans GitHub Actions » afin de découvrir comment stocker les clés de manière sécurisée.

Utilisation de Tailscale pour créer un réseau de superposition

Tailscale est un produit commercial basé sur WireGuard. Cette option est très similaire à celle de WireGuard, à la différence près que Tailscale est une expérience produit plus complète et non un composant open source.

Ses inconvénients sont similaires à ceux de WireGuard : la connexion étant de type un-à-un, vous devrez peut-être effectuer du travail supplémentaire pour obtenir une haute disponibilité ou un débit élevé. Vous devez toujours générer et stocker les clés de manière sécurisée. Le protocole étant toujours UDP, votre réseau doit prendre en charge le trafic UDP.

Toutefois, il existe certains avantages par rapport à WireGuard : NAT-T (NAT Traversal) est intégré, vous n’avez donc pas besoin d’exposer un port au réseau Internet public. Il s’agit de loin de l’option la plus rapide pour être opérationnel, car Tailscale fournit un workflow GitHub Actions d’une seule étape pour se connecter au réseau de superposition.

Pour plus d’informations, consultez Tailscale GitHub Action ainsi que « Utilisation de secrets dans GitHub Actions » afin de découvrir comment stocker les clés de manière sécurisée.

Utilisation de WireGuard pour créer un réseau de superposition

Dans cet article