J'essaye, depuis un long moment, de résoudre un problème assez complexe : comment utiliser les adresses ipv6 anonymes sur l'internet public, tout en utilisant les adresses fixes connues dans un réseau local.

Hein ?

L'idée

Lorsque vous naviguer sur le web, vous souhaitez être le moins possible traçable. C'est possible (relativement) en utilisant des adresses ipv6 générées au hasard. Ainsi un site web qui verrait passer différentes adresses ne saurait pas qu'en fait il s'agit d'un seul ordinateur.

Ceci n'est qu'une partie d'une vraie solution d’anonymisation. Il faut aussi faire en sorte que votre navigateur lui-même soit intraçable.

Mais l'utilisation de ces adresses ipv6 s'avère une mauvaise idée dans votre réseau local. Ici, en effet, vous souhaitez au contraire avoir des adresses fixes et connues des autres appareils. Ainsi, l'utilisation d'une adresse fixe et inscrite dans un DNS local, tel que décrit ailleurs dans ce blog, permet de savoir que c'est la machine d'Arthur qui s'est connectée au serveur de courrier.

Lors d'une connection en ssh, le serveur sur lequel on se connecte va typiquement essayer de savoir quel est le nom de la machine qui demande la connection. Et ça peut prendre des plombes.

Théorie

Pour résoudre cela, il faudrait en fait que la table de routage utilise en priorité les adresses fixes dans un réseau local connu, et au contraire les adresses aléatoires dans un réseau public.

Un autre problème apparaît : quand décider que le réseau est suffisamment sûr ? L'ordinateur, lui, ne le sait pas. C'est l'utilisateur qui sait s'il est chez lui ou sur un wifi public.

On notera donc que l'utilisateur lui-même doit être éduqué, comprendre ce que signifie sécuriser son réseau, etc.

Dans Windows, il y a une option qui permet à l'utilisateur de signaler que le réseau dans lequel il se trouve est un réseau public ou privé. Ça permet de modifier la politique du pare-feu en conséquence. C'est également ce qui devrait permettre d'ajuster la table de routage.

Expérimentations

Adresse fixe

On pourrait utiliser une adresse fournie par dhcp(v6), mais dans ce cas, il faut indiquer celle-ci dans la route (cf ci-dessous).

Je vais donc plutôt utiliser l'adresse SLAAC de l'interface, ce qui a l'avantage d'être vraiment fixe et possiblement connue à l'avance (avec ipv6calc). Ceci se fait en activant l'autoconf dans les paramètres du noyau (soit via sysctl, soit via /proc).

cat /proc/sys/net/ipv6/conf/all/autoconf 
1

Adresses temporaires

Idem :

cat /proc/sys/net/ipv6/conf/all/use_tempaddr
2

La valeur 2 indique qu'on privilégie les adresses temporaires.

Voici maintenant mes adresses ipv6, sur mon interface filaire :

[stephane@Jabberwocky ~]$ ip -6 addr show eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:…:c79/64 scope global temporary dynamic 
   valid_lft 3508sec preferred_lft 3508sec
inet6 2001:…:d709/64 scope global mngtmpaddr dynamic 
   valid_lft 3508sec preferred_lft 3508sec
inet6 fe80::…:d709/64 scope link 
   valid_lft forever preferred_lft forever

On voit que la première adresse est temporaire et la troisième est l'adresse de lien local. La seconde est l'adresse SLAAC, puisque ses derniers octets sont les mêmes que pour l'adresse de lien local.

Route

Voici la table de routage ipv6 de base de mon portable :

[stephane@Jabberwocky ~]$ ip -6 route
2001:…:e2::/64 dev eno1  proto kernel  metric 256  expires 3598sec pref medium
fe80::/64 dev eno1  proto kernel  metric 256  pref medium
default via fe80:…:d709 dev eno1  proto ra  metric 1024  expires 598sec hoplimit 255 pref medium

Il faut en fait ajouter une route, ou modifier la première.

Changer la route :

(On a besoin de mettre une métrique basse, sinon c'est pas cette route qui sera prise en compte.)

[stephane@Jabberwocky ~]$ sudo ip -6 route add 2001:...:e2::/64 src 2001:...:e2:226:...:d709 dev eno1 metric 128

Resultat :

[stephane@Jabberwocky ~]$ ip -6 route
2001:...:e2::/64 dev eno1  src 2001:...:e2:226:...:d709  metric 128  pref medium
fe80::/64 dev eno1  proto kernel  metric 256  pref medium
default via fe80::20d:b9ff:fe3e:a812 dev eno1  proto ra  metric 1024  expires 594sec hoplimit 255 pref medium

En mettant la métrique à 128 (nombre pris un peu au hasard, mais en dessous de 256), on met la route au dessus. Si on ne précise pas de métrique, la valeur considérée est 1024 et la route n'est pas considérée.

Vérifier le montage

Prenez les adresses ip d'un des hôtes de votre réseau et d'un hôte public (google ou FB feront de bonnes victimes) et vérifiez donc quelles adresses sources seront considérées lors d'une connection.

Google

[stephane@Jabberwocky ~]$ host -t aaaa google.com
google.com has IPv6 address 2a00:1450:400f:808::200e

[stephane@Jabberwocky ~]$ ip route get 2a00:1450:4005:803::200e
2a00:1450:4005:803::200e from :: via fe80::20d:...:a812 dev eno1  proto ra  src 2001:...:e2:e5b4:...:c79  metric 1024  hoplimit 255 pref medium

J'obtiens l'adresse anonyme.

Hote du réseau local

[stephane@Jabberwocky all]$ ip route get 2001:...:e2::2
2001:...:e2::2 from :: dev eno1  src 2001:...:e2:226:...:d709  metric 128  pref medium

J'obtiens l'adresse fixe.

Du concret

Le problème c'est donc de modifier durablement la table de routage dans le cadre de ce réseau précis (cet ordinateur étant un portable, je le change fréquemment de réseau. La configuration ne doit donc être fixe que pour ce réseau). Pour tous les autres réseaux, la table de routage par défaut, générée et gérée par le noyau et les démons réseaux doit rester en place.

Pour les ordinateurs faiblement mobiles (comprenez : tours et ordinateurs de bureaux statiques), on va voir que la problématique reste la même.

En gros, pour l'instant, j'ai un script que j'active suivant le besoin et qui modifie la route tel que décrit plus haut. C'est pas fixe, c'est donc dynamique, enfin fixement dynamique ou dynamiquement fixe, au choix. Surtout c'est pas comme ça qu'on devrait faire.

D'autre part, une fois la table de routage modifiée, il arrive souvent qu'elle soit mise à jour, auquel cas la route que vous avez mise en place n'est pas forcement utilisée.

À ma connaissance personne n'a prévu ou conçu de politique de routage de ce genre. Si vous avez une solution, vos commentaires sont les bienvenus.