Attention, avec la commande _ip_ le résultat ne sera pas visible avec _ifconfig_
si aucun label du type eth0:N n'est donné à l'interface ; on ne verra l'adresse qu'avec un :
~~~
# ip addr show
~~~
Notons que dans certains cas particuliers (comme le besoin de préciser le nom de l'interface
dans une commande _iptables_) on souhaite avoir un nom d'interface virtuelle sans les ":".
On utilisera donc simplement un label sans ":" :
~~~
# ip addr add 192.0.43.13/24 dev label eth00
# iptables -t nat -A POSTROUTING -o eth00 [...]
~~~
## Configuration serveur(s) DNS
Le fichier _/etc/hosts_ permet d'indiquer manuellement des enregistrements DNS, du type :
~~~
127.0.0.1 ad.doubleclick.net
~~~
Pour note, ces enregistrements sont par défaut prioritaires sur les réponses des serveurs DNS
(et pour rappel, les commandes dig et host n'utilisent PAS _/etc/hosts_).
La configuration du (ou des) serveur(s) DNS s'effectue dans le fichier _/etc/resolv.conf_.
Voici un exemple classique :
~~~
search example.com
nameserver 192.0.42.53
nameserver 192.0.43.53
options timeout:2 attempts:2
~~~
Pour des précisions sur les options possibles : _man resolv.conf_
Note : si l'on utilise Postfix, il faut le redémarrer suite à un changement dans _/etc/resolv.conf_ (car il est chrooté par dédaut et il gère sa propre copie dans /var/spool/postfix)
Attention, sur Debian 11, il faut apparemment ajouter `bridge_hw` avec l'adresse MAC de l'interface bridgée cf [#991416](https://bugs.debian.org/991416)... notamment sur les [serveurs OVH](ServeurOVH) :
Pour une configuration KVM, où l'on souhaiterait avoir plusieurs bridges selon les VLANs, il faut en premier configurer l'interface physique enoX, puis une interface enoX.YY par VLAN, et un bridge par VLAN dans lequel sera ce même enoX.YY. L'IP du KVM doit être attribuée au bridge qui correspond au VLAN dans lequel ce KVM est. Par exemple, avec un KVM dont l'IP est dans le VLAN 2, et des VMs devant être dans les VLANs 2, 3 et 4 :
~~~
auto eno1
iface eno1 inet manual
# VLAN2
auto eno1.2
iface eno1.2 inet manual
## Bridge
auto bridge_vlan2
iface bridge_vlan2 inet static
address 192.0.2.1/24
gateway 192.0.2.254
bridge_ports eno1.2
# VLAN 3
auto eno1.3
iface eno1.3 inet manual
## Bridge
auto bridge_vlan3
iface bridge_vlan3 inet manual
bridge_ports eno1.3
# VLAN 4
auto eno1.4
iface eno1.4 inet manual
## Bridge
auto bridge_vlan4
iface bridge_vlan4 inet manual
bridge_ports eno1.4
~~~
L'IP du KVM est 192.0.2.1 dans le VLAN2. Ensuite, le bridge correspondant au VLAN souhaité sera attribué à la VM.
Le bonding, ou l'agrégation de lien, permet d'agréger plusieurs liens physiques en un seul lien virtuel. Selon le mode utilisé, cela peut offrir une tolérance de panne, de l'équilibrage de charge (load-balancing), et/ou une augmentation de débit.
~~~
# apt install ifenslave
# modprobe bonding
~~~
Son implémentation sous Debian est documentée dans `/usr/share/doc/ifenslave/README.Debian.gz`.
Il existe plusieurs modes : `balance-rr` (round-robin), `active-backup`, `balance-xor`, `broadcast`, `802.3ad` (LACP), `balance-tlb` (Adaptive Transmit Load Balancing), et `balance-alb` (Adaptive Load Balancing). Chacun est numéroté de 0 à 6.
Les modes active-backup, ALB et TLB ne nécessitent pas de configuration particulière des switchs, alors que les autres modes oui.
Pour du bonding sans configuration du côté des switchs, nous utilisons le mode ALB (ou mode "6"), qui comprend les caractéristiques du mode TLB avec des suppléments.
En effet avec le mode TLB, seul le trafic sortant bénéficie du load-balancing entre les différentes interfaces, et le trafic entrant n'est reçue que sur une seule interface. Le mode ALB permet également le load-balancing sur le trafic entrant à l'aide de négociations ARP.
Dans ce mode, chacune des interfaces physiques faisant partie du bonding parent possède sa propre adresse MAC. Ainsi, les switchs uplink − qui ne sont pas au courant de ce bonding − ne verront pas de flapping d'adresses MAC.
Le débit total du serveur peut être augmenté lors de multiples connexions selon le nombre d'interfaces physiques, mais le débit d'une seule même connexion ne pourra pas dépasser celui d'une interface physique seule, dû au fonctionnement du load-balancing.
Ce mode pose problème lorsque du VRRP est nécessaire sur la machine. En effet, le driver du mode ALB modifie l'adresse MAC correspondant à l'IP utilisée selon l'interface de sortie (pour avoir une adresse MAC par interface, comme indiqué ci-dessus). Du coup, l'adresse MAC de type 00:00:5e:00:01:XX utilisée par VRRP et partagée par les machines membres VRRP n'est jamais vue par les voisins, et une bascule VRRP impliquera une coupure de l'IP le temps que le cache ARP des voisins expire.
Pour du bonding sans configuration du côté des switchs, nous utilisons également le mode active-backup (ou mode "1"), où seule une interface sur les 2 est utilisée activement. Ce mode permet une redondance, et est préférable au mode ALB lorsque du VRRP est nécessaire sur la machine.
Pour une configuration KVM, où l'on souhaiterait avoir plusieurs bridges selon les VLANs, il faut en premier configurer l'interface bond0, puis une interface bond0.XX par VLAN, et un bridge par VLAN dans lequel sera ce même bond0.XX. L'IP du KVM doit être attribuée au bridge qui correspond au VLAN dans lequel ce KVM est. Par exemple, avec un KVM dont l'IP est dans le VLAN 2, et des VMs devant être dans les VLANs 2, 3 et 4 :
Il est possible de configurer d'autres tables de routage, permettant par exemple d'utiliser plusieurs routes par défaut selon certaines conditions. Le paquet `iproute2` est nécessaire.
Un exemple de nécessité peut être dans le cas où un serveur possède 2 adresses IP différentes, dans 2 réseaux différents :
~~~
# ip --brief a
eth0 UP 192.0.2.1/24
eth1 UP 198.51.100.1/24
~~~
Disons que la route par défaut est 192.0.2.254 :
~~~
# ip r
default via 192.0.2.254 dev eth0
~~~
Alors tous les paquets sortiront par cette route par défaut, et cela peut être problématique si l'on souhaite joindre l'IP 198.51.100.1 dans l'autre réseau.
On peut alors créer une nouvelle table de routage en l'ajoutant dans `/etc/iproute2/rt_tables`. Ici, j'ajoute la table `secondfai` :
~~~
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
#1 inr.ruhep
2 secondfai
~~~
On voit qu'il existe déjà plusieurs tables. La table `local` s'occupe du trafic devant rester local à la machine, ainsi que du broadcast. La table `main` est celle utilisée et affichée par défaut lorsqu'on ne précise pas de table. La table `default` est vide.
On va maintenant remplir cette nouvelle table de routage, en y spécifiant la route par défaut 198.51.100.254 du second réseau :
Il nous reste à spécifier dans quels cas utiliser cette table. Si l'on veut que tout le trafic que la machine émet depuis ce second réseau passe forcément par son routeur 198.51.100.254, on peut spécifier cette règle :
~~~
# ip rule add from 198.51.100.0/24 lookup secondfai prio 1000
~~~
Cette règle se traduit par « pour tout trafic dont la source est dans le réseau 198.51.100.0/24, je consulte la table `secondfai` », et sa priorité est de 1000. Plus sa priorité sera basse, et plus la règle sera prioritaire.
Les règles en place peuvent être consultées de cette manière :
Ainsi, tout le trafic que la machine émet depuis 192.0.2.1/24 sortira par la route par défaut de la table par défaut `main`, et tout le trafic que la machine émet depuis 198.51.100.1/24 sortira par la route par défaut de la table secondaire `secondfai`.
À partir de Stretch, certaines machines sont installés d'office avec networkd (qui fait partie de systemd), on peut vouloir migrer à ifup (`/etc/network/interfaces`) pour plusieurs raisons (compatibilité, …).
Si besoin de « haute performance », on appliquera la configuration [sysctl](https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt) suivante :
*`net.nf_conntrack_max=262144` (utiliser `conntrack -L` pour bien ajuster la valeur)
*`net.core.somaxconn=1024`
*`net.ipv4.tcp_max_syn_backlog=1024`
*`net.ipv4.tcp_tw_reuse=1`
*`net.ipv4.tcp_fin_timeout=30`
*`net.ipv4.ip_local_port_range=2000 65000`
Si cela ne suffit pas, voici quelques pistes pour aller plus loin :
* lire <http://www.nateware.com/linux-network-tuning-for-2013.html> et notamment les options `net.core.*mem*`, `net.core.optmem_max`, `net.ipv4.tcp_*mem`, `net.core.netdev_max_backlog`, `net.ipv4.tcp_max_tw_buckets`
* augmenter le buffer de certains cartes réseau avec [ethtool]() : voir `ethtool -g eth0` et modifier avec `ethtool -G eth0 rx/rx-mini/rx-jumbo/tx NNNN`
puis sur ce serveur on spécifie l'IP déplacée (par exemple 192.0.2.42), l'IP du routeur (par exemple 192.0.2.254) et la nouvelle adresse MAC (par exemple 52:54:00:12:34:56) :
Il arrive qu'on veuille vérifier qu'il est possible de joindre un port TCP au travers d'un firewall, alors que rien n'écoute sur ce port à ce moment là. On peut alors utiliser `socat(1)` ou `nc(1)` pour créer un serveur temporaire, qui imprimera sur la sortie standard ce qui arrive sur le port. Exemple sur le port 2121, en écoute sur toutes les interfaces du serveur :
Lorsqu'on souhaite consulter ce qui passe en TCP entre 2 processus ou serveurs (par exemple entre HAProxy et Apache), pour analyser par exemple les en-têtes échangés… on peut utiliser tcpdump, mais cela n'est pas toujours aisé.
Il est possible d'intercaler `socat(1)` entre les 2 processus. Il fera le passe-plat mais nous indiquera aussi (sur la sortie standard) ce qui est échangé.
Ici on ouvre localement le port 8080 et on renvoie le flux vers le port 8080 de example.com.
# systemctl restart networking; ip a d 192.0.2.42/24 dev eth0; ip a a 192.0.2.42/24 dev br0; ip r d default via 192.0.2.1 dev eth0; ip r a default via 192.0.2.1 dev br0
~~~
Ainsi, si l'on perd la main, la machine revient accessible en quelques minutes.
