Rôle Ansible - VPN WireGuard Site-à-Site

Rôle pour déployer des configurations VPN WireGuard Site-à-Site.

Logs Molecule : Court, Complet

Testé sur :

• Debian 11
• Raspbian 11
• Debian 12

Installation

# dernière version
ansible-galaxy role install git+https://github.com/ansibleguy/infra_wireguard

# depuis galaxy
ansible-galaxy install ansibleguy.infra_wireguard

# ou pour un chemin de rôle personnalisé
ansible-galaxy install ansibleguy.infra_wireguard --roles-path ./roles

# installer les dépendances
ansible-galaxy install -r requirements.yml
python3 -m pip install -r requirements.txt

---

Contribuer

N'hésitez pas à :

• Ouvrir des PR

• Lancer des discussions

• Signaler des problèmes => après avoir consulté le guide de dépannage ci-dessous !

---

Utilisation

Vous voulez une interface graphique Ansible simple ? Consultez mon Ansible WebUI

Exemples

Voici quelques exemples de configuration détaillés et leurs résultats :

• Topologie - Unique
• Topologie - Étoile
• Topologie - Maille

Configuration

Vous pouvez définir vos topologies WireGuard qui s'étendent sur plusieurs hôtes ou groupes d'hôtes.

Le rôle filtrera les topologies auxquelles l'hôte cible actuel appartient et configurera celles-ci.

Ces clés de pair doivent correspondre aux noms des hôtes dans votre inventaire Ansible !

wireguard:
  restart_on_change: true  # permet le redémarrage des services wg en cas de changement

  topologies:
    dc_nl:
      type: 'single'
      peers:
        srv02:
          Endpoint: 'srv02.wg.template.ansibleguy.net'
          Address: '10.100.0.1/30'

        srv03:
          Endpoint: 'srv03.wg.template.ansibleguy.net'
          Address: '10.100.0.2/30'

Vous souhaiterez peut-être utiliser 'ansible-vault' pour crypter les fichiers de clé d'hôte :

ansible-vault encrypt roles/ansibleguy.infra_wireguard/files/keys/some_file.key

Exécution

Exécutez le playbook :

ansible-playbook -K -D -i inventory/hosts.yml playbook.yml

Ou si vous avez crypté vos clés :

ansible-playbook -K -D -i inventory/hosts.yml playbook.yml --ask-vault-pass

Il existe également quelques tags utiles disponibles :

• base
• config
• tunnels
• purge

Si vous souhaitez provisionner l'une de vos topologies seulement, vous pouvez définir la variable suivante au moment de l'exécution :

ansible-playbook -K -D -i inventory/hosts.yml playbook.yml -e only_topo=TOPOLOGY_KEY

---

Fonctionnalités

• Installation de paquets

  • WireGuard
  • Resolvconf (résolution de noms)

• Configuration

  • Configuration simplifiée par le mapping de topologies

  • Topologies prises en charge :

    • unique - simplement connecter deux nœuds
    • étoile - plusieurs nœuds de branche se connectent à un hub central
    • maille - connecter chaque pair à chaque autre pair

  • Clés

    • Génération de paires de clés publiques/privées pour chaque hôte dans une topologie (WG identifie le pair par publicKey)
    • Les clés sont écrites dans le contrôleur pour la cohérence

  • Routage

    • Le routage est à vous de gérer ! Vous pouvez activer les routes WG ajoutées automatiquement ou ajouter des scripts personnalisés.

  • Configuration par défaut :

    • Sauvegarde de la clé privée dans un fichier
    • Désactivation de l'ajout automatique de routes (anti-verrouillage et personnalisation)
    • Journalisation syslog activée avec identificateurs d'instance
    • Redémarrage du service wg en cas de changement

  • Options par défaut :

    • Utilisation de PSK pour une sécurité supplémentaire
    • Purge des tunnels orphelins

  • Options non actives par défaut :

    • Installation de 'resolvconf' pour le remplacement de résolution de noms
    • Redirection de trafic (type routeur)

  • Fonctionnalités :

    • Affichage des derniers journaux si le service échoue à redémarrer
    • Connexion automatique des pairs dynamiques

---

Informations

• Remarque : ce rôle ne prend actuellement en charge que les systèmes basés sur Debian.

• Remarque : La plupart des fonctionnalités du rôle peuvent être activées ou désactivées.

  Pour toutes les options disponibles - voir la configuration par défaut située dans le fichier de configuration principal !

• Avertissement : Toutes les configurations/variables que vous fournissez ne seront pas vérifiées pour leur validité. Une mauvaise configuration pourrait casser le rôle !

• Avertissement : Sachez que les scripts up-/down de WireGuard s'exécutent lorsque LE SERVICE DE TUNNEL est actif ; PAS LA CONNEXION DE TUNNEL.

  Vous devez prendre cela en compte lors de la planification/configuration de vos routes et métriques !

• Info : Vous devriez garder vos noms de topologie courts. Et essayez de ne pas utiliser de caractères spéciaux => ils seront supprimés automatiquement (sauf '_=+.-') afin que la clé soit un nom d'interface valide !

• Info : Les interfaces obtiendront un préfixe ajouté : (peut être modifié comme prévu)

  • unique => wgs_
  • étoile => wgx_
  • maille => wgm_

• Info : Comment exécuter des tests est décrit ici

• Info : Les clés d'hôte seront sauvegardées dans le répertoire 'files' du rôle par défaut.

  Ce répertoire de clés peut être changé en utilisant la variable 'controller_key_store' !

