15 KiB
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 :
::::: {.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 :
::::: {.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 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)1. Il spécifie le format par lequel doivent commencer les données liées à l'administration d'interfaces réseau.
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.
Le payload du message Netlink sera donc transmis comme une liste d'attributs (où chaque attribut peut à son tour avoir des attributs imbriqués).
En se basant sur du code d'ip link
2, on peut reconstituer la
communication suivante :
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
:
Il ne reste maintenant plus qu'à assigner une IP à chacune des interfaces :
Dès lors3, nous pouvons ping
er chaque extrêmité :
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.
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 :
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.
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 :
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 :
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 Networking4.
Appliqué à Docker, vous apprécierez cet article : Understanding Docker Networking Drivers and their use cases5.
-
Network Interface Service Module https://tools.ietf.org/html/rfc3549#section-2.3.3.1 ↩︎
-
https://github.com/shemminger/iproute2/blob/main/ip/link_veth.c ↩︎
-
Il peut être nécessaire d'activer chaque lien, via
ip link set vethX up
. ↩︎ -
https://blog.flameeyes.eu/2010/09/linux-containers-and-networking ↩︎
-
https://www.docker.com/blog/understanding-docker-networking-drivers-use-cases/ ↩︎