Labo 3 : Network Automation avec Ansible

L’automatisation du déploiement de configuration peut se faire de manière ad-hoc, avec des shell scripts mais est sujette à une maintenance coûteuse : le langage shell script ne connaît qu’un seul type : les chaînes de caractères et aucune structure de données. Dans laboratoire, nous allons mettre en oeuvre l’outil Ansible pour le déploiement automatique et idem-potente de la configuration d’une infrastructure.

Ce laboratoire est divisé en deux parties :

Dans la première partie il s’agira de configurer un petit réseau composé de deux routeurs et deux hôtes avec l’outil ifupdown 1.
La deuxième partie installera un tunnel wireguard entre les deux hôtes et installera un serveur web basé sur nginx disponible uniquement sur l’interface VPN de l’hôte.

1 - Topologie

Téléchargez le labo ansible-simple. Vous devriez obtenir la topologie indiquée en figure Fig. 11. Utilisez votre script écrit dans le labo précédent pour installer l’accès SSH sur les machines et leur donner un hostname correspondant à celui indiqué sur la topologie.

Fig. 11 Topologie pour configuration simple par ansible

A - Commandes ad-hoc

Installez ansible sur votre laptop puis vérifiez que les machines sont bien joignables avec la commande :
```
ansible -m ping -i "H1,H2,R1,R2" all
```
Expliquez ce que fait cette commande ? utilisez la commande ansible-doc pour répondre à la question.
Donner la commande ad-hoc qui permet d’afficher l’uptime de toutes les machines, sans écrire de fichier inventaire. Démontrez que cette commande est correcte en l’exécutant sur la topologie.
Donner la commande ad-hoc qui va créer le fichier /tmp/hello.txt sur toutes les machines. Montrez sa sortie par une capture d’écran.
Quelle est la différente entre les modules command, shell et raw ? Expliquez et donner des exemples.

2 - Routage et adressage

A - Playbook Ansible

Ecrire un playbook qui met en place une configuration persistente des interfaces de H1,H2, R1 et R2 avec les contraintes suivantes :

L’adressage de toutes les interfaces sera statique : iface <ifname> inet static.
Le routage sera statique et seuls H1 et H2 utiliseront une route par défaut vers leur routeur respectif. Les routes seront installées avec la directive post-up de /etc/network/interfaces 1
Les hôtes et les routeurs devront être séparés dans deux groupes dans votre inventaire Ansible : routers et hosts.
Tout changement dans la configuration IP devra redémarrer le service systemd networking, qui est un wrapper au dessus d’ifup/ifdown, vous pouvez le vérifier avec la commande :
```
systemctl cat networking
```
Votre configuration devra être idempotente, autrement dit, si il n’y a pas de changements dans les fichiers de configuration, Ansible ne devra pas les re-écrire, ni redémarrer le service networking.
Votre playbook devra utiliser des variables pour le nom des interfaces, l’adresse IP, le masque et la passerelle par défaut, indiqué dans le champ vars de vos tasks ansible puis générer le fichier /etc/network/interfaces.d sur la base de ces variables à l’aide du module template d’Ansible 2

À quoi servent les options --syntax-check et --check de la commande ansible-playbook ?

B - Vérification du bon fonctionnement

A la fin de cette implémentation, H1 doit pouvoir pinger H2, ce que votre playbook devra vérifier dans une tâche finale.

3 - Tunnel wireguard et serveur web

Cette partie suppose que le playbook écrit dans la partie précédente fonctionne, c’est à dire que le routage et l’adressage des machines est correctement configuré. On se propose maintenant d’installer un tunnel wireguard 5 entre H1 et H2, selon la figure Fig. 12.

A - Playbook

Ecrire un playbook qui met en place la configuration persistente suivante entre H1 et H2 :

H1 et H2 devront être reliés par un tunnel wireguard persistent au démarrage, mais dont les clefs privées sont issus d’une variable de votre playbook.
H2 devra devra faire tourner un serveur web avec nginx et une page générée à partir d’un template Jinja2 issue de votre playbook.
La page web ne sera accessible que sur l’IP du tunnel wireguard.
le playbook ansible sera en charge d’installer les packages debian nginx et wireguard avec le module apt 4 mais ce n’est aps obligatoire, on peut considérer que ces packages ont été installés manuellement.
l’accès Internet pour installer les packages pourra se faire avec la commande dhclient -v mgmt0 qui installe un route par défaut par DHCP.
La configuration du tunnel se basera sur service systemd wg-quick et le fichier de configuration associé 3.
Tout changement des clefs devra re-démarrer le tunnel.

B - Vérification du bon fonctionnement

Une fois le tunnel opérationnel, votre playbook devra utiliser curl pour s’assurer que la page web attendue est bien atteignable sur l’adresse IP du tunnel.

C - Sécurisation

Modifier votre playbook pour que les clefs privées wireguard soient issues d’un vault Ansible 6

1(1,2): https://manpages.debian.org/unstable/ifupdown/interfaces.5.en.html
2: https://docs.ansible.com/ansible/latest/collections/ansible/builtin/template_module.html
3: https://manpages.debian.org/unstable/wireguard-tools/wg-quick.8.en.html
4: https://docs.ansible.com/ansible/latest/collections/ansible/builtin/apt_module.html
5: https://www.wireguard.com/
6: https://docs.ansible.com/ansible/latest/vault_guide/index.html