# Usage
Les fichiers `ifup.sh` et `ifdown.sh` sont des scripts de gestion d'interfaces réseaux pour les conteneurs [Systemd-nspawn](https://doc.ycharbi.fr/index.php/Conteneurs_-_systemd) écrit par mes soins. Supportant les *VLAN* et les *ponts isolés* en *espace de noms réseau* (sans support du *802.1Q* pour ces derniers), ils se bases sur la technologie de [filtrage des *VLAN*](https://doc.ycharbi.fr/index.php/Vlan_-_linux) du noyau *Linux* pour la gestion du *802.1Q*. Les ponts isolés peuvent quant à eux être utilisés pour empêcher la communication des conteneurs au sein d'un même LAN. Cette approche permet une mise en œuvre d'une défense en profondeur dans la communication inter-conteneur.
* *ifup.sh* permet l'attribution d'une interface physique à un conteneur ainsi que la création et le placement d'une interface réseau virtuelle dans un *VLAN* ou dans un tronc *802.1Q*. Il se charge également de l'intégrer à un pont spécifique. Pour les ponts isolés en espace de noms réseau, les *VLAN* ne sont pas supportés. L'existence préalable des ponts et des espaces de noms réseau (si pont isolé) est requise
* *ifdown* se charge de supprimer les interfaces créées par *Systemd-nspawn* après l'extinction du conteneur

