```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 link`[^IPLINK], on peut reconstituer la
communication suivante :
[^IPLINK]:
```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);
}
```
Maintenant que l'on a notre interface virtuelle, nous pouvons envoyer un second
message pour la déplacer dans un nouveau *namespace*[^IPSETNS] :
[^IPSETNS]:
```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 lors[^linkdown], nous pouvons `ping`er chaque extrêmité :
[^linkdown]: Il peut être nécessaire d'activer chaque lien, via `ip link set
vethX up`.
```
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](https://fr.wikipedia.org/wiki/IEEE_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](http://www.ieee802.org/1/pages/802.1bg.html)).
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 Networking](https://blog.flameeyes.eu/2010/09/linux-containers-and-networking)[^netnsmore1].
Appliqué à Docker, vous apprécierez cet article : [Understanding Docker
Networking Drivers and their use
cases](https://www.docker.com/blog/understanding-docker-networking-drivers-use-cases/)[^netnsmore2].
[^netnsmore1]:
[^netnsmore2]: