SwordArMor

Le source-specific routing sous linux 3.12 et supérieur

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.