IPv6 » Historique » Version 13
Version 12 (Bernard Urban, 29/09/2011 23:06) → Version 13/318 (Bernard Urban, 29/09/2011 23:35)
h1. IPv6
Information about IPv6
Issue #35
h2. Links
General
* http://en.wikipedia.org/wiki/ICMPv6
* http://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol
* http://en.wikipedia.org/wiki/Radvd
* http://en.wikipedia.org/wiki/DHCPv6
Linux
* http://madduck.net/docs/ipv6/
* http://tldp.org/HOWTO/Linux+IPv6-HOWTO/
h2. How to enable routing for /56 ?
Currently each IPv4 delivered by tetaneutral.net is matched by a /56 IPv6 (mapping /24 = 256 IPv4 <=> /48 = 256 /56 IPv6).
As tetaneutral.net is a simple flat ethernet network, all machines are on the same broadcast domain. In order to route /56s we must :
- Assign interconexion subnets. Current recommendation is to provide /112s matched to (but outside) of the corresponding /56
- Add a local static route for this subnet to h3 and gw (admin required)
h2. Discussions
> J'ai fait quelques essais: VM configuré en routeur, openvpn entre la VM
> et ma machine, histoire de simuler des interfaces. J'ai essayé radvd
> comme des définitions manuelles des adresses IPv6.
>
> Bon, ça marche depuis la VM mais pas depuis chez moi (wget
> http://ipv6.google.com), même si les paquets IPv6 (vu avec tcpdump)
> partent bien de la VM vers l'internet. Mais il n'y a pas de retour.
>
> Après quelques cogitations et la lecture de ceci:
> http://www.fdn.fr/IPv6-a-la-maison.html j'en arrive à ces
> réflexions:
>
> 1) Dans le blog FDN ci-dessus l'adresse IPv6 affectée au ppp0 n'est pas
> dans son /48; ce qui voudrait dire qu'il n'y a pas de raison d'affecter
> une IPv6 du /56 au eth0 des VM tetaneutral.
>
> 2) Pour faire marcher une telle config à FDN, le routeur FDN en amont du
> modem/routeur de l'abonné devrait avoir une route du type:
> ip -6 route add range/48 dev ppp-abonné via link-local-ppp-abonné
> soit chez nous:
> ip -6 route add range/56 dev eth0-vm via link-local-eth0-vm
>
> > du /56 via une interconnection explicite entre le routeur de
> > tetaneutral.net et un routeur chez le membre ?
>
> Un lien openvpn?
Bonsoir,
On peut rajouter une regle de routage comme tu le suggere,
reste a choisir les details pratiques.
Pour la link-local coté routeur on a choisi fe80::31 en statique il
reste a choisir une regle pour attribuer le link local coté client.
Une regle automatique basée sur l'IPv4 est en place pour
l'attribution du subnet IPv6 :
http://wiki.tetaneutral.net/index.php/Architecture
Une regle similaire pour le routage donnerait par exemple fe80::81:XY
ou XY est le dernier octet de l'IPv4 ecrit en hexadecimal
pour la link local coté client.
L'avantage d'une regle statique vs le SLAAC c'est que c'est un peu plus
flexible coté client sur le choix de l'equipement routeur.
L'avantage du routé est bien sur la flexibilité et la sécurisation
potentielle, l'inconvenient est qu'avec nos equipements actuels peu
puissant on perdra un peu en debit mais ça se corrigera avec
de nouveaux equipements.
Je suis vraiment curieux de savoir comment font les autres hebergeurs
dans le monde IPv6, ceux auxquels j'ai acces ne proposent pas de
routage, simplement ce que propose tetaneutral.net actuellement.
Suggestions ?
h2. Connectivité IPv6 complète depuis chez vous en quelques étapes simples +(en cours d'édition)+
Connectivité complète signifie que toutes vos machines pouvant fonctionner en IPv6 peuvent accéder des sites IPv6 externes mais surtout être joignables de l'extérieur sur une adresse IPv6 propre. Pas de NAT ou autre bidouille de ce genre. Implications en terme d'autohébergement et sécurité laissées en exercice.
Pour bien comprendre ce qui suit, il est recommandé d'avoir un peu potassé les hyperliens plus haut et mieux encore d'avoir joué avec l'IPv6 sur votre réseau local maison en utilisant par exemple des adresses ULA.
h3. Etape 1: obtenir une machine virtuelle Tetaneutral.
Celle-ci (on l'appellera VM dans la suite) sera configurée par défaut comme suit dans /etc/network/interfaces du point de vue IPv6:
<pre>
iface eth0 inet6 static
address 2a01:6600:80XX:YY00::1
netmask 56
gateway fe80::31
</pre>
où XX et YY sont les versions hexadécimales des xx et yy décimaux de votre (unique!) adresse IPv4 de la forme 91.224.xx.yy.
Voyons ce qu'implique la prise en compte par le système de ce fragment de /etc/network/interfaces. Il dit que:
# l'adresse 2a01:6600:80XX:YY00::1 est affectée à eth0, ce qui signifie que votre VM est accessible à cette adresse depuis l'intérieur de la VM comme depuis l'extérieur par toutes les machines du même segment réseau que eth0
# les paquets passant par votre VM peuvent atteindre les adresses de la plage 2a01:6600:80XX:YY00::/56 en étant envoyés en sortie de l'interface eth0
La plage 2a01:6600:80XX:YY00::/56 a été allouée par tetaneutral à votre VM. Notre problème est d'allouer une partie de ces adresses à des machines de notre domicile en utilisant l'accès que nous avons (en IPv4!) à la VM.
Avec cette configuration, vous pouvez héberger sur la VM des milliards de serveurs avec des adresses IPv6 différentes, il suffit de les ajouter à eth0 par une commande du type:
<pre>
ip -6 address add une-adresse-ipv6-de votre-plage/56 dev eth0
</pre>
Le /56 n'est pas absolument nécessaire, il évite juste de rajouter une route plus spécifique pour atteindre votre nouvelle adresse IPv6 depuis votre VM, route qui s'avère redondante.
Le lecteur attentif aura noté que cette configuration déclare que toutes les adresses de votre plage sont situées derrière eth0, en dehors de la partie contrôlée par votre VM, et il semble impossible alors d'en distraire une partie. Il y a au moins deux solutions à ce problème:
# S'arranger pour que les segments réseau de votre domicile fassent partie de celui partant de eth0 sur la VM. Celà revient techniquement à bridger ces segments réseaux. Cette solution a cependant des inconvénients en terme de configurabilité et de sécurité.
# Réduire la plage IPv6 allouée derrière l'eth0 de la VM et réallouer le solde à votre réseau local maison, par des techniques de routage. C'est ce qu'on va décrire dans la suite. Mais d'abord, on a besoin d'un peu de collaboration de Tetaneutral.
h3. Etape 2: faire router votre plage /56 par Tetaneutral.
Dans la configuration par défaut des VM Tetaneutral, l'hôte des VM crée la route vers l'adresse 2a01:6600:80XX:YY00::1 (et des autres que vous rajoutez éventuellement à la main sur eth0) par l'utilisation de l'équivalent IPv6 d'ARP. Il est donc impossible de router vers une adresse qui n'existe pas sur cet eth0.
Tetaneutral doit donc rajouter une route explicite:
<pre>
ip -6 route add 2a01:6600:80XX:YY00::/56 via fe80::XX:YY dev votre-eth0-côté-hôte
</pre>
Celà n'a de sens que si fe80::XX:YY une des adresses de l'eth0 côté VM. Il faut donc l'ajouter et le mieux est de le faire via une directive 'up' dans /etc/network/interfaces:
<pre>
iface eth0 inet6 static
address 2a01:6600:80XX:YY00::1
netmask 64
gateway fe80::31
up ip -6 add add fe80::XX:YY dev eth0
</pre>
Mon lecteur toujours très attentif n'aura pas manqué de noter que netmask ci-dessus est passé de 56 à 64. Nous n'allouons donc maintenant plus toutes nos adresses IPv6 sur le segment réseau partant d'eth0. En particulier, nous allons voir maintenant comment récupérer 2a01:6600:80XX:YY01::/64 pour notre réseau à domicile.
+Remarque:+ la sous-plage doit être /64 au minimum, sinon l'adressage automatique des interfaces réseau qu'on verra plus loin ne marchera pas.
h3. Etape 3: simuler un lien ethernet entre une machine à domicile la maison et cette VM.
Les technologies VPN/tunnel sont le pendant réseau des machines virtuelles: elles permettent de créer des interfaces réseaux virtuelles (du point de vue hardware, mais bien réelles d'un point de vue logiciel) et de les connecter entre elles.
Tout comme les machines virtuelles nécessitent quand même un minimum de support silicium, un VPN/tunnel va nécessiter de s'appuyer sur une vraie liaison entre deux vraies interfaces réseau, en l'occurence pour nous la liaison internet IPv4 entre autre utilisée pour l'administration de la VM depuis votre domicile. Plus précisément, nous allons utiliser l'outil openvpn.
La première étape va consister à installer openvpn en mode serveur sur la VM. Le fichier suivant est à créer dans /etc/openvpn/myris.conf:
<pre>
dev tap
proto udp
local 91.224.xx.yy
float
ca myris/ca.crt
cert myris/myris.crt
key myris/myris.key
dh myris/dh1024.pem
tls-server
port 1194
ping 15
ping-restart 45
# car serveur
ping-timer-rem
persist-tun
persist-key
verb 0
ifconfig 10.0.0.2 255.255.255.252
route ipv4-adresse-client-openvpn-domicile 255.255.255.255 10.0.0.1
script-security 3 system
route-up "/sbin/ip -6 addr add 2a01:6600:80XX:YY01::1/64 dev tap0"
</pre>
+Remarque:+ le paramètre route-up contient le nom 'tap0' codé en dur, ce qui n'est pas portable. Cette commande est nécessaire pour créer sur la VM une route vers la bonne interface pour la plage 2a01:6600:80XX:YY01::/64. Pour que le serveur openvpn soit toujours présent, il faut ajouter
<pre>
AUTOSTART="myris"
</pre>
à /etc/default/openvpn.
Sur la machine à domicile, il faut une installation en mode client, pourquoi pas le même nom de fichier que le serveur, mais pas le même contenu:
<pre>
dev tap
proto udp
local ipv4-adresse-client-openvpn-domicile
remote 91.224.xx.yy
ca myris/ca.crt
cert myris/client.crt
key myris/client.key
tls-client
port 1194
ping 15
ping-restart 45
persist-tun
persist-key
verb 0
ifconfig 10.0.0.1 255.255.255.252
route 0.0.0.0 0.0.0.0 10.0.0.2
</pre>
Il est supposé bien sûr dans l'exemple ci-dessus que vous n'utilisez pas 10.0.0.0/30 chez vous. Les répertoires /etc/openvpn/myris sur VM et machine cliente contiendront les divers certificats et clés, qu'il faut générer.
h3. Etape 4: passer la VM en mode routeur et annoncer des routes pour votre réseau à domicile avec radvd.
Pour autoriser les paquets à être routés sur la VM entre eth0 et tap0, il faut passer en mode routeur:
<pre>
echo 1 >/proc/sys/net/ipv6/conf/default/forwarding
</pre>
Nous allons maintenant mettre en place une configuration automatique d'adresses IPv6 de toutes les machines du segment réseau partant du tap0 de la VM (soit le tap0 du client openvpn, mais après l'étape suivante toutes les interfaces de votre réseau local). Nous utiliserons pour celà l'outil radvd, avec le fichier de configuration /etc/radvd.conf:
<pre>
interface tap0
{
IgnoreIfMissing on;
AdvSendAdvert on;
AdvLinkMTU 1280;
prefix 2a01:6600:80XX:YY01::/64
{
AdvOnLink on;
AdvAutonomous on;
};
};
</pre>
+Remarque:+ le fichier contient le nom 'tap0' codé en dur, ce qui n'est pas portable. Par ailleurs, il est possible d'interdire à une machine de s'autoconfigurer, mais ce n'est pas le défaut pour Linux et j'ai supposé que vous ne l'avez pas modifié.
h3. Etape 5: bridger les interfaces réseau du client openvpn l'"ethernet" entre votre machine à la maison et la VM, avec celui de votre domicile
A ce stade, la machine openvpn cliente peut accéder l'internet IPv6, car radvd aura placé une route par défaut via son tap0. Si vous bridgez maintenant ce tap0 avec son eth0 (normalement relié au reste de votre réseau local), toutes les machines de ce réseau local vont s'assigner au bout de quelques minutes une adresse tirée de la plage 2a01:6600:80XX:YY01::/64, et une route par défaut via le tap0 du client openvpn: c'est ce qu'on voulait obtenir.
Voici les incantations magiques nécessaires:
<pre>
# on suppose qu'eth0 a l'adresse 192.168.0.1/24
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 tap0
# à ce stade, le machine hébergeant le client openvpn n'est plus adressable
# mais il est dans la plupart des cas utile de lui en redonner une, en général celle d'eth0
ip addr add 192.168.0.1/24 dev br0
</pre>
h2. FAQ
* How to ping the link-local gateway?
Using scoped addresses:
<pre>
ping6 fe80::31%eth0
</pre>
Information about IPv6
Issue #35
h2. Links
General
* http://en.wikipedia.org/wiki/ICMPv6
* http://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol
* http://en.wikipedia.org/wiki/Radvd
* http://en.wikipedia.org/wiki/DHCPv6
Linux
* http://madduck.net/docs/ipv6/
* http://tldp.org/HOWTO/Linux+IPv6-HOWTO/
h2. How to enable routing for /56 ?
Currently each IPv4 delivered by tetaneutral.net is matched by a /56 IPv6 (mapping /24 = 256 IPv4 <=> /48 = 256 /56 IPv6).
As tetaneutral.net is a simple flat ethernet network, all machines are on the same broadcast domain. In order to route /56s we must :
- Assign interconexion subnets. Current recommendation is to provide /112s matched to (but outside) of the corresponding /56
- Add a local static route for this subnet to h3 and gw (admin required)
h2. Discussions
> J'ai fait quelques essais: VM configuré en routeur, openvpn entre la VM
> et ma machine, histoire de simuler des interfaces. J'ai essayé radvd
> comme des définitions manuelles des adresses IPv6.
>
> Bon, ça marche depuis la VM mais pas depuis chez moi (wget
> http://ipv6.google.com), même si les paquets IPv6 (vu avec tcpdump)
> partent bien de la VM vers l'internet. Mais il n'y a pas de retour.
>
> Après quelques cogitations et la lecture de ceci:
> http://www.fdn.fr/IPv6-a-la-maison.html j'en arrive à ces
> réflexions:
>
> 1) Dans le blog FDN ci-dessus l'adresse IPv6 affectée au ppp0 n'est pas
> dans son /48; ce qui voudrait dire qu'il n'y a pas de raison d'affecter
> une IPv6 du /56 au eth0 des VM tetaneutral.
>
> 2) Pour faire marcher une telle config à FDN, le routeur FDN en amont du
> modem/routeur de l'abonné devrait avoir une route du type:
> ip -6 route add range/48 dev ppp-abonné via link-local-ppp-abonné
> soit chez nous:
> ip -6 route add range/56 dev eth0-vm via link-local-eth0-vm
>
> > du /56 via une interconnection explicite entre le routeur de
> > tetaneutral.net et un routeur chez le membre ?
>
> Un lien openvpn?
Bonsoir,
On peut rajouter une regle de routage comme tu le suggere,
reste a choisir les details pratiques.
Pour la link-local coté routeur on a choisi fe80::31 en statique il
reste a choisir une regle pour attribuer le link local coté client.
Une regle automatique basée sur l'IPv4 est en place pour
l'attribution du subnet IPv6 :
http://wiki.tetaneutral.net/index.php/Architecture
Une regle similaire pour le routage donnerait par exemple fe80::81:XY
ou XY est le dernier octet de l'IPv4 ecrit en hexadecimal
pour la link local coté client.
L'avantage d'une regle statique vs le SLAAC c'est que c'est un peu plus
flexible coté client sur le choix de l'equipement routeur.
L'avantage du routé est bien sur la flexibilité et la sécurisation
potentielle, l'inconvenient est qu'avec nos equipements actuels peu
puissant on perdra un peu en debit mais ça se corrigera avec
de nouveaux equipements.
Je suis vraiment curieux de savoir comment font les autres hebergeurs
dans le monde IPv6, ceux auxquels j'ai acces ne proposent pas de
routage, simplement ce que propose tetaneutral.net actuellement.
Suggestions ?
h2. Connectivité IPv6 complète depuis chez vous en quelques étapes simples +(en cours d'édition)+
Connectivité complète signifie que toutes vos machines pouvant fonctionner en IPv6 peuvent accéder des sites IPv6 externes mais surtout être joignables de l'extérieur sur une adresse IPv6 propre. Pas de NAT ou autre bidouille de ce genre. Implications en terme d'autohébergement et sécurité laissées en exercice.
Pour bien comprendre ce qui suit, il est recommandé d'avoir un peu potassé les hyperliens plus haut et mieux encore d'avoir joué avec l'IPv6 sur votre réseau local maison en utilisant par exemple des adresses ULA.
h3. Etape 1: obtenir une machine virtuelle Tetaneutral.
Celle-ci (on l'appellera VM dans la suite) sera configurée par défaut comme suit dans /etc/network/interfaces du point de vue IPv6:
<pre>
iface eth0 inet6 static
address 2a01:6600:80XX:YY00::1
netmask 56
gateway fe80::31
</pre>
où XX et YY sont les versions hexadécimales des xx et yy décimaux de votre (unique!) adresse IPv4 de la forme 91.224.xx.yy.
Voyons ce qu'implique la prise en compte par le système de ce fragment de /etc/network/interfaces. Il dit que:
# l'adresse 2a01:6600:80XX:YY00::1 est affectée à eth0, ce qui signifie que votre VM est accessible à cette adresse depuis l'intérieur de la VM comme depuis l'extérieur par toutes les machines du même segment réseau que eth0
# les paquets passant par votre VM peuvent atteindre les adresses de la plage 2a01:6600:80XX:YY00::/56 en étant envoyés en sortie de l'interface eth0
La plage 2a01:6600:80XX:YY00::/56 a été allouée par tetaneutral à votre VM. Notre problème est d'allouer une partie de ces adresses à des machines de notre domicile en utilisant l'accès que nous avons (en IPv4!) à la VM.
Avec cette configuration, vous pouvez héberger sur la VM des milliards de serveurs avec des adresses IPv6 différentes, il suffit de les ajouter à eth0 par une commande du type:
<pre>
ip -6 address add une-adresse-ipv6-de votre-plage/56 dev eth0
</pre>
Le /56 n'est pas absolument nécessaire, il évite juste de rajouter une route plus spécifique pour atteindre votre nouvelle adresse IPv6 depuis votre VM, route qui s'avère redondante.
Le lecteur attentif aura noté que cette configuration déclare que toutes les adresses de votre plage sont situées derrière eth0, en dehors de la partie contrôlée par votre VM, et il semble impossible alors d'en distraire une partie. Il y a au moins deux solutions à ce problème:
# S'arranger pour que les segments réseau de votre domicile fassent partie de celui partant de eth0 sur la VM. Celà revient techniquement à bridger ces segments réseaux. Cette solution a cependant des inconvénients en terme de configurabilité et de sécurité.
# Réduire la plage IPv6 allouée derrière l'eth0 de la VM et réallouer le solde à votre réseau local maison, par des techniques de routage. C'est ce qu'on va décrire dans la suite. Mais d'abord, on a besoin d'un peu de collaboration de Tetaneutral.
h3. Etape 2: faire router votre plage /56 par Tetaneutral.
Dans la configuration par défaut des VM Tetaneutral, l'hôte des VM crée la route vers l'adresse 2a01:6600:80XX:YY00::1 (et des autres que vous rajoutez éventuellement à la main sur eth0) par l'utilisation de l'équivalent IPv6 d'ARP. Il est donc impossible de router vers une adresse qui n'existe pas sur cet eth0.
Tetaneutral doit donc rajouter une route explicite:
<pre>
ip -6 route add 2a01:6600:80XX:YY00::/56 via fe80::XX:YY dev votre-eth0-côté-hôte
</pre>
Celà n'a de sens que si fe80::XX:YY une des adresses de l'eth0 côté VM. Il faut donc l'ajouter et le mieux est de le faire via une directive 'up' dans /etc/network/interfaces:
<pre>
iface eth0 inet6 static
address 2a01:6600:80XX:YY00::1
netmask 64
gateway fe80::31
up ip -6 add add fe80::XX:YY dev eth0
</pre>
Mon lecteur toujours très attentif n'aura pas manqué de noter que netmask ci-dessus est passé de 56 à 64. Nous n'allouons donc maintenant plus toutes nos adresses IPv6 sur le segment réseau partant d'eth0. En particulier, nous allons voir maintenant comment récupérer 2a01:6600:80XX:YY01::/64 pour notre réseau à domicile.
+Remarque:+ la sous-plage doit être /64 au minimum, sinon l'adressage automatique des interfaces réseau qu'on verra plus loin ne marchera pas.
h3. Etape 3: simuler un lien ethernet entre une machine à domicile la maison et cette VM.
Les technologies VPN/tunnel sont le pendant réseau des machines virtuelles: elles permettent de créer des interfaces réseaux virtuelles (du point de vue hardware, mais bien réelles d'un point de vue logiciel) et de les connecter entre elles.
Tout comme les machines virtuelles nécessitent quand même un minimum de support silicium, un VPN/tunnel va nécessiter de s'appuyer sur une vraie liaison entre deux vraies interfaces réseau, en l'occurence pour nous la liaison internet IPv4 entre autre utilisée pour l'administration de la VM depuis votre domicile. Plus précisément, nous allons utiliser l'outil openvpn.
La première étape va consister à installer openvpn en mode serveur sur la VM. Le fichier suivant est à créer dans /etc/openvpn/myris.conf:
<pre>
dev tap
proto udp
local 91.224.xx.yy
float
ca myris/ca.crt
cert myris/myris.crt
key myris/myris.key
dh myris/dh1024.pem
tls-server
port 1194
ping 15
ping-restart 45
# car serveur
ping-timer-rem
persist-tun
persist-key
verb 0
ifconfig 10.0.0.2 255.255.255.252
route ipv4-adresse-client-openvpn-domicile 255.255.255.255 10.0.0.1
script-security 3 system
route-up "/sbin/ip -6 addr add 2a01:6600:80XX:YY01::1/64 dev tap0"
</pre>
+Remarque:+ le paramètre route-up contient le nom 'tap0' codé en dur, ce qui n'est pas portable. Cette commande est nécessaire pour créer sur la VM une route vers la bonne interface pour la plage 2a01:6600:80XX:YY01::/64. Pour que le serveur openvpn soit toujours présent, il faut ajouter
<pre>
AUTOSTART="myris"
</pre>
à /etc/default/openvpn.
Sur la machine à domicile, il faut une installation en mode client, pourquoi pas le même nom de fichier que le serveur, mais pas le même contenu:
<pre>
dev tap
proto udp
local ipv4-adresse-client-openvpn-domicile
remote 91.224.xx.yy
ca myris/ca.crt
cert myris/client.crt
key myris/client.key
tls-client
port 1194
ping 15
ping-restart 45
persist-tun
persist-key
verb 0
ifconfig 10.0.0.1 255.255.255.252
route 0.0.0.0 0.0.0.0 10.0.0.2
</pre>
Il est supposé bien sûr dans l'exemple ci-dessus que vous n'utilisez pas 10.0.0.0/30 chez vous. Les répertoires /etc/openvpn/myris sur VM et machine cliente contiendront les divers certificats et clés, qu'il faut générer.
h3. Etape 4: passer la VM en mode routeur et annoncer des routes pour votre réseau à domicile avec radvd.
Pour autoriser les paquets à être routés sur la VM entre eth0 et tap0, il faut passer en mode routeur:
<pre>
echo 1 >/proc/sys/net/ipv6/conf/default/forwarding
</pre>
Nous allons maintenant mettre en place une configuration automatique d'adresses IPv6 de toutes les machines du segment réseau partant du tap0 de la VM (soit le tap0 du client openvpn, mais après l'étape suivante toutes les interfaces de votre réseau local). Nous utiliserons pour celà l'outil radvd, avec le fichier de configuration /etc/radvd.conf:
<pre>
interface tap0
{
IgnoreIfMissing on;
AdvSendAdvert on;
AdvLinkMTU 1280;
prefix 2a01:6600:80XX:YY01::/64
{
AdvOnLink on;
AdvAutonomous on;
};
};
</pre>
+Remarque:+ le fichier contient le nom 'tap0' codé en dur, ce qui n'est pas portable. Par ailleurs, il est possible d'interdire à une machine de s'autoconfigurer, mais ce n'est pas le défaut pour Linux et j'ai supposé que vous ne l'avez pas modifié.
h3. Etape 5: bridger les interfaces réseau du client openvpn l'"ethernet" entre votre machine à la maison et la VM, avec celui de votre domicile
A ce stade, la machine openvpn cliente peut accéder l'internet IPv6, car radvd aura placé une route par défaut via son tap0. Si vous bridgez maintenant ce tap0 avec son eth0 (normalement relié au reste de votre réseau local), toutes les machines de ce réseau local vont s'assigner au bout de quelques minutes une adresse tirée de la plage 2a01:6600:80XX:YY01::/64, et une route par défaut via le tap0 du client openvpn: c'est ce qu'on voulait obtenir.
Voici les incantations magiques nécessaires:
<pre>
# on suppose qu'eth0 a l'adresse 192.168.0.1/24
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 tap0
# à ce stade, le machine hébergeant le client openvpn n'est plus adressable
# mais il est dans la plupart des cas utile de lui en redonner une, en général celle d'eth0
ip addr add 192.168.0.1/24 dev br0
</pre>
h2. FAQ
* How to ping the link-local gateway?
Using scoped addresses:
<pre>
ping6 fe80::31%eth0
</pre>