IPV4/IPV6 cohabitation?

Support Debian
#1

Bon, j’ai donc à l’heure actuelle un système comme suit:

Une passerelle ayant 2 interfaces réseau physique:

eth1 sur IP public
eth0 coté LAN

Un freebox monté en bridge (coté eth1 donc).

Le routage à l’heure actuelle est comme suit:

10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
10.8.1.0        0.0.0.0         255.255.255.0   U     0      0        0 tap1
82.66.248.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         82.66.248.254   0.0.0.0         UG    0      0        0 eth1

et les interfaces sont (loopback exceptée)

[code]tap0 Link encap:Ethernet HWaddr 00:01:c0:04:11:f6
adr inet6: fe80::2ff:28ff:fe9d:5ad5/64 Scope:Lien

eth0 Link encap:Ethernet HWaddr 00:01:c0:04:11:f6
adr inet6: fe80::201:c0ff:fe04:11f6/64 Scope:Lien

br0 Link encap:Ethernet HWaddr 00:01:c0:04:11:f6
inet adr:192.168.1.251 Bcast:192.168.1.255 Masque:255.255.255.0
(pont regroupant les deux prédentes)

eth1 Link encap:Ethernet HWaddr 00:01:c0:04:30:1c
inet adr:82.66.248.156 Bcast:82.66.248.255 Masque:255.255.255.0

tap1 Link encap:Ethernet HWaddr 00:ff:a5:db:4f:ff
inet adr:10.8.1.1 Bcast:10.8.1.255 Masque:255.255.255.0

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet adr:10.8.0.1 P-t-P:10.8.0.2 Masque:255.255.255.255

(2 VPNS suppléméntaires)
[/code]
J’ai des règles assez simples, mais longues:

iptables-save | grep -c “”

267
donc je ne met pas tout (il y a des règles bloquant les gars abusant du serveur NTP)

Mais en gros, on y trouve des règles type de celles pour le port 8080

-A MONLIMITEUR-OUT -p tcp -m tcp --sport 8080 -j MARK --set-xmark 0x19/0xffffffff
-A PREROUTING -d 82.66.248.156/32 -i br0 -p tcp -m state --state NEW,RELATED,ESTABLISHED -m tcp --dport 8080 -j DNAT --to-destination 192.168.1.248:8080
-A PREROUTING -i eth1 -p tcp -m state --state NEW,RELATED,ESTABLISHED -m tcp --dport 8080 -j DNAT --to-destination 192.168.1.248:8080
-A POSTROUTING -s 192.168.1.0/24 -o br0 -p tcp -m tcp --dport 8080 -j MASQUERADE
-A FORWARD -s 192.168.1.240/32 -p tcp -m tcp --dport 8080 -j ACCEPT

ici routage typique d’un port en tcp vers une machine, la première règle est pour la gestion du QoS, et les 2ième + 4ième pour permettre aux requêtes venant du LAN de fonctionner. La dernière est un routeur WIFI.

et bien évidemment il y a une règle
-A POSTROUTING -o eth1 -j MASQUERADE

pour l’accès à internet du LAN.

La question est de savoir comme nt faire cohabiter une telle configuration avec l’IPV6. Dans un tel cas, il faut que les paquets en IPV4 soit «masqués» mais pas ceux en IPV6. J’ai vu que dans un tel cas, une solution était de faire un pont entre l’interface LAN et l’interface vers l’exterieur et de virer du pont avec ebtables les paquets IPV4, ceux ci vont donc vers eth0/eth1 et subissent les règles anciennes (je ne savais pas que c’était possible mais admettons). Que faire lorsque l’interface LAN est déjà dans un pont? En fait je ne vois pas comment faire cohabiter IPV4 et IPV6 dans une telle configuration, cela dans l’éventualité où je passerais en IPV6 (à vue de nez, ça n’est pas demain!)

#2

Bon, je suppose que tu connais déjà http://ip6.fr/free-broute/ pour pouvoir bénéficier de l’IPv6 de la freebox derrière un routeur IPv4 basé sur Linux en le transformant en pont pour l’IPv6.

[code]#Commençons par créer ce pont virtuel :
brctl addbr br0
ifconfig br0 up

On intègre à ce pont les deux interfaces :

brctl addif br0 eth0
brctl addif br0 eth1

Ajoutons la règle (brouting) permettant d’utiliser le pont uniquement pour l’IPv6 :

ebtables -t broute -A BROUTING -p ! ipv6 -j DROP[/code]

Dans ta situation où il y a déjà un pont côté LAN, ça se complique. Il se trouve que récemment un freenaute avait déjà posé la question dans un newsgroup de Free, et après avoir un peu cogité je lui avais suggéré la variation suivante consistant aussi à ajouter l’interface WAN (eth1) au pont mais en lui interdisant tout trafic IPv4/ARP (en fait non IPv6) ponté :

ebtables -t broute -A BROUTING -p ! ipv6 -i eth1 -j DROP ebtables -A FORWARD -p ! ipv6 -o eth1 -j DROP ebtables -A OUTPUT -p ! ipv6 -o eth1 -j DROP brctl addif br0 eth1
Ensuite, il faudra mettre en place le filtrage IPv6 si nécessaire.

#3

Commentaires hors sujet :

“wc -l” pour compter les lignes c’est pas plus simple que “grep -c” ?

[quote=“fran.b”]-A PREROUTING -d 82.66.248.156/32 -i br0 -p tcp -m state --state NEW,RELATED,ESTABLISHED -m tcp --dport 8080 -j DNAT --to-destination 192.168.1.248:8080
-A PREROUTING -i eth1 -p tcp -m state --state NEW,RELATED,ESTABLISHED -m tcp --dport 8080 -j DNAT --to-destination 192.168.1.248:8080[/quote]
Les paquets qui traversent les chaînes de la table nat sont forcément dans l’état NEW, donc il est inutile d’utiliser la correspondance state.

