inetdoc.net

Après une trop longue pause dans les publications de ce blog, voici une nouvelle version de l'article VPN site à site IPSec.

Cette fois-ci, l'article est complet avec 3 configurations distinctes et un dépôt Git dédié : vpn-ipsec.

• 3 routeurs Cisco CSR1000v avec le système IOS XE
• 3 routeurs Debian GNU/Linux avec la suite FRRouting
• Le VPN hétérogène avec un système différent à chaque extrémité du tunnel

Cette topologie est une figure académique classique qui ne date pas d'hier. Elle est cependant tout à fait d'actualité dans un contexte de "cloud hybride". La construction des différentes configurations est automatisée avec Ansible.

Côté Debian, j'ai pu évaluer le mode Infrastructure as Code en utilisant cloud.debian.org comme "source de tirage" de l'image .qcow2 de machine virtuelle.

Cette image est fournie avec Systemd-Networkd pour le pilotage des interfaces réseau. Une fois les 3 maquettes validées, on peut faire un bilan plutôt positif du passage à une solution totalement intégrée à systemd de la configuration réseau.

• Les points positifs

  Même si le passage du fichier de configuration unique historique /etc/network/interfaces aux fichiers de descriptions du répertoire /etc/systemd/network/ n'est pas spontané, on s'y fait assez rapidement.

  Pour mimer le contexte des routeurs "constructeurs", j'ai choisi de configurer une interface Out of Band dans un contexte de routage dédié (VRF). C'est un franc succès. Sur le plan pédagogique, ça va permettre de sensibiliser les étudiants en insistant sur le fait que les contextes VRFs ne sont pas un "produit" de tel ou tel fournisseur d'équipements matériels.

• Le point négatif

  La configuration d'un tunnel GRE via Systemd-Networkd n'est pas fonctionnelle dans un contexte hétérogène alors que la configuration manuelle avec la commande ip l'est.

  Il faut bien avouer que la mise en place d'un VPN GRE+IPSec avec deux systèmes différents en vis-à-vis ne doit pas être très courante. Au delà de la seule interface GRE, cette hétérogénéité impose une connaissance "plus fine" des configurations et des protocoles.

  Pour l'instant, j'éviterais de proposer un support de travaux pratiques de ce type aux étudiant•e•s.

Pour conclure, je suis très satisfait du déploiement de Debian en mode Infrastructure as Code et de l'utilisation des outils virt-customize et virt-resize ainsi que de la facilité de configuration de strongSwan.

La configuration IPSec de premier niveau se limite à deux fichiers : /etc/ipsec.secrets et /etc/ipsec.conf. Il faut noter que ces deux fichiers suffisent à la validation du contexte hétérogène. Voir : VPN IPSec site à site - la configuration IPSec. C'est un excellent point que l'on doit pondérer en fonction de la volumétrie de trafic qui doit transiter par le VPN.

Toute dernière remarque sur la forme, l'utilisation de HedgeDoc pour la publication de documents avec des pages multiples n'est pas idéale. Il me reste à tester le mode présentation.

Voilà, pour le moment ...

L'adage veut toujours qu'une antisèche n'ait de valeur que si on la rédige soi-même !

Dans la pratique, les étudiants cherchent toujours des antisèches toutes faites. Voici donc une nouvelle édition de l'antisèche réseau qui reprend les manipulations de base sur la lecture et la configuration d'une interface.

En espérant que cet aide-mémoire facilite la découverte des mystérieux paramètres d'une connexion réseau.

Comme de plus en plus d'images de machines virtuelles de l'hyperviseur KVM utilisent l'EFI à la place du BIOS historique, j'ai ajouté de nouveaux scripts de lancement dans le dépôt GitHub : inetdoc/guides/vm/files/.

Il faut ajouter que Cisco fournit aussi les images de routeurs CSR1000v et de commutateurs Nexus9000v avec un lancement EFI.

Cette nouvelle gestion de l'amorçage système s'appuie sur les fichiers fournis par le paquet ovmf. À chaque lancement de machine virtuelle, un lien symbolique vers le fichier OVMF_CODE.fd est créé dans le répertoire courant. On ajoute à ce lien une copie du fichier OVMF_VARS.fd avec le nom de la machine virtuelle en préfixe.

Le nouveau script ovs-startup-efi.sh décrit deux unités de stockage au format pflash pour chacun des deux fichiers.

Une fois la machine virtuelle lancée, on obtient un montage avec une partition EFI.

$ ./scripts/ovs-startup-efi.sh vm0-debian-testing-amd64-efi.qcow2 4096 0
~> Virtual machine filename   : vm0-debian-testing-amd64-efi.qcow2
~> RAM size                   : 4096MB
~> SPICE VDI port number      : 5900
~> telnet console port number : 2300
~> MAC address                : b8:ad:ca:fe:00:00
~> Switch port interface      : tap0, access mode
~> IPv6 LL address            : fe80::baad:caff:fefe:0%vlan68

$ ssh etu@fe80::baad:caff:fefe:0%vlan68
Warning: Permanently added 'fe80::baad:caff:fefe:0%vlan68' (ED25519) to the list of known hosts.
etu@fe80::baad:caff:fefe:0%vlan68's password:
Linux vm0 5.16.0-1-amd64 #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have no mail.
Last login: Wed Feb 23 09:11:33 2022 from fe80::5449:9fff:fe63:95ba%enp0s1

$ mount | grep efi
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/vda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)