teach/virli
1
0
Fork 0
Code Issues Pull requests Releases Activity

tuto4 ready

Browse source
This commit is contained in:
nemunaire 2022-11-11 10:14:16 +01:00
commit e928733d61
17 changed files with 789 additions and 203 deletions
Download patch file Download diff file Expand all files Collapse all files

269
tutorial/4/networkns.md
View file

@ -1,8 +1,9 @@
\newpage
Le *namespace* `network` {#net-ns}
------------------------
Voyons maintenant plus en détail les différents espaces de nom, leurs
caractéristiques et leurs usages ; en commençant par le *namespace* `network`.
### Introduction
L'espace de noms `network`, comme son nom l'indique permet de virtualiser tout
@ -14,16 +15,25 @@ environnement qui n'a plus qu'une interface de *loopback* :
<div lang="en-US">
```
42sh# unshare -n ip a
42sh# unshare --net ip a
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
```
</div>
::::: {.warning}
Bien que portant le même nom que l'interface de *loopback* de notre
environnement principal, il s'agit bien de deux interfaces isolées l'une de
l'autre.
:::::
Afin d'amener du réseau à notre nouvel espace de nom, il va falloir lui
attribuer des interface. En fait, nous allons pouvoir déplacer nos interfaces
réseaux, dans le *namespace* vers lequel elle doit être accessible. Une
interface donnée ne peut se trouver que dans un seul *namespace* à la fois.
Qui dit nouvelle pile réseau, dit également que les ports qui sont assignés
dans l'espace principal, ne le sont plus dans le conteneur : il est donc
possible de lancer un serveur web sans qu'il n'entre en conflit avec celui d'un
@ -38,17 +48,51 @@ La suite d'outils `iproute2` propose une interface simplifiée pour utiliser le
Nous pouvons tout d'abord créer un nouvel espace de noms :
<div lang="en-US">
```bash
```
42sh# ip netns add virli
```
</div>
::::: {.code}
La technique utilisée ici pour avoir des *namespaces* nommés est la même que
celle que nous avons vue dans
[la première partie sur les *namespaces*](#ns-lifetime) : via un `mount --bind`
dans le dossier `/var/run/netns/`. Cela permet de faire persister le namespace
malgré le fait que plus aucun processus ne s'y exécute.
Nous pouvons créer artificiellement des entrées pour `ip netns` avec les
quelques commandes suivantes :
<div lang="en-US">
```
# On affiche la liste des netns déjà créés
42sh# ip netns
virli
# On crée un fichier pour servir de réceptacle au bind mount
42sh# touch /var/run/netns/foo
# On crée un nouveau namespace net, puis on bind tout de suite le
# fichier de namespace vers le fichier que l'on vient de créer
42sh# unshare --net \
mount --bind /proc/self/ns/net /var/run/netns/foo
# Testons si cela a bien marché
42sh# ip netns
foo virli
42sh# ip netns exec foo ip link
1: lo: <LOOPBACK> mut 65536 qdisc noop state DOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
```
</div>
Les fichiers utilisés par `ip netns` ne sont donc rien de plus que des
*bind-mount*. Ce qui explique qu'ils soient persistant même sans processus
s'exécutant à l'intérieur.
:::::
Maintenant que notre *namespace* est créé, nous pouvons regarder s'il contient
des interfaces :
@ -67,7 +111,7 @@ D'ailleurs, cette interface est rapportée comme étant désactivée, activons-l
via la commande :
<div lang="en-US">
```bash
```
42sh# ip netns exec virli ip link set dev lo up
```
</div>
@ -105,6 +149,171 @@ entre d'un côté sort de l'autre et inversement. La commande précédente a don
créé deux interfaces `veth0` et `veth1` : les paquets envoyés sur `veth0` sont
donc reçus par `veth1` et les paquets envoyés à `veth1` sont reçus par `veth0`.
::::: {.code}
Pour réaliser ces étapes dans un langage de programmation, nous allons passer
par Netlink. Il s'agit d'une interface de communication entre le noyau et
l'espace utilisateur. Il faut commencer par créer une `socket` pour avoir accès
à l'API Netlink, nous pourrons ensuite envoyer des requêtes, comme celle nous
permettant de créer notre interface `veth`.
Un message Netlink a une structure, alignée sur 4 octets, contenant un en-tête
et des données. Le format de l'en-tête est décrit dans le RFC
3549[^RFC3549] :
[^RFC3549]: <https://tools.ietf.org/html/rfc3549>
<div lang="en-US">
```c
struct nlmsghdr {
uint32_t nlmsg_len; // Length of message including header
uint16_t nlmsg_type; // Type of message content
uint16_t nlmsg_flags; // Additional flags
uint32_t nlmsg_seq; // Sequence number
uint32_t nlmsg_pid; // Sender port ID
};
```
</div>
Parmi les fonctionnalités de Netlink, nous allons utiliser le module NIS
(Network Interface Service)[^REF3549NIS]. Il spécifie le format par lequel
doivent commencer les données liées à l'administration d'interfaces réseau.
[^RFC3549NIS]: Network Interface Service Module <https://tools.ietf.org/html/rfc3549#section-2.3.3.1>
<div lang="en-US">
```c
struct ifinfomsg {
uint8_t ifi_family; // AF_UNSPEC
// uint8_t Reserved
uint16_t ifi_type; // Device type
int32_t ifi_index; // Interface index
uint32_t ifi_flags; // Device flags
uint32_t ifi_change; // change mask
};
```
</div>
Le module NIS a besoin que les données soient transmises sous forme d'*attributs
Netlink*. Ces attributs fournissent un moyen de segmenter la charge utile en
sous-sections. Un attribut a une taille et un type, en plus de sa charge utile.
<div lang="en-US">
```c
struct rtattr {
uint16_t rta_len; // Length of option
uint16_t rta_type; // Type of option
// Data follows
};
```
</div>
Le *payload* du message Netlink sera donc transmis comme une liste d'attributs (où
chaque attribut peut à son tour avoir des attributs imbriqués).
<div lang="en-US">
```c
struct rtattr {
unsigned short rta_len;
unsigned short rta_type;
};
```
</div>
En se basant sur du code d'`ip link`[^IPLINK], on peut reconstituer la
communication suivante :
[^IPLINK]: <https://github.com/shemminger/iproute2/blob/main/ip/link_veth.c>
<div lang="en-US">
```c
#define MAX_PAYLOAD 1024
struct nlreq {
struct nlmsghdr hdr; // Netlink message header
struct ifinfomsg msg; // First data filled with NIS module info
char buf[MAX_PAYLOAD]; // Remaining payload
};
int
create_veth(char *ifname, char *peername)
{
// Create the netlink socket
int sock_fd = socket(PF_NETLINK, SOCK_RAW | SOCK_CLOEXEC, NETLINK_ROUTE);
if (sock_fd < 0)
return -1;
uint16_t flags =
NLM_F_REQUEST // We build a request message
| NLM_F_CREATE // Create a device if it doesn't exist
| NLM_F_EXCL // Do nothing if it already exists
| NLM_F_ACK; // Except an ack as reply or an error
// Initialise request message
struct nl_req req = {
.hdr.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg)),
.hdr.nlmsg_flags = flags,
.hdr.nlmsg_type = RTM_NEWLINK,
.msg.ifi_family = PF_NETLINK,
};
struct nlmsghdr *hdr = &req.hdr;
int maxlen = sizeof(req);
// Attribute r0 with veth info
addattr_l(hdr, maxlen, IFLA_IFNAME, ifname, strlen(ifname) + 1);
// Attribute r1 nested within r1, containing iface info
struct rtattr *linfo =
addattr_nest(n, maxlen, IFLA_LINKINFO);
// Specify the device type is veth
addattr_l(hdr, maxlen, IFLA_INFO_KIND, "veth", 5);
// r2: another nested attribute
struct rtattr *linfodata =
addattr_nest(hdr, maxlen, IFLA_INFO_DATA);
// r3: nested attribute, contains the peer name
struct rtattr *peerinfo =
addattr_nest(n, maxlen, VETH_INFO_PEER);
n->nlmsg_len += sizeof(struct ifinfomsg);
addattr_l(n, maxlen, IFLA_IFNAME, peername, strlen(peername) + 1);
addattr_nest_end(hdr, peerinfo);
addattr_nest_end(hdr, linfodata);
addattr_nest_end(hdr, linfo);
// Send the message
sendmsg(sock_fd, &req, 0);
}
```
</div>
Maintenant que l'on a notre interface virtuelle, nous pouvons envoyer un second
message pour la déplacer dans un nouveau *namespace*[^IPSETNS] :
[^IPSETNS]: <https://github.com/shemminger/iproute2/blob/main/ip/iplink.c#L677>
<div lang="en-US">
```c
// Initialise request message
struct nl_req req = {
.hdr.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg)),
.hdr.nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK,
.hdr.nlmsg_type = RTM_NEWLINK,
.msg.ifi_family = PF_NETLINK,
};
addattr_l(&req.hdr, sizeof(req), IFLA_NET_NS_FD, &netns, 4);
addattr_l(&req.hdr, sizeof(req), IFLA_IFNAME,
ifname, strlen(ifname) + 1);
sendmsg(sock_fd, &req, 0);
```
</div>
:::::
Dans cette configuration, ces deux interfaces ne sont pas très utiles, mais si
l'on place l'une des deux extrémités dans un autre *namespace* `network`, il
devient alors possible de réaliser un échange de paquets entre les deux.
@ -112,7 +321,7 @@ devient alors possible de réaliser un échange de paquets entre les deux.
Pour déplacer `veth1` dans notre *namespace* `virli` :
<div lang="en-US">
```bash
```
42sh# ip link set veth1 netns virli
```
</div>
@ -120,7 +329,7 @@ Pour déplacer `veth1` dans notre *namespace* `virli` :
Il ne reste maintenant plus qu'à assigner une IP à chacune des interfaces :
<div lang="en-US">
```bash
```
42sh# ip netns exec virli ip a add 10.10.10.42/24 dev veth1
42sh# ip a add 10.10.10.41/24 dev veth0
```
@ -150,8 +359,9 @@ couches du noyau. Utiliser les interfaces *veth* est plutôt simple et disponibl
partout, mais c'est loin d'être la technique la plus rapide ou la moins
gourmande.
Voyons ensemble les autres possibilités à notre disposition.
#### VLAN
#### VLAN \
Il est possible d'attribuer juste une interface de VLAN, si l'on a un switch
supportant la technologie [802.1q](https://fr.wikipedia.org/wiki/IEEE_802.1Q)
@ -165,8 +375,11 @@ derrière notre machine.
```
</div>
On attribuera alors à chaque conteneur une interface de VLAN différente. Cela
peut donner lieu à une configuration de switch(s) assez complexe.
#### MACVLAN
#### MACVLAN \
<!-- https://hicu.be/bridge-vs-macvlan -->
@ -176,11 +389,11 @@ MACVLAN. S'il est activé dans votre noyau, vous allez avoir le choix entre l'un
des quatre modes : *private*, VEPA, *bridge* ou *passthru*.
Quel que soit le mode choisi, les paquets en provenance d'autres machines et à
destination d'un MAC seront délivrés à l'interface possédant la MAC. Les
destination d'une MAC seront délivrés à l'interface possédant ladite MAC. Les
différences entre les modes se trouvent au niveau de la communication entre les
interfaces.
##### VEPA
##### VEPA \
Dans ce mode, tous les paquets sortants sont directement envoyés sur
l'interface Ethernet de sortie, sans qu'aucun routage préalable n'ait été
@ -198,7 +411,7 @@ Pour construire une nouvelle interface de ce type :
</div>
##### *Private*
##### *Private* \
À la différence du mode *VEPA*, si un paquet émis par un conteneur à
destination d'un autre conteneur est réfléchi par un switch, le paquet ne sera
@ -214,12 +427,12 @@ conteneur de la même machine.
</div>
##### *Bridge*
##### *Bridge* \
À l'inverse des modes *VEPA* et *private*, les paquets sont routés selon leur
adresse MAC : si jamais une adresse MAC est connue, le paquet est délivré à
l'interface MACVLAN correspondante ; dans le cas contraire, le paquet est
envoyé sur l'interface de sortie.
En mode *Bridge*, les paquets sont routés selon leur adresse MAC : si jamais
une adresse MAC est connue, le paquet est délivré à l'interface MACVLAN
correspondante ; dans le cas contraire, le paquet est envoyé sur l'interface de
sortie.
Pour construire une nouvelle interface de ce type :
@ -230,6 +443,28 @@ Pour construire une nouvelle interface de ce type :
</div>
##### *passthru* \
Enfin, le mode *passthru* permet de récupérer le contrôle sur tout ce qu'il
reste du périphérique initial (notamment pour lui changer sa MAC propre, ou
pour activer le mode de promiscuité).
L'intérêt est surtout de pouvoir donner cette interface à un conteneur ou une
machine virtuelle, sans lui donner un accès complet à l'interface physique (et
notamment aux autres MACVLAN).
On construit l'interface en mode *passthru* de cette façon :
<div lang="en-US">
```
42sh# ip link add link eth0 mac3 type macvlan mode passthru
```
</div>
Une seule interface MACVLAN peut être en mode *passthru* par interface
physique.
### Aller plus loin {-}
Pour approfondir les différentes techniques de routage, je vous