teach
/
virli
1
0
Fork 0
Code Issues Pull Requests Releases Activity
virli/tutorial/4/networkns.md

15 KiB
Raw Blame History

Le namespace network

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 ce qui est en lien avec le réseau : les interfaces, les ports, les routes, les règles de filtrage, etc.

En entrant dans un nouvel espace de noms network, on se retrouve dans un environnement qui n'a plus qu'une interface de loopback :

``` 42sh# unshare --net ip a 1: lo: 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 ```

::::: {.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 autre espace de noms.

Premiers pas avec ip netns

La suite d'outils iproute2 propose une interface simplifiée pour utiliser le namespace network : ip netns.

Nous pouvons tout d'abord créer un nouvel espace de noms :

``` 42sh# ip netns add virli ```

::::: {.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 : 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 :

``` # 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: 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 :

<div lang="en-US">

42sh# ip netns exec virli ip link 1: lo: 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>

Cette commande ne nous montre que l'interface de *loopback*, car nous n'avons
pour l'instant pas encore attaché la moindre interface.

D'ailleurs, cette interface est rapportée comme étant désactivée, activons-la
via la commande :

<div lang="en-US">

42sh# ip netns exec virli ip link set dev lo up

</div>

À ce stade, nous pouvons déjà commencer à lancer un `ping` sur cette interface :

<div lang="en-US">

42sh# ip netns exec virli ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.038 ms ...

</div>


### *Virtual Ethernet*

Étant donné qu'une interface réseau ne peut être présente que dans un seul
espace de noms à la fois, il n'est pas bien pratique d'imposer d'avoir une
interface physique par conteneur, d'autant plus si l'on a plusieurs
centaines de conteneurs à gérer.

Une technique couramment employée consiste à créer une interface virtuelle de
type `veth` :

<div lang="en-US">

42sh# ip link add veth0 type veth peer name veth1

</div>

Une interface `veth` se comporte comme un tube bidirectionnel : tout ce qui
entre d'un côté sort de l'autre et inversement. La commande précédente a donc
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
};

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.

```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 }; ```

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.

```c struct rtattr { uint16_t rta_len; // Length of option uint16_t rta_type; // Type of option // Data follows }; ```

Le payload du message Netlink sera donc transmis comme une liste d'attributs (où chaque attribut peut à son tour avoir des attributs imbriqués).

```c struct rtattr { unsigned short rta_len; unsigned short rta_type; }; ```

En se basant sur du code d'ip link1, on peut reconstituer la communication suivante :

```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);

:::::

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.

Pour déplacer veth1 dans notre namespace virli :

``` 42sh# ip link set veth1 netns virli ```

Il ne reste maintenant plus qu'à assigner une IP à chacune des interfaces :

``` 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 ```

Dès lors2, nous pouvons pinger chaque extrêmité :

``` 42sh# ping 10.10.10.42 - et - 42sh# ip netns exec virli ping 10.10.10.41 ```

Il ne reste donc pas grand chose à faire pour fournir Internet à notre conteneur : via un peu de NAT ou grâce à un pont Ethernet.

Les autres types d'interfaces

Le bridge ou le NAT obligera tous les paquets à passer à travers de nombreuses couches du noyau. Utiliser les interfaces veth est plutôt simple et disponible 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 \

Il est possible d'attribuer juste une interface de VLAN, si l'on a un switch supportant la technologie 802.1q derrière notre machine.

``` 42sh# ip link add link eth0 name eth0.100 type vlan id 100 42sh# ip link set dev eth0.100 up 42sh# ip link set eth0.100 netns virli ```

On attribuera alors à chaque conteneur une interface de VLAN différente. Cela peut donner lieu à une configuration de switch(s) assez complexe.

MACVLAN \

Lorsque l'on n'a pas assez de carte ethernet et que le switch ne supporte pas les VLAN, le noyau met à disposition un routage basé sur les adresses MAC : le 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'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 \

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é effectué. Ainsi, si un paquet est à destination d'un des autres conteneurs de la machine, c'est à l'équipement réseau derrière la machine de rerouter le paquet vers la machine émettrice (par exemple un switch 802.1Qbg).

Pour construire une nouvelle interface de ce type :

``` 42sh# ip link add link eth0 mac0 type macvlan mode vepa ```
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 pas délivré.

Dans ce mode, on est donc assuré qu'aucun conteneur ne pourra parler à un autre conteneur de la même machine.

``` 42sh# ip link add link eth0 mac1 type macvlan mode private ```
Bridge \

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 :

``` 42sh# ip link add link eth0 mac2 type macvlan mode bridge ```
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 :

``` 42sh# ip link add link eth0 mac3 type macvlan mode passthru ```

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 recommande cet article : Linux Containers and Networking3.

Appliqué à Docker, vous apprécierez cet article : Understanding Docker Networking Drivers and their use cases4.