#4

Merci de ta réponse, pour ta première réponse, oui je pensais à ça, effectivement la solution proposée est logique, mais il faut que je lise le man de ebtables, que je ne connais absolument pas.

[quote=“PascalHambourg”]Commentaires hors sujet :

“wc -l” pour compter les lignes c’est pas plus simple que “grep -c” ?

[quote=“fran.b”]-A PREROUTING -d 82.66.248.156/32 -i br0 -p tcp -m state --state NEW,RELATED,ESTABLISHED -m tcp --dport 8080 -j DNAT --to-destination 192.168.1.248:8080
-A PREROUTING -i eth1 -p tcp -m state --state NEW,RELATED,ESTABLISHED -m tcp --dport 8080 -j DNAT --to-destination 192.168.1.248:8080[/quote]
Les paquets qui traversent les chaînes de la table nat sont forcément dans l’état NEW, donc il est inutile d’utiliser la correspondance state.[/quote]

C’est vrai que c’est logique là encore quand on y réfléchit, mais je ne le savais pas, du coup je le met(tais) à chaque fois.

#5

Globalement ebtables ressemble beaucoup à iptables, tu ne devrais pas être dépaysé.
Note : la machine ne fait pas de routage IPv6, pas besoin donc d’activer le forwarding IPv6 et sa seule interface configurée en IPv6 global est le pont br0.

#6

Bon, j’ai du passé en IPV6. Je n’avais pas fait ça avant. Plusieurs petites questions.

