D’abord définissons ce qu’est le source-specific routing
Le source-specific routing se traduit en français par « routage en fonction de la source ». En termes moins barbares, cela veut dire que l’on enverra nos paquets via une route différente en fonction de leur provenance. Cela sert par exemple quand on a plusieurs accès internet sur une machine, et que l’on veut répartir la charge entre les deux. Nous pouvons aussi en avoir l’utilité si l’on veut redonder un serveur.Et voici comment ça fonctionne
Je suis pour ma part dans le cas où je veux redonder mon serveur chez moi. Qui dit serveur à la maison, dit serveur sur mon réseau local, donc sans forcément d’IPv4 publique dessus.Comme je n’avais pas envie de m’embêter avec les redirections NAT et que je voulais être sûr d’avoir une IP fixe, j’ai choisi de prendre un VPN chez Illyse qui tombe directement sur mon serveur. Ainsi, je peux changer de FAI comme je veux, l’IP publique de mon serveur ne changera pas et je résiste aussi à toutes les règles de filtrage qui peuvent m’être imposées. Ce VPN m’offre une IPv4 fixe et un bloc IPv6 /56.
Et aussi, comme j’aime bien jouer, j’ai un tunnel 6in4 qui arrive chez moi depuis he.net et qui me permet d’avoir de l’IPv6 sur tout mon réseau local alors que numéricâble ne sait pas faire ça. Je me suis donc retrouvé avec deux IPv6 publiques sur mon serveur : 2001:470:1f13:138:715d:2fa0:b591:532f/64 par he et 2a00:5881:4008:400::1/56 par Illyse.
S’est alors posée la question « comment puis-je être joignable via ces deux IPs sachant que je n’ai qu’une seule route par défaut ? ».
2001:470:1f13:138::/64 dev eth0 proto kernel metric 4
2a00:5881:4008:400::/64 dev tun0 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
default via fe80::250:fcff:fe4d:c3a4 dev eth0 metric 1024
En effet, avec une seule route par défaut, tous les paquets IP ressortiront
via la même interface, pour ma part eth0. Auparavant il fallait jouer avec
ip rules
, créer plusieurs tables de routage et composer avec
tout ça. Si cela vous intéresse, vous pouvez regarder sur
lartc.org comment procéder. Pour ma part je trouve que ça fait un peu
mal aux cheveux.Et bien depuis la version 3.12 du kernel Linux et la clause
from
, il suffit de deux commandes : ip -6 route add
default dev tun0 from 2a00:5881:4008:400::/56
et ip -6 route
add default via fe80::250:fcff:fe4d:c3a4 dev eth0 from
2001:470:1f13:138::/64
si je veux répondre sur une IP dans chacun de
ces réseaux, sur leur interface respective. Nous obtenons alors une table
de routage du genre de :
default from 2001:470:1f13:138::/64 via fe80::250:fcff:fe4d:c3a4 dev eth0 metric 1024
default from 2a00:5881:4008:400::/56 dev tun0 metric 1024
2001:470:1f13:138::/64 dev eth0 proto kernel metric 4
2a00:5881:4008:400::/64 dev tun0 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
default via fe80::250:fcff:fe4d:c3a4 dev eth0 metric 1024
Ainsi, mon serveur saura quelle interface utiliser en fonction de l’adresse
source.