• Info : Si vous utilisez des pare-feu OPNSense - vous pouvez utiliser la collection Ansible ansibleguy.opnsense pour gérer ces tunnels WireGuard.

---

Dépannage

Si vous rencontrez des problèmes de connectivité => veuillez suivre ces étapes pour en identifier la source :

1. Le VPN est-il actif ?

wg show all

Si ce n'est pas le cas :

• La connexion ne peut pas être établie - peut-être une mauvaise configuration ou un problème réseau (pare-feu bloquant le trafic)

• Vérifiez vos journaux WireGuard :

  # 'wgs_ts2' est l'interface de tunnel WireGuard dans cet exemple
  guy@srv:~# journalctl -u wg-quick@wgs_ts2
  > -- Le journal commence le Tue 2022-02-08 15:46:07 UTC, se termine le Tue 2022-02-08 17:01:27 UTC. --
  > Feb 08 16:12:31 test-ag-wg-s3 systemd[1]: Démarrage de WireGuard via wg-quick(8) pour wgs_ts2...
  > Feb 08 16:12:31 test-ag-wg-s3 wireguard_wgs_ts2[10698]: [#] ip link add wgs_ts2 type wireguard
  > Feb 08 16:12:31 test-ag-wg-s3 wireguard_wgs_ts2[10698]: [#] wg setconf wgs_ts2 /dev/fd/63
  

  • Voici quelques messages d'erreur courants que vous pourriez voir en cas de mauvaise configuration de vos tunnels :
    • Erreur : RTNETLINK answers: Address already in use
      • Problème : chaque tunnel doit utiliser un port unique à l'écoute - vous avez peut-être assigné un port dupliqué (ou oublié de le définir sur un port personnalisé)
    • Erreur : failure in name resolution
      • Problème : le nom d'hôte dns que le service essaie de contacter n'est pas défini (correctement) ou votre hôte cible a des problèmes généraux de résolution DNS
    • Erreur : Les tunnels sont configurés, les services fonctionnent, mais la connexion n'est pas établie
      • Problème : le port de connexion pourrait être bloqué par un pare-feu

2. Le trafic passe-t-il par le tunnel ?

Pinger l'adresse IP tunnel WireGuard distante - dans la configuration, c'est l' 'Adresse'.

Important : définissez l'adresse IP source à utiliser !

# .2 est l'IP WG distante ; .1 est l'IP locale
ping 10.0.1.2 -I 10.0.1.1

Si ce n'est pas le cas :

• Assurez-vous que le tunnel fonctionne vraiment !

• Vérifiez si les clés correspondent => wg show all doit afficher 'les mêmes' clés publiques des deux côtés :

  guy@srv1:~# wg show all
  > interface: wgx_tx1
  > public key: FJgEWygMdiqRcTvij3PiXOtPJNtTENQkv301l2PGhwY=
  > ...
  

  guy@srv2:~# wg show all
  > ...
  > peer: FJgEWygMdiqRcTvij3PiXOtPJNtTENQkv301l2PGhwY=
  > ...
  

  Pour régénérer des clés non appariées, il suffit de les supprimer du répertoire 'files' du contrôleur et de relancer le rôle sur les serveurs.

3. Le trafic est-il acheminé par le tunnel ?

Cela ne s'applique que aux tunnels utilisés pour connecter des sous-réseaux distants.

Nous le testons avec un autre ping - cette fois en utilisant le sous-réseau local (pas l'IP WG).

# 172.30.1.1 est le 'sous-réseau' distant ; 172.20.0.1 est le local
ping 172.30.1.1 -I 172.20.0.1
# vous pouvez également exécuter un traceroute pour obtenir plus d'informations sur le chemin pris :
traceroute 172.30.1.1

Si vous êtes motivé => vous pouvez exécuter un tcpdump sur l'hôte distant pour découvrir si le trafic passe 'par le tunnel'.

# 'wgs_ts2' est l'interface de tunnel WireGuard dans cet exemple
guy@srv:~# tcpdump -i wgs_ts2
> tcpdump: sortie détaillée supprimée, utilisez -v[v]... pour un décodage complet du protocole
> écoute sur wgs_ts2, type de lien RAW (Raw IP), longueur d'échantillon 262144 octets
> 17:00:07.336550 IP 10.0.1.2 > 10.0.1.1: ICMP echo request, id 38770, seq 1, length 64
> 17:00:07.336695 IP 10.0.1.1 > 10.0.1.2: ICMP echo reply, id 38770, seq 1, length 64

Si ce n'est pas le cas :

• Vérifiez si un pare-feu bloque le trafic entre les hôtes.

  IPTables/NFTables, par exemple, doivent autoriser le trafic entrant ET le transfert de trafic.

• Vérifiez votre configuration de routage pour des erreurs et comparez-la avec la configuration en cours :

  # montrer un aperçu 'simple'
  ip route show all
  # montrer TOUS les routes
  ip route show table all
  # pour supprimer les routes broadcast/local inutiles
  ip route show table all | grep -vE '^(broadcast|local)\s'
  

• Les hôtes doivent supporter le transfert de trafic !

  Assurez-vous que le paramètre 'wireguard.support.traffic_forwarding' est activé.

• Vous avez peut-être oublié d'ajouter le réseau cible aux 'AllowedIPs'.

  Cela est nécessaire pour les topologies étoile et maille !

4. Vous avez toujours des problèmes

Cela pourrait être un problème de rôle ou un bug ou un autre cas particulier => n'hésitez pas à ouvrir un problème sur GitHub !

Veuillez fournir les résultats de dépannage dans le problème.