Tout d’abord pour Pascal: J’ai attentivement lu ce que tu avais dit. Dans mon cas (cf ci dessus, qui se résume à une interface eth1 sur l’extérieur et une autre (eth0) utilisée en bridge), on s’en sort en intégrant eth1 au pont (on a donc un pont contenant
eth1 + eth0 + tap0 (au lieu de br0 + eth0) et en mettant les règles suivantes:

ebtables -t broute -A BROUTING -p ! ipv6 -i eth1 -j DROPQui bloque le pont à tout ce qui vient de eth1 et n’est pas de l’IPV6.

qui bloque tout transfert du pont vers eth1 qui ne serait pas du IPV6. Cela oblige donc le trafic IPV4 à passer par le routage classique.

qui bloque tout paquet sortant par eth1 qui ne serait pas IPV6 (trafic utilisant le bridge). Tu vas dire si je me trompe, je vois bien que cela concerne le cas d’une paquet sortant IPV4 interdit en sortie sur eth1 qui pourraient sortir par eth1 parce que eth1 appartient au pont br0 et qu’il n’y aurait pas de règles interdisant la sortie par br0. Bon, d’accord. Mais en l’absence de cette règle, avec ce pont il y a deux possibilités pour le paquet de sortir: le pont br0 via eth1 donc (ce que cette règle veut interdire) et eth1 directement via le routage IPV4 classique (obligatoire dès que les paquets Ethernet sont bloqués).
Dans le cas où la règle ebtables n’est pas mise, est ce que le pont est systématiquement choisi parce que le noyau regarde systématiquement les règles de transfert possibles pour les paquets Ethernet (un pont n’est finalement que l’autorisation de transfert d’une interface à une autre, quand ça coince on remonte au niveau au dessus (IP) où le routage s’applique).

Edit: Les autres questions annoncées n’existent plus, en les rédigeant j’ai répondu moi même. Pour info il y avait entre autres un trafic IPV6 intense que je ne comprenais pas jusqu’à ce que je m’aperçoive qu’il s’agit d’une machine à Toulouse sur le VPN, VPN qui est sur le pont et donc dont les machines connectées bénéficient aussi d’une adresse IPV6 (je pensais à une machine externe dont je pouvais lire le trafic…)

PS: Un truc pour retenir une adresse IPV6?

#7

Lut,
Je ne suis pas sur de comprendre exactement le besoin.

Tu souhaites que l’IPv6 passe tel quel sur ton LAN ( un même L2 pour tout ton LAN)
Ou que l’IPv6 passe sur tes intersites et internet
ou les 2?

Ou j’ai pas compris :slightly_smiling: .

#8

Tout marche bien, mais je demande juste à Pascal une confirmation sur le fonctionnement des ponts, en gros que lorsque deux interfaces sont pontées, les règles iptables éventuelles sont court-circuitées (exemple d’un paquet bloqué en sortie sur eth1 mais qui sort quand même puisque eth0 et eth1 appartiennent à un pont br0).

Tant que j’y suis j’ai été étonné de devoir autoriser le forwarding IPV6 sur eth1 pour que les requêtes DHCP passent, mais là encore en y réfléchissant c’est logique. J’imagine que c’est la même chose pour le multicast.

#9

Non. Par défaut les règles iptables s’appliquent aussi aux paquets pontés.
Cf. les sysctl net.bridge.bridge-nf-call-*
Mais les règles ebtables DROP ont plus pour objet de bloquer les trames broadcast et multicast non IPv6 (notamment IPv4 et ARP) qui sont diffusées sur tous les ports du pont que de forcer leur routage. Côté LAN, le routage IPv4 intervient de façon classique.

Pas du tout. Je suis aussi étonné. Et surtout je ne vois pas le rapport entre le forwarding IPv6 et les requêtes DHCP, ça n’a rien de logique. Quelles requêtes DHCP, au juste ? Celles envoyées par eth1 à la freebox pour récupérer l’adresse IPv4 publique ?

Note :
Il y aurait maintenant des alternatives au pontage de l’IPv6.

  • Le NAT IPv6 avec un noyau et un iptables suffisamment récent. Que je ne recommande pas évidemment.
  • J’ai entendu dire que depuis peu il était possible d’utiliser les autres préfixes /64 du bloc /56 alloué. Jusqu’ici seul le premier était utilisé par l freebox et routé sur son interface LAN. S’il est effectivement possible de router un /64 vers un routeur IPv6, il n’y aurait plus besoin de pont.
#10

Non. Par défaut les règles iptables s’appliquent aussi aux paquets pontés.
Cf. les sysctl net.bridge.bridge-nf-call-*
Mais les règles ebtables DROP ont plus pour objet de bloquer les trames broadcast et multicast non IPv6 (notamment IPv4 et ARP) qui sont diffusées sur tous les ports du pont que de forcer leur routage. Côté LAN, le routage IPv4 intervient de façon classique.[/quote]
Je me souviens que tu en avais parlé pour le pont dans les VPN effectivement. Ça n’est pas logique que des règles jouant sur les paquets IP (OSI 3) interviennent au niveau Ethernet (OSI 2). Ça veut dire que je n’ai toujours pas compris ce qu’est un bridge.

[quote]

Pas du tout. Je suis aussi étonné. Et surtout je ne vois pas le rapport entre le forwarding IPv6 et les requêtes DHCP, ça n’a rien de logique. Quelles requêtes DHCP, au juste ? Celles envoyées par eth1 à la freebox pour récupérer l’adresse IPv4 publique ?[/quote]
Bon j’allais t’exposer le problème mais avec ce que tu viens de dire, je viens de constater que en interdisant le FORWARD les requêtes DHCP passent pour une machine reliée par cable mais pas par une machine reliée par WIFI, WIFI dont le point d’accès est sur une deuxième machine avec un pont wlan0+eth0. D’ici à ce que ça soit ce pont qui bloque puisque lesponts peuvent bloquer et que je me sois enmelé les pinceaux…
Je n’arrive pas à comprendre pourquoi on a mélangé le pontage avec le filtrage qui concerne plutôt le routage. C’est sans doute pratique mais ça rend le tout un peu fouilli…

#11

Ce n’est pas logique mais c’est utile quand on veut faire un pont filtrant et que les fonctionnalités limitées de filtrage IP d’ebtables ne suffisent pas. On peut même faire du suivi de connexion et du NAT sur les paquets IP pontés ! Apparamment cela a été jugé suffisamment utile au point que cette fonctionnalité est activée par défaut (tous les net.bridge.bridge-nf-call-* = 1). Je ne partage pas ce point de vue.

Le cheminement des paquets dans un pont est décrit dans le diagramme “packet flow in netfilter” inclus notamment dans la page Wikipédia d’iptables.

Si tu ne veux pas que netfilter voie les paquets pontés, il suffit de mettre les net.bridge.bridge-nf-call-* à 0. (Attention à la “race condition” si tu le fais dans /etc/sysctl.conf ou /etc/sysctl.d/, il faut que le module bridge soit déjà chargé pour que ces paramètres existent).

Par contre si tu veux faire du filtrage IPv6 avec ip6tables entre ton LAN et la box, la machine n’étant pas routeur IPv6 mais simple pont, il faudra laisser net.bridge.bridge-nf-call-ip6tables=1 et utiliser l’extension physdev pour identifier les interfaces physiques d’entrée et/ou de sortie.

#12

Les requêtes DHCP ne fonctionnent pas par du broadcast (avec donc du «forward»)?

Sinon c’est curieux: Une machine en filaire sur eth0 reçoit une adresse IPV6, une machine connecté à un point d’accès WIFI construit par une interface wlan0 pontée sur une interface eth0 sur une machine connectée au réseau filaire (et qui a donc eu une adresse IPV6) ne reçoit pas d’adresse IPV6:

Free <--- eth1. DHCP IPV4..eth0 ---> LAN <--- eth0 reçoit IPV6 de Free et IPV4 local ^ ___________ LAN aussi _______| v eth0 pontée avec wlan0 <+++ WIFI +++> wlan0 reçoit IPV4 local mais pas IPV6
Le deuxième pont est sur une machine avec ttes les variables /proc/sys/net/bridge/bridge-nf-call* contenant toutes 0.

#13

En IPv4 les requêtes DHCP initiales sont émises en broadcast. Je ne garantis pas pour les requêtes de renouvellement, qui pourraient être émises en unicast à l’adresse du serveur DHCP qui a accordé le bail puisque le client la connaît.
Mais quel rapport avec du “forward” ?

En IPv6 le broadcast n’est pas utilisé et remplacé par du multicast, donc je suppose que les requêtes DHCPv6 initiales sont émises en multicast. Mais ne l’ayant pas encore utilisé, je ne connais pas bien.

Mais tu n’as toujours pas répondu à ma question : quelles requêtes DHCP ?

  • Les requêtes DHCP en IPv4 émises par ton routeur-pont vers la freebox pour récupérer l’adresse IPv4 publique ?
  • Les requêtes DHCP en IPv4 émises par un poste du LAN (si tu as un serveur DHCP sur ton LAN ?
  • Les requêtes DHCPv6 émises par un poste du LAN (si tu as un serveur DHCPv6 sur ton LAN) ? A ma connaissance la freebox ne fait pas office de serveur DHCPv6, elle se contente d’émettre spontanément et sur demande des annonces RA (Router Advertisement) contenant notamment le préfixe IPv6 global que les postes connectés à son LAN peuvent utiliser pour générer une ou plusieurs adresses IPv6 globales par autoconfiguration sans état (SLAAC, activée par défaut si la machine n’est pas configurée en routeur IPv6).

Autre question : est-tu en train de parler d’un problème qui affecte le fonctionnement en IPv4 de ton réseau suite aux modifications que tu as effectuées pour la mise en place de l’IPv6, ou bien qui affecte spécifiquement le fonctionnement en IPv6 ?

Le DNS (ok, je sors).
Quel type d’adresse ? Pour son propre réseau on a surtout besoin de retenir des préfixes /64 voire plus courts. Les adresses importantes (serveurs) sont souvent configurées en statique et de la forme <préfixe>:<id_sous_reseau_court>::<id_machine_court>. Quand je dis “court”, c’est un ou deux chiffres maximum. Ou bien on prend le même nombre que le dernier octet de l’adresse IPv4.

#14

En IPv4 les requêtes DHCP initiales sont émises en broadcast. Je ne garantis pas pour les requêtes de renouvellement, qui pourraient être émises en unicast à l’adresse du serveur DHCP qui a accordé le bail puisque le client la connaît.
Mais quel rapport avec du “forward” ?
[/quote]
Il s’agit des requêtes IPV6 à destination de la freebox donc. Elles passent à travers le pont eth0 - eth1. Cela se voit sur un tcpdump.

hercule:/home/francois# tcpdump -i wlan0 ip6 and udp tcpdump: WARNING: wlan0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes 21:01:27.899363 IP6 fe80::f89b:d9e3:ea5:f73d.57576 > ff02::c.1900: UDP, length 146 21:01:28.324326 IP6 fe80::9eb7:dff:fe72:76be.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit 21:01:28.324422 IP6 fe80::9eb7:dff:fe72:76be.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit 21:01:29.334375 IP6 fe80::9eb7:dff:fe72:76be.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit 21:01:29.334479 IP6 fe80::9eb7:dff:fe72:76be.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit

En fait les règles actuelles sont

[code]*filter
:INPUT DROP [0:0]
:FORWARD DROP [4:776]
:OUTPUT ACCEPT [0:0]
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i tap0 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -p tcp -m state --state NEW,RELATED,ESTABLISHED -m tcp --dport 995 -j ACCEPT
-A INPUT -p tcp -m state --state NEW,RELATED,ESTABLISHED -m tcp --dport 994 -j ACCEPT
[…identiques à la ligne ci dessus au port prêt…]
-A FORWARD -p ipv6-icmp -j ACCEPT
COMMIT

Completed on Sun Sep 15 20:52:43 2013

[/code]
Si j’enlève la dernière ligne FORWARD, un machine branchée sur le réseau filaire reçoit une adresse IPV4 mais pas IPV6. En mettant la ligne, elle reçoit une adresse IPV6 (en + de l’IPV4 et sur la plage qui m’est allouée par Free et bien sûr différente de celles des autres machines). Dans la mesure où les paquets doivent traverser le pont et que les règles ip6tables s’appliquent, que le forward soit accepté me parait logique. Par contre pourquoi ce sont les paquets icmp6 et pourquoi le fait que les paquets UDP ne soient pas bloqués? Là il faut que j’approfondisse parce que pour le moment je n’en sais rien.

Ce sont ces requêtes qui coincent, elles sont transmises à la freebox et une adresse IPV6 dans ma plage lui est attribuée. Je n’ai pas de serveur IPV6. Ces requêtes marchent sur le réseau filaire à condition d’avoir la règle

-A FORWARD -p ipv6-icmp -j ACCEPT et na marchent pas sinon. Ces requêtes ne marchent pas à partir du WIFI, réseau dont le point d’accès est en pont avec une interface sur le réseau filaire (en clair le serveur DHCP IPV4 marche pour les 2). Sur la machine faisant point d’accès, il y a une adresse IPV6 et les /proc/sys/net/bridge/bridge-nf-call* sont à 0.

Non l’IPV4 fonctionne comme d’habitude et ne pose aucun souci. C’est juste un pbm ou plutôt une incomprehension de ma part sur ce qui se passe avec l’IPV6 (un problème signifierait que c’est anormal, ça je n’en sais rien).

[quote]

Le DNS (ok, je sors).[/quote]je me sens seul…[quote]
Quel type d’adresse ? Pour son propre réseau on a surtout besoin de retenir des préfixes /64 voire plus courts. Les adresses importantes (serveurs) sont souvent configurées en statique et de la forme <préfixe>:<id_sous_reseau_court>::<id_machine_court>. Quand je dis “court”, c’est un ou deux chiffres maximum. Ou bien on prend le même nombre que le dernier octet de l’adresse IPv4.[/quote]
Ben là, toutes les adresses IPV6 données par free sont sur 48 octets sur la même plage /64 bien sûr les 44 derniers octets qui changent d’une machine à l’autre (y compris les machines branchées sur le VPN, un copain à Toulouse m’a demandé pourquoi soudain ses machines (sur mon VPN) avaient soudain une IPV6…). Je pense que Free construit l’adresse IPV6 à partir de l’identifiant IPV6 de la machine envoyée lors de la requête lui même construit avec l’adresse MAC de la carte réseau.

Mais en fait je finis par reconnaître au moins celle de la passerelle IPV4 (comment il faut dire pour l’IPV6? ce serait plutôt un commutateur Ethernet intelligent à ce stade) au coup d’oeil dans un listing sans la connaître vraiment, c’est étonnant d’ailleurs.

#15

Ce n’est pas Free qui qui contruit l’adresse IPv6 à partir du préfixe et de l’adresse MAC, c’est l’hôte client lui-même, par autoconfiguration d’adresse sans état (Stateless Address Auto-Configuration ou SLAAC). En simplifiant, le processus est le suivant :

  • la freebox émet en multicast des annonces de routeur (Router Advertisement ou RA) périodiquement et en réponse à une sollicitation (Router Solictation ou RS) d’un hôte. Une annonce de routeur contient les préfixes IPv6 valides sur le réseau, l’adresse (link local généralement) du routeur, optionnellement des routes, des adresses de DNS (RDNSS)…
  • l’hôte envoie une sollicitation de routeur lorsqu’une interface en autoconf est activée afin de recevoir une annonce de routeur.
  • A réception de l’annonce de routeur, l’hôte crée une adresse IPv6 globale à partir du préfixe et de l’adresse MAC de l’interface et optionnellement une adresse IPv6 temporaire à partir du préfixe et d’un identifiant aléatoire (voir “privacy extensions” et net.ipv6.conf.*.use_tempaddr) renouvelée périodiquement.

“Sans état” fait référence au fait que le routeur ne maintient aucun état des adresses autoconfigurées (il ne les connaît même pas), contrairement à un serveur DHCP qui doit maintenir un état des baux alloués.
A ce propos, tout ce processus n’a rien à voir avec les requêtes DHCPv6, d’ailleurs dans tes captures de paquets tu ne vois aucune réponse de la box, normalement. Les annonces et sollications de routeur font partir du protocole NDP (Neighbour Discovery Protocol) qui est un sous-ensemble d’ICMPv6. C’est pourquoi l’autoconf ne fonctionne pas si on bloque les paquets ICMPv6.

Ce à quoi tu dois t’intéresser, ce sont les messages ICMPv6 de type Router Advertisement et Router Solicitation, suivre leur trajet sur les différentes interfaces traversées et voir où ça coince exactement dans le cas du wifi.

Concernant tes règles ip6tables sur le routeur-pont (ce qui signifie que tu as laissé bridge-nf-call-ip6tables=1 je suppose), il me semble que désigner les interfaces d’entrée ou de sortie comme tu le fais est incorrect car il s’agit des “ports” d’un pont. -i ou -o doivent désigner le l’interface pont, et l’interface “port” d’entrée ou de sortie doit être désignée avec physdev.
Accessoirement, si tu n’autorises que l’ICMPv6 dans FORWARD, tes postes ne doivent pas pouvoir faire grand chose en IPv6 à part récupérer une adresse et envoyer des pings.

Cela s’appelle un pont, tout simplement. Un commutateur est un pont multiport.
Tu reconnais son adresse probablement grâce la fin de l’adresse MAC, ça me le fait aussi avec certaines machines avec l’habitude. Mais pour les machines importantes, tu peux configurer une adresse IPv6 statique plus facile à retenir, par exemple <préfixe>::2 (pas <préfixe>::1, c’est la freebox), <préfixe>::3…

#16

Ce n’est pas Free qui qui contruit l’adresse IPv6 à partir du préfixe et de l’adresse MAC, c’est l’hôte client lui-même, […]n’a rien à voir avec les requêtes DHCPv6, d’ailleurs dans tes captures de paquets tu ne vois aucune réponse de la box, normalement. Les annonces et sollications de routeur font partir du protocole NDP (Neighbour Discovery Protocol) qui est un sous-ensemble d’ICMPv6. C’est pourquoi l’autoconf ne fonctionne pas si on bloque les paquets ICMPv6.
[/quote]J’ai compris. J’ignorais complètement ce mécanisme (plutôt astucieux je trouve). Ça explique beaucoup de choses.[quote]
Ce à quoi tu dois t’intéresser, ce sont les messages ICMPv6 de type Router Advertisement et Router Solicitation, suivre leur trajet sur les différentes interfaces traversées et voir où ça coince exactement dans le cas du wifi.
[/quote]
passerelle=cerbere (pont tap0+eth1+eth0)
point d’accès=hercule (pont eth0+wlan0, variables bridge* à 0, pas de règles iptables)

C’est assez étonnant, j’ai tracé tout ce qui n’est pas UDP et TCP sur les machines. Moralité les paquets icmp6 sont présents sur eth0, wlan0 (et br0) de la machine qui sert de point d’accès (hercule, tcpdump peut tracer un seul port d’entrée d’un pont, j’ai tout mis pour vérifier), par contre sur l’interface wlan0 de mon portable, aucun de ces paquets n’apparait.

Plus étonnant, si je met une adresse IPV6 à la main sur l’interface wlan0 du portable et je «ping6» ma passerelle, là ça passe bien entre les différentes machines pendant un laps de temps puis soudain ça ne passe plus sans que je fasse quoi que ce soit:

Voilà ce que ça donne sur le portable (6262 = hercule, 11f6 = cerbere, 13 = portos, j’ai modifié des octets de la plage IPV6), en gros au début hercule et cerbere répondent, tant que je fais des pings à partir de cerbere vers portos, les pings vers cerbere répondent toujours, par contre hercule se met à ne plus répondre. J’arrête les pings à partir de cerbere et là aucune des machines ne répond à l’autre:

[code]root@portos:/home/francois# ifconfig wlan0 inet6 add 2a01:a:b:c:d:e:fe04:13/64
root@portos:/home/francois# ping6 2a01:a:b:c:d:e:fe07:6262
PING 2a01:a:b:c:d:e:fe07:6262(2a01:a:b:c:d:e:fe07:6262) 56 data bytes
From 2a01:a:b:c:d:e:fe04:13 icmp_seq=1 Destination unreachable: Address unreachable
From 2a01:a:b:c:d:e:fe04:13 icmp_seq=2 Destination unreachable: Address unreachable
From 2a01:a:b:c:d:e:fe04:13 icmp_seq=3 Destination unreachable: Address unreachable
^C
— 2a01:a:b:c:d:e:fe07:6262 ping statistics —
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4000ms

root@portos:/home/francois# ping6 2a01:a:b:c:d:e:fe07:6d62
PING 2a01:a:b:c:d:e:fe07:6d62(2a01:a:b:c:d:e:fe07:6d62) 56 data bytes
64 bytes from 2a01:a:b:c:d:e:fe07:6d62: icmp_seq=1 ttl=64 time=3.38 ms
64 bytes from 2a01:a:b:c:d:e:fe07:6d62: icmp_seq=2 ttl=64 time=1.27 ms
64 bytes from 2a01:a:b:c:d:e:fe07:6d62: icmp_seq=3 ttl=64 time=1.19 ms
64 bytes from 2a01:a:b:c:d:e:fe07:6d62: icmp_seq=4 ttl=64 time=1.19 ms
64 bytes from 2a01:a:b:c:d:e:fe07:6d62: icmp_seq=5 ttl=64 time=1.21 ms
64 bytes from 2a01:a:b:c:d:e:fe07:6d62: icmp_seq=6 ttl=64 time=3.21 ms
64 bytes from 2a01:a:b:c:d:e:fe07:6d62: icmp_seq=7 ttl=255 time=1.32 ms
64 bytes from 2a01:a:b:c:d:e:fe07:6d62: icmp_seq=8 ttl=255 time=1.22 ms
^C
— 2a01:a:b:c:d:e:fe07:6d62 ping statistics —
8 packets transmitted, 8 received, 0% packet loss, time 7008ms
rtt min/avg/max/mdev = 1.195/1.752/3.384/0.895 ms
root@portos:/home/francois# ping6 2a01:a:b:c:d:e:fe07:6d62
PING 2a01:a:b:c:d:e:fe07:6d62(2a01:a:b:c:d:e:fe07:6d62) 56 data bytes
64 bytes from 2a01:a:b:c:d:e:fe07:6d62: icmp_seq=1 ttl=255 time=1.98 ms
64 bytes from 2a01:a:b:c:d:e:fe07:6d62: icmp_seq=2 ttl=255 time=1.28 ms
^C
— 2a01:a:b:c:d:e:fe07:6d62 ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.288/1.637/1.987/0.351 ms
root@portos:/home/francois# ping6 2a01:a:b:c:d:e:fe04:11f6
PING 2a01:a:b:c:d:e:fe04:11f6(2a01:a:b:c:d:e:fe04:11f6) 56 data bytes
64 bytes from 2a01:a:b:c:d:e:fe04:11f6: icmp_seq=1 ttl=64 time=4.97 ms
64 bytes from 2a01:a:b:c:d:e:fe04:11f6: icmp_seq=2 ttl=64 time=1.66 ms
64 bytes from 2a01:a:b:c:d:e:fe04:11f6: icmp_seq=3 ttl=64 time=1.55 ms
64 bytes from 2a01:a:b:c:d:e:fe04:11f6: icmp_seq=4 ttl=64 time=1.45 ms
64 bytes from 2a01:a:b:c:d:e:fe04:11f6: icmp_seq=5 ttl=64 time=1.47 ms
64 bytes from 2a01:a:b:c:d:e:fe04:11f6: icmp_seq=6 ttl=64 time=1.44 ms
64 bytes from 2a01:a:b:c:d:e:fe04:11f6: icmp_seq=7 ttl=64 time=1.98 ms
64 bytes from 2a01:a:b:c:d:e:fe04:11f6: icmp_seq=8 ttl=64 time=14.4 ms
^C
— 2a01:a:b:c:d:e:fe04:11f6 ping statistics —
8 packets transmitted, 8 received, 0% packet loss, time 7010ms
rtt min/avg/max/mdev = 1.440/3.624/14.446/4.241 ms
root@portos:/home/francois# ping6 2a01:a:b:c:d:e:fe07:6d62
PING 2a01:a:b:c:d:e:fe07:6d62(2a01:a:b:c:d:e:fe07:6d62) 56 data bytes
64 bytes from 2a01:a:b:c:d:e:fe07:6d62: icmp_seq=1 ttl=255 time=1.23 ms
64 bytes from 2a01:a:b:c:d:e:fe07:6d62: icmp_seq=2 ttl=255 time=1.27 ms
^C
— 2a01:a:b:c:d:e:fe07:6d62 ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.234/1.252/1.270/0.018 ms
root@portos:/home/francois#
root@portos:/home/francois# ping6 2a01:a:b:c:d:e:fe07:6d62
PING 2a01:a:b:c:d:e:fe07:6d62(2a01:a:b:c:d:e:fe07:6d62) 56 data bytes
^C
— 2a01:a:b:c:d:e:fe07:6d62 ping statistics —
9 packets transmitted, 0 received, 100% packet loss, time 8062ms

root@portos:/home/francois# ping6 2a01:a:b:c:d:e:fe04:11f6
PING 2a01:a:b:c:d:e:fe04:11f6(2a01:a:b:c:d:e:fe04:11f6) 56 data bytes
64 bytes from 2a01:a:b:c:d:e:fe04:11f6: icmp_seq=1 ttl=64 time=2.19 ms
64 bytes from 2a01:a:b:c:d:e:fe04:11f6: icmp_seq=2 ttl=64 time=1.53 ms
64 bytes from 2a01:a:b:c:d:e:fe04:11f6: icmp_seq=3 ttl=64 time=3.04 ms
64 bytes from 2a01:a:b:c:d:e:fe04:11f6: icmp_seq=4 ttl=64 time=1.30 ms
^C
— 2a01:a:b:c:d:e:fe04:11f6 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 1.306/2.020/3.041/0.674 ms
root@portos:/home/francois# ping6 2a01:a:b:c:d:e:fe07:6d62
PING 2a01:a:b:c:d:e:fe07:6d62(2a01:a:b:c:d:e:fe07:6d62) 56 data bytes
^C
— 2a01:a:b:c:d:e:fe07:6d62 ping statistics —
9 packets transmitted, 0 received, 100% packet loss, time 8062ms

root@portos:/home/francois# ping6 2a01:a:b:c:d:e:fe04:11f6
PING 2a01:a:b:c:d:e:fe04:11f6(2a01:a:b:c:d:e:fe04:11f6) 56 data bytes
64 bytes from 2a01:a:b:c:d:e:fe04:11f6: icmp_seq=1 ttl=64 time=1.39 ms
64 bytes from 2a01:a:b:c:d:e:fe04:11f6: icmp_seq=2 ttl=64 time=1.35 ms
^C
— 2a01:a:b:c:d:e:fe04:11f6 ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.358/1.378/1.399/0.042 ms
root@portos:/home/francois# ping6 2a01:a:b:c:d:e:fe04:11f6
PING 2a01:a:b:c:d:e:fe04:11f6(2a01:a:b:c:d:e:fe04:11f6) 56 data bytes
64 bytes from 2a01:a:b:c:d:e:fe04:11f6: icmp_seq=1 ttl=64 time=1.91 ms
64 bytes from 2a01:a:b:c:d:e:fe04:11f6: icmp_seq=2 ttl=64 time=4.52 ms
^C
— 2a01:a:b:c:d:e:fe04:11f6 ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.913/3.221/4.529/1.308 ms
root@portos:/home/francois# ping6 2a01:a:b:c:d:e:fe07:6d62
PING 2a01:a:b:c:d:e:fe07:6d62(2a01:a:b:c:d:e:fe07:6d62) 56 data bytes
^C
— 2a01:a:b:c:d:e:fe07:6d62 ping statistics —
14 packets transmitted, 0 received, 100% packet loss, time 1007ms

[Là j’attends 4-5 mn]
root@portos:/home/francois# ping6 2a01:a:b:c:d:e:fe04:11f6
PING 2a01:a:b:c:d:e:fe04:11f6(2a01:a:b:c:d:e:fe04:11f6) 56 data bytes
^C
— 2a01:a:b:c:d:e:fe04:11f6 ping statistics —
7 packets transmitted, 0 received, 100% packet loss, time 5999ms

root@portos:/home/francois#
[/code]

Sur hercule puis cerbere:

[code]francois@hercule:~$ ping6 2a01:a:b:c:d:e:fe04:13
PING 2a01:a:b:c:d:e:fe04:13(2a01:a:b:c:d:e:fe04:13) 56 data bytes
From 2a01:a:b:c:d:e:fe07:6d62 icmp_seq=1 Destination unreachable: Address unreachable
From 2a01:a:b:c:d:e:fe07:6d62 icmp_seq=2 Destination unreachable: Address unreachable
From 2a01:a:b:c:d:e:fe07:6d62 icmp_seq=5 Destination unreachable: Address unreachable
From 2a01:a:b:c:d:e:fe07:6d62 icmp_seq=6 Destination unreachable: Address unreachable
From 2a01:a:b:c:d:e:fe07:6d62 icmp_seq=7 Destination unreachable: Address unreachable
^C
— 2a01:a:b:c:d:e:fe04:13 ping statistics —
10 packets transmitted, 0 received, +5 errors, 100% packet loss, time 8999ms

francois@hercule:~$ logout
Connection to hercule closed.
francois@cerbere:~$ ping6 2a01:a:b:c:d:e:fe04:13
PING 2a01:a:b:c:d:e:fe04:13(2a01:a:b:c:d:e:fe04:13) 56 data bytes
64 bytes from 2a01:a:b:c:d:e:fe04:13: icmp_seq=1 ttl=64 time=2.10 ms
64 bytes from 2a01:a:b:c:d:e:fe04:13: icmp_seq=2 ttl=64 time=1.96 ms
64 bytes from 2a01:a:b:c:d:e:fe04:13: icmp_seq=3 ttl=64 time=2.06 ms
^C
— 2a01:a:b:c:d:e:fe04:13 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2010ms
rtt min/avg/max/mdev = 1.964/2.047/2.108/0.060 ms
francois@cerbere:~$ ping6 2a01:a:b:c:d:e:fe04:13
PING 2a01:a:b:c:d:e:fe04:13(2a01:a:b:c:d:e:fe04:13) 56 data bytes
From 2a01:a:b:c:d:e:fe07:6d62 icmp_seq=1 Destination unreachable: Address unreachable
From 2a01:a:b:c:d:e:fe07:6d62 icmp_seq=2 Destination unreachable: Address unreachable
From 2a01:a:b:c:d:e:fe07:6d62 icmp_seq=5 Destination unreachable: Address unreachable
…
[/code]

Tout se passe comme si cerbere et hercule savaient pendant un cours instant où est portos puis oublient sa localisation sauf si on leur fait faire un ping. Cela peut s’expliquer par le fait suivant: quand j’attribue à la main une adresse ipv6 à wlan0 de portos (le portable), cerbere et hercule reçoivent immédiatement les paquets

18:45:03.166566 IP6 :: > ff02::1:ff04:13: ICMP6, neighbor solicitation, who has 2a01:a:b:c:d:e:fe04:13, length 24 18:45:03.454562 IP6 fe80::207:cbff:fe48:3855 > ff02::1:ff04:11f6: ICMP6, neighbor solicitation, who has 2a01:a:b:c:d:e:fe04:11f6, length 32 18:45:03.454751 IP6 2a01:a:b:c:d:e:fe04:11f6 > fe80::207:cbff:fe48:3855: ICMP6, neighbor advertisement, tgt is 2a01:a:b:c:d:e:fe04:11f6, length 32 qui doivent temporairement mettre portos/IPV6 dans leurs tables et donc la rendre accessible pendant quelque temps.

Mais tout ça c’est des suppositions, j’avoue que ça me laisse perplexe, je ne comprends pas pourquoi les paquets «ICMP6, neighbor …» ne passent pas le WIFI. Car c’est finalement ce qui ressort de tout ça: tout passe le WIFI sauf ces paquets ce qui me parait (à peu près) expliquer le tout. Par ne pas passer le WIFI j’entends apparait sur wlan0 du point d’accès et pas sur wlan0 de la machine connectée.

[Si tu lis encore ce message, tu as droit à un whisky, faisant les manipulations en même temps que la rédaction du message, je ne suis pas sûr de sa clarté, courage c’est fini!]

[quote]

Concernant tes règles ip6tables sur le routeur-pont (ce qui signifie que tu as laissé bridge-nf-call-ip6tables=1 je suppose),[/quote]
oui

donc ce serait --physdev-in eth0 ou --physdev-in tap0. Je ne connaissais pas…

Oui, c’est transitoire, pour le moment j’essaye plutôt de comprendre le fonctionnement de l’IPV6.

#17

J’avoue que je n’ai pas analysé en détail tous tes résultats, mais les symptômes me font penser à un asymétrie d’acheminement des paquets ICMPv6 NDP, dont font également partie les types Neighbour Solicitation et Neighbour Advertisement qui sont l’équivalent pour IPv6 de ce qu’est le protocole ARP pour IPv6.

Il semble acquis que des paquets disparaissent au niveau de l’interface wlan0 du pont hercule. Mais il faudrait préciser quels types de paquets passent dans les deux sens, dans un seul sens. J’ai l’impression que le problème affecte seulement des paquets dans le sens hercule -> portos, mais c’est à vérifier. Egalement je soupçonne que ce sont les paquets multicast qui sont affectés.

Je te suggère d’utiliser les outils ndisc6 et rdisc6 du paquet ndisc6 plutôt que ping6, qui te permettront de contrôler exactement quels types de paquets NDP tu veux envoyer, et de suivre à la trace avec tcpdump sur chaque interface en même temps.

PS: Qui est fe80::207:cbff:fe48:3855 ? portos ?

#18

3855 = la freebox, en clair ce qu’il y a au bout (i.e 82.66.248.254 en IPV4) soit encore alfortville-5-82-66-248.

P=Portos, H=hercule
Les paquets routers solicitation: P -> H OK, H -> P Bloqué.
Les paquets routers adverstisement: H -> P Bloqué, P -> H non testé.

Les paquets neighbor solicitation: P -> H: OK, H -> P: Bloqué.
Les paquets neighbor advertisement: H -> P OK, P -> H: OK

En fait les paquets «solicitation» sont bloqués de Hercule vers Portos, et les réponses sont OK sauf pour les «routers adverstisement» de Hercule vers Portos (d’où l’impossibilité pour Portos de se trouver une adresse IPV6).

Je ne comprends pas pourquoi les ping ne marchent que pendant un court laps de temps de portos vers hercule…

#19

Si fe80…3855 est la freebox, je ne vois pas le lien entre l’attribution manuelle d’une adresse IPv6 à portos et la requête NDP de la freebox pour cerbere. Cela doit être une coïncidence.

Et je réalise seulement maintenant que hercule est 6d62 et non 6262, c’est pourquoi je ne comprenais pas les “host unreachable” sur 6262 (forcément, cette interface n’existe pas). Par contre je ne comprends pas pourquoi le TTL passe tout d’un coup de 64 à 255…

En tout cas tes dernières observations confirment ma première impression : les paquets perdus sont de type multicast (requêtes et RA) dans le sens hercule -> portos. Les RA ne sont pas vraiment des réponses, bien qu’ils puissent être émis en réponse à un RS ils sont toujours émis en multicast. Pour info les adresses multicast IPv6 sont dans le préfixe ff00::/8.

L’hypothèse que tu as formulée me semble plausible : les premiers paquets NDP émis par portos mettent son adresse dans le cache NDP des deux autres machines, mais ultérieurement lorsqu’elle envoient des requêtes NDP (perdues) pour renouveler le cache elles ne reçoivent pas de réponse, d’où les “host unreachable” lors des pings émis depuis ces machines. Par contre portos, qui reçoit les réponses, n’a pas de “host unreachable”, juste pas de réponse au ping parce que la cible ne sait pas comment l’envoyer.

#20

J’ai oublié le plus important… trouver l’origine du problème.
Deux possibilités : soit a) les paquets perdus ne sont pas émis par l’interface wifi d’hercule, soit b) ils sont émis mais pas reçus par portos.

Tests possibles :

  • connecter une autre machine en wifi à hercule, avec un autre type d’interface wifi de préférence et voir si elle reçoit les paquets multicast.
  • Connecter portos en wifi à un autre point d’accès, par exemple la freebox et voir si elle reçoit les paquets multicast.

S’il s’avère que le problème vient d’hercule, il faudrait regarder s’il persiste en sortant wlan0 du pont (avec config IPv6 manuelle puisqu’il n’y aura plus de RA). En effet il a été rapporté que certaines interfaces wifi ne fonctionnent pas très bien avec le pontage.