Afin qu'ils s'exécutent au démarrage et à l'arrêt d'un conteneur, il faut [modifier](https://philip-trauner.me/blog/post/machinectl-autologin) le service `systemd-nspawn@.service` pour y ajouter les directives adéquates. Notez l'emplacement des scripts dans l'exemple et assurez-vous de leur permission d'exécution :

``` bash
systemctl edit systemd-nspawn@.service
```

Collez-y le contenu suivant. Ceci aura pour effet de créer le fichier `/etc/systemd/system/systemd-nspawn@.service.d/override.conf` qui persistera aux mises à jour du paquet *systemd-container*.

``` ini
[Service]
ExecStartPre=/etc/systemd/nspawn/ifup.sh %i
ExecStopPost=/etc/systemd/nspawn/ifdown.sh %i
```

Si vous voulez revenir en arrière, un `systemctl revert systemd-nspawn@.service` supprimera le fichier de modifications et restaurera l'état initial sans laisser de traces de l'opération précédente.

:bulb: Le traitement des paramètres d'interfaces des conteneurs des fichiers `*.nspawn` s'appuit sur des commentaires spécifiques à placer directement au dessus de chaque directives `Interface=`.

Pour configurer les interfaces réseaux d'un conteneur, il faut :
* Interface **physique** : utiliser la directive `Interface=` de façon [normale](https://www.freedesktop.org/software/systemd/man/systemd.nspawn.html#Interface=) en veillant à ne pas avoir l'une des deux lignes de commentaire dans les deux lignes au dessus de celle-ci
* Interface **virtuelle** : ajouter deux lignes de commentaires **au dessus** de chaque directive `Interface=` dans le [fichier de configuration](https://doc.ycharbi.fr/index.php/Conteneurs_-_systemd#Fichier_de_configuration) de celui-ci

Pour une interface physique :

``` ini
Interface=nomIfacePhy
```

Pour une interface non étiqueté (mode *access*) :

``` ini
#PONT=votrePont
#VLAN=vid
Interface=nomIfaceVirt_vid
```

Pour une interface de tronc 802.1Q (mode *trunk*) :
``` ini
#PONT=votrePont
#8021Q=vid1,vi2,vid3
Interface=nomIfaceVirt_vid
```

Pour une interface en pont isolé :
``` ini
#PONT=votrePont
#ISOLE=votreEspaceDeNomsRéseau
Interface=nomIfaceVirt
```

Il est possible de mixer les notions au travers de plusieurs interfaces comme dans l'exemple suivant (fichier `/etc/systemd/nspawn/web.nspawn`) :
``` ini
[Network]
#PONT=br0
#VLAN=100
Interface=web_100
#PONT=br0
#VLAN=121
Interface=web_121
#PONT=br0
#8021Q=5,210
Interface=web_T1

Interface=eth2
#PONT=br1
#8021Q=181,1109
Interface=web_T2
#PONT=br-netns135
#ISOLE=netns135
Interface=nxtcld
```

Le script vérifie que ce que vous avez renseigné est valide. S'il rencontre la moindre erreur, il s'interrompt sans modifier le système et vous oriente sur le problème. En utilisation avec un conteneur, les messages de retour du script sont visibles dans le journal du service via `systemctl status systemd-nspawn@votreConteneur.service` ou `journalctl -xe`.

:warning: *J'attire votre attention sur le fait que l'ajout, en cours de fonctionnement, de directives `Interface=` dans le ficher de configuration de votre conteneur a pour effet de neutraliser l'exécution de `ifdown.sh`. Ceci est intrinsèque à la façon dont il fonctionne. Les interfaces créées par `ifup.sh` devront alors êtres supprimées manuellement.*

# Environnement
Toute référence à un pont ou à un espace de noms réseau suppose son existence préalable. Cette section propose un exemple de configuration réseau pour un système *GNU/Linux Debian* mettant en œuvre un pont avec filtrage de *VLAN* ainsi qu'un *pont isolé* en *espace de noms réseau*. Il conviendra d'en adapter les valeurs pour coller avec votre besoin.

Fichier `/etc/network/interfaces` :
```
auto lo
iface lo inet loopback
	up /usr/local/sbin/confint
```

Fichier `/usr/local/sbin/confint` :
```bash
#!/bin/bash
# Script de configuration des interfaces réseau

nom_pont="br0"
nom_iface1="ens3"

# La MTU peut être passée à 9000 pour l'activation des trames géantes (adapter cette valeur dans le script le cas échéant)
ip link set "${nom_iface1}" mtu 1500
ip link set "${nom_iface1}" up

# Création du pont supportant le 802.1Q
ip link add "${nom_pont}" type bridge vlan_filtering 1
ip link set "${nom_pont}" up

# Ajout de l'interface physique au pont
ip link set "${nom_iface1}" master "${nom_pont}"

# Désactivation du VLAN par défaut sur le pont afin de l'isoler
bridge vlan del dev "${nom_pont}" vid 1 self
bridge vlan del dev "${nom_iface1}" vid 1 master

# VLAN
id_vlan="10"
nom_svi="vlan${id_vlan}"
ip_svi="192.168."${id_vlan}".1/24"
ip link add link "${nom_pont}" name vlan"${id_vlan}" type vlan id "${id_vlan}"
ip link set "${nom_svi}" up
ip address add "${ip_svi}" dev "${nom_svi}"
bridge vlan add dev "${nom_iface1}" vid "${id_vlan}" tagged master
bridge vlan add dev "${nom_pont}" vid "${id_vlan}" tagged self

id_vlan="20"
nom_svi="vlan${id_vlan}"
ip_svi="192.168."${id_vlan}".1/24"
ip link add link "${nom_pont}" name vlan"${id_vlan}" type vlan id "${id_vlan}"
ip link set "${nom_svi}" up
ip address add "${ip_svi}" dev "${nom_svi}"
bridge vlan add dev "${nom_iface1}" vid "${id_vlan}" tagged master
bridge vlan add dev "${nom_pont}" vid "${id_vlan}" tagged self

# Routage
ip route add default via 192.168.10.254 dev vlan10 onlink

# Pont isolé 135
id_rzo="135"
nom_netns="netns${id_rzo}"
nom_pont="br-netns${id_rzo}"
nom_veth="veth${id_rzo}"
ipv4_veth="10.1.${id_rzo}.254/24"
ip netns add "${nom_netns}"
ip netns exec "${nom_netns}" ip link add "${nom_pont}" type bridge stp_state 0
ip link add ${nom_veth} type veth peer name ${nom_veth}_h
ip link set netns "${nom_netns}" dev ${nom_veth}_h
ip netns exec "${nom_netns}" ip link set ${nom_veth}_h master "${nom_pont}"
ip netns exec "${nom_netns}" ip link set dev ${nom_veth}_h type bridge_slave isolated off
ip netns exec "${nom_netns}" sh -c "echo 1 > /proc/sys/net/ipv6/conf/${nom_pont}/disable_ipv6"
ip netns exec "${nom_netns}" sh -c "echo 1 > /proc/sys/net/ipv6/conf/${nom_veth}_h/disable_ipv6"
ip netns exec "${nom_netns}" ip link set ${nom_pont} up
ip netns exec "${nom_netns}" ip link set ${nom_veth}_h up
ip address add "${ipv4_veth}" dev "${nom_veth}"
ip link set "${nom_veth}" up
```

Ne pas oublier d'ajouter les droits d'exécution au script et d'activer le routage :
```bash
chmod +x /usr/local/sbin/confint

# Configuration de routage éphémère
# Utiliser un paramètre sysctl pour le rendre persistent
echo 1 > /proc/sys/net/ipv4/ip_forward
```

# Tests sans altérations
Si vous voulez modifier les scripts, il peut être pratique d'afficher les commandes générées sans les appliquer lors de vos tests. Pour ce faire, il suffit de commenter la ligne suivante (et comme précisé en commentaire dans le script) dans la fonction `execCmdIntRzo()` (le script exige un nom de conteneur en paramètre) :

``` bash
# ${commandes_a_executer["${id_commande_rzo}"]}
```