La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: renaud07 le 01 décembre 2022 à 20:06:46
-
Bonjour,
Je viens de tomber sur vieux bug de virtualbox, non résolu à ce jour, qui fait que l'IPv6 est inopérant en bridge lorsque l'hôte est connecté en wifi. Ça affecte en particulier Linux et appremment (c'est comme ça que je suis tombé dessus) les vieilles versions de windows (XP/2003). Bizarrement, un invité windows (à partir de vista) fonctionne sans problème puisque je ne m'étais rendu compte de rien jusqu'à présent.
A priori, ça serait lié aux paquets NS multicast, qui n’atteignent jamais la VM :
https://www.virtualbox.org/ticket/5503
https://www.virtualbox.org/ticket/14212
Si on se connecte en filaire, tout refonctionne instantanément.
La seule solution que j'ai trouvé et qui débloque la situation est de ping la GUA du routeur. Celui-ci répond à la GUA de la VM et cette fois ça marche.
Existe-t-il une solution plus pratique ? À part espérer une hypothétique correction...
Merci :)
-
> Bizarrement, un invité windows (à partir de vista) fonctionne sans problème puisque je ne m'étais rendu compte de rien jusqu'à présent
Tu pourrais faire une capture sur une telle VM pour essayer de comprendre pourquoi le bug ne se produit pas ? Je connais bien ce bug (j'ai pas mal travaillé dessus), je serai étonné que ca affecte un guest OS mais pas un autre.
-
Je vois que je ne pouvais pas mieux tomber :)
Voici les 2 captures :
-
OK, donc dans le cas du guest Windows, on voit bien des NS/NA pour une GUA, ce qu'on ne voit pas dans le cas de Linux.
On voit que les VM solicitent un routeur, recoivent un RA et configurent leurs adresses sur l'interface. Quand tu as fait tes captures, c'était juste après avoir activé la connexion réseau ? La VM démarre avec la connexion réseau désactivée dans ce cas ? Je demande pour savoir si on démarre avec un cache ND vide sur le routeur ou pas.
Je pars du principe que :
- ces captures ont été faites en wifi,
- tu n'as pas généré de traffic intentionnellement depuis les VM (comme faire un ping de la GUA du routeur) depuis le redémarrage de la VM,
- un hote sur le réseau (le routeur?) émet des NS pour la/les GUA/ULA configurées sur les VM.
J'ai bon ?
On ne voit aucun multicast ND de la part du routeur sur ces deux captures, mais on voit bien des échanges NS/NA unicast, ainsi que des router discovery (multicast) et unicast router advertisements. J'en déduis que :
- le patch a finalement été intégré à VirtualBox, car l'adresse MAC de la VM contenue dans les NA est bien remplacée par celle de ton interface Wifi (sinon, les échanges NS/NA unicast ne fonctionneraient pas). Tu devrais d'ailleurs pouvoir le vérifier en comparant les adresses MAC inclues dans les paquets NA émises par le guest de chaque côté du bridge VirtualBox (coté wifi et côté guest, donc) : elles devraient être différentes.
- les RS (router soliciation) émis par le guest en multicast arrivent bien à l'acces point (sinon, il n'y aurait pas de neighbor advertisements en retour),
- le guest ne recoit qu'une partie des paquets multicast recus par ton interface wifi.
Selon moi, ce qui sauve Windows, c'est qu'il émet des unsolicited neighbor advertisements juste après avoir configuré ses adresses (paquets #284 à 296 dans ta seconde capture).
Ces paquets sont émis en multicast et contiennent l'adresse MAC de la VM. Après leur réception par le point d'accès, ils contiennent l'adresse MAC de la carte wifi du host, et peuplent les caches ND de tous les hôtes qui les recoivent, dont le routeur.
Lorsque le routeur veut émettre un paquet vers la GUA du guest, il a déjà dans son cache ND une adresse MAC correspondant. Il peut donc envoyer le paquet en question sans avoir à faire une requête NS préalable, puis revalide périodiquement l'entrée de ce cache en faisant des requêtes NS unicast.
-> Il n'y a donc jamais de NS multicast émis par le routeur, et le traffic est acheminé correctement.
Dans ta capture Linux, ces unsolicited neighbor advertisements ne sont pas émis. Le routeur n'a donc pas d'entrée pour la GUA de la VM dans son cache ND, et doit donc émettre un NS multicast pour savoir à quelle adresse MAC le transmettre.
Ce paquet n'est jamais recu par ton guest, il n'y répond donc pas (logique). Le routeur timeout et jette le paquet original.
Maintenant, cherchons à résoudre le souci.
Normalement, VirtualBox devrait configurer ton interface wifi en "promiscuous", c'est à dire qu'elle désactive son filtre multicast et accepte toute trame multicast recue. Tu peux faire
$ ip link
et regarder les flags de ton interface (par exemple, chez moi, j'ai wlp2s0b1: <BROADCAST,MULTICAST,UP,LOWER_UP>).
Si le flag ALLMULTI n'est pas présent, ca n'a pas fonctionné. Tu peux faire
# ip link set $DEV allmulticast on
pour l'activer. Chez moi, ca donne wlp2s0b1: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP>.
Ensuite, refais une capture sur le guest. Est-ce que les NS multicast traversent le bridge VirtualBox cette fois ci ? Est-ce que ca résoud tes soucis de connectivité non sollicitée ?
-
Ouiiiiiii 8) Merci beaucoup !
En relisant le ticket de virtualbox hier soir, j'allais justement tester en mettant la carte en promiscous, tu m'as devancé^^ Et on a la réponse pour XP : il n'envoie pas non plus de NA en multicast, comme Linux donc.
Pour les paquets multicast sur 10, c'est les n°213 à 216 plutôt ? (vers ff02::1) Je vois pas de 284 à 296 (ou je regarde pas la bonne colonne ?)
On voit que les VM solicitent un routeur, recoivent un RA et configurent leurs adresses sur l'interface. Quand tu as fait tes captures, c'était juste après avoir activé la connexion réseau ? La VM démarre avec la connexion réseau désactivée dans ce cas ? Je demande pour savoir si on démarre avec un cache ND vide sur le routeur ou pas.
Je pars du principe que :
- ces captures ont été faites en wifi,
- tu n'as pas généré de traffic intentionnellement depuis les VM (comme faire un ping de la GUA du routeur) depuis le redémarrage de la VM,
- un hote sur le réseau (le routeur?) émet des NS pour la/les GUA/ULA configurées sur les VM.
J'ai bon ?
Yep
Par contre, il me reste toujours un petit soucis : impossible d'avoir de l'ipv6 à travers un routeur supplémentaire. Je voulais faire un sous réseau spécial VM (via pfsense ou un 2nd openwrt) comme sur mon deskop en filaire, sauf que ça marche pas... j'ai l'impression que c'est également lié au multicast, mais je comprends pas pourquoi ça passe pas. Sachant que je suis en réseau interne entre les VM et le routeur et le routeur en bridge.
-
Concernant mon problème de Pfsense, si je ping à partir d'une VM mon routeur principal : Les paquets partent bien, reviennent, mais n’atteignent jamais le pfsense.
J'ai essayé de faire des captures en switchant filaire-wifi, mais c'est pas évident...
-
Ouiiiiiii 8) Merci beaucoup !
Nice, donc ca marche. Et ca devrait marcher avec n'importe quel guest.
Pour les paquets multicast sur 10, c'est les n°213 à 216 plutôt ? (vers ff02::1) Je vois pas de 284 à 296 (ou je regarde pas la bonne colonne ?)
Oui, je ne sais pas d'où viennent mes numéros, j'avais clairement pas les yeux en face des trous :)
Si tu arrives à faire des captures, ca aidera grandement pour debugger ton nouveau souci.
-
Alors, j'ai essayé d'analyser une capture côté hôte, et... je ne vois rien de particulier. Hormis le fait que sur le wifi la MAC soit remplacée le reste semble identique. Je me demande s'il n'y aurait pas un problème avec le mécanisme de VB. Car comment VB détermine s'il faut envoyer le paquet à la VM ou non ? Y'a une correspondance IP <-> MAC ?
Ce que je suppose : comme les paquets retours arrivent avec la MAC de la carte wifi, il doit remplacer celle-ci par la MAC du pfsense en cherchant dans sa table. Sauf que pour les VM situées derrière le pfsense, l'IP étant différente et la MAC wan du pfsense déjà associée à son IP, il considère qu'elle est inconnue et ignore le paquet.
Ça se tient ? ou c'est pas du tout comme ça que ça fonctionne ?
Je te laisse les captures entières, si jamais tu trouves quelque chose... pour t'y retrouver :
-b05b : pfsense
-c2d2 : routeur principal
-9400 : préfixe principal
-9402 : préfixe délégué
-
À court d'idées, j'ai essayé avec Vmware workstation. Dans le ticket il était évoqué que ça fonctionnait sans problème, et... ÇA MARCHE !
En faisant un capture côté hôte, j'ai trouvé un truc intéressant : les paquets sont "dupliqués" et systématiquement sur le premier on retrouve la MAC de la VM, alors que sur le second apparaît celle de l'interface wifi. Avec vmware, les deux paquets ont tous les deux l'@MAC de la carte wifi, à aucun moment la MAC de la VM n'est visible. Même histoire avec l'échange NS/NA juste avant le ping.
-
J'ai un peu perdu le fil, désolé.
Donc tu veux mettre un pfSense dans une VM et lui router un /64 (je suppose) de ton /56 attribué par Orange.
Derrière ce pfSense (qui aurait deux interfaces: une bridgée à ton LAN, soit par cable, soit en wifi, et l'autre vers un bridge virtuel), il y aurait d'autrs VM, qui seraient uniquement connectées à la seconde interface du pfSense.
Orange <-> routeur physique <-> host <-> pfsense virtualisé <-> autre vm derrière le pfsense
J'ai bon ?
La duplication des paquets, ca sent pas bon. On dirait que les VM sensées être derrière le pfSense étaient bridgées au LAN. C'est possible ? Ou est-ce que ton pfSense a bien deux interfaces réseau différentes ?
-
> Y'a une correspondance IP <-> MAC ?
Yep, c'est du MAC NAT. On ne touche pas aux adresses IP, mais dans le sens vm -> net, on remplace l'adresse source MAC des VM par celle de l'interface wifi du host.
Dans le sens net -> vm. on fait l'inverse : on remplace l'adresse MAC de destination (celle de l'interface wifi du host, donc) par celle de la VM.
Comme VirtualBox a besoin de savoir quelle adresse MAC utiliser pour faire le remplacement dans le sens net -> vm, il lui faut un identifiant qui ne change pas : c'est l'adresse IP. Il maintient donc une table dynamique d'associations entre IP<->MAC, qu'il maintient passivement, en observant le traffic IMCPv6 NS/NA.
En gros, c'est le même principe que du NAT L3 (IP), sauf c'est du NAT au niveau L2.
-
Donc tu veux mettre un pfSense dans une VM et lui router un /64 (je suppose) de ton /56 attribué par Orange.
Derrière ce pfSense (qui aurait deux interfaces: une bridgée à ton LAN, soit par cable, soit en wifi, et l'autre vers un bridge virtuel), il y aurait d'autrs VM, qui seraient uniquement connectées à la seconde interface du pfSense.
Orange <-> routeur physique <-> host <-> pfsense virtualisé <-> autre vm derrière le pfsense
J'ai bon ?
Tout à fait.
La duplication des paquets, ca sent pas bon. On dirait que les VM sensées être derrière le pfSense étaient bridgées au LAN. C'est possible ? Ou est-ce que ton pfSense a bien deux interfaces réseau différentes ?
Les VM ne sont pas connectées au LAN, pas de soucis de ce côté là. La duplication ne se fait que dans le sens pfsense > net. Un coup on a le paquet "original" avec la MAC de pfsense et celui d'après avec la MAC de l'interface. Ça fait pareil en filaire et tout passe sans problème (sans modif de la mac du coup)
Je suis en bridge/réseau interne sur le pfsense, et réseau interne sur les VM.
Yep, c'est du MAC NAT. On ne touche pas aux adresses IP, mais dans le sens vm -> net, on remplace l'adresse source MAC des VM par celle de l'interface wifi du host.
Dans le sens net -> vm. on fait l'inverse : on remplace l'adresse MAC de destination (celle de l'interface wifi du host, donc) par celle de la VM.
Comme VirtualBox a besoin de savoir quelle adresse MAC utiliser pour faire le remplacement dans le sens net -> vm, il lui faut un identifiant qui ne change pas : c'est l'adresse IP. Il maintient donc une table dynamique d'associations entre IP<->MAC, qu'il maintient passivement, en observant le traffic IMCPv6 NS/NA.
En gros, c'est le même principe que du NAT L3 (IP), sauf c'est du NAT au niveau L2.
Je suis pas trop mauvais en déduction à ce je vois :)
-
Okay. hmmm... quand tu captures avec wireshark, tu captures bien uniquement sur l'interface physique (wlo0 ou enp2s0) ?
J'enfonce très certainement des portes ouvertes, mais cette duplication de paquets ne me dit rien de bon : si tu as bien deux réseaux séparés, tu ne devrais pas voir de duplication, et surtout, tu ne devrais jamais voir les MAC source des VM sur la patte upstream du pfSense...
J'ai l'impression que ces deux bridges ne sont pas étanches, et que tes soucis viennent de là.
As-tu moyen de faire une capture externe au PC également? Par exemple, sur ton routeur physique ? Pour s'assurer que les paquets sont bien dupliqués sur le réseau et que ce n'est pas qu'une vue de l'esprit de Wireshark.
Si les paquets sont effectivement dupliqués, tu envoies 2x plus de traffic sur le LAN/WAN que tu ne devrais. Ca ne va pas être top si c'est le cas.
-
Pas de duplication côté routeur, ça doit donc être wireshark qui a un peu de mal.
Okay. hmmm... quand tu captures avec wireshark, tu captures bien uniquement sur l'interface physique (wlo0 ou enp2s0) ?
Yep
-
Après avoir lâché l'affaire, je viens d'avoir une illumination. Étant donné que VB ne veut toujours rien savoir : j'utilise l'interface host-only de vmware qui s'installe comme une interface classique et apparaît donc dans la liste des interfaces par pont sur virtualbox et magie, ça marche ! 8)
Le seul soucis c'est que les deux se font concurrence sur l’utilisation de la virtualisation, du coup, les VM virtualbox crashent de temps en temps (bizarrement que Linux pour le moment, windows ne bronche pas).
Il faudrait pouvoir désactiver la virtualisation sur vmware, mais je n'ai pas trouvé comment faire.
-
Bon, je change de tactique. La cohabitation vmware/virtualbox, ça va pas du tout.
Je me suis rappelé du réseau de milkywan à base de VxLAN, je me suis dit que j'allais faire pareil. Montage d'un tunnel entre une VM debian vers mon rapberry pi qui me sert de DHCP/DNS/serveur wireguard... et qui ressort sur le LAN. En plus j'ai déjà un bout de conf tout prêt d'autres essais. J'ai donc tenté le coup avec cette architecture :
Routeur principal --- LAN --- AP wifi - - - PC portable (hôte) -bridge- VM debian (VTEP) -bridge- /réseau interne/ --- pfsense
|
Raspberry (bridge vxlan/eth0)
Sauf, qu'il y a un couac. Car je bridge eth0 sur le Rpi qui est l'unique interface par où tout sort. Ça doit faire une boucle (je suppose) et la connexion tombe.
J'ai fini par créer un VLAN supplémentaire bridgé avec le vxlan, que je fais remonter jusqu'à mon routeur principal et là fonctionne 8)
Par contre, j'ai un problème de MTU. Je suis obligé de la baisser à 1450 sur les VM, sinon le trafic ne passe pas en dehors des requêtes DNS et ICMP. Je n'arrive pas à trouver comment la faire s'adapter toute seule (ou que la debian fragmente) car de que j'ai lu la fragementation n'est pas supportée ni le PMTU car L2 et pas L3. Bizarrement, lorsque je l'avais essayé sur mon tunnel WG je n'ai rien fait de particulier (si ce n'est adapter la MTU du vxlan lui-même) et ça fonctionnait parfaitement je pensais donc que ça serait pareil ici.
Elle est à 1450 par défaut (qui est à priori la valeur en v4), mais visiblement ça ne suffit pas. Ça fait plusieurs heures que je cherche des infos claires, sans succès.
La conf :
Rapspberry :
auto vxlan10
iface vxlan10 inet manual
pre-up ip link add vxlan10 type vxlan id 10 dev eth0 remote 192.168.1.164 dstport 4789 || true
up ip link set vxlan10 up
down ip link set vxlan10 down
post-down ip link del vxlan10 || true
auto br0
iface br0 inet manual
bridge_ports eth0.40 vxlan10
5: eth0.40@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
link/ether b8:27:eb:ea:xx:xx brd ff:ff:ff:ff:ff:ff
8: vxlan10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master br0 state UNKNOWN group default qlen 1000
link/ether 3e:6b:d2:c5:xx:xx brd ff:ff:ff:ff:ff:ff
9: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
link/ether 3e:6b:d2:c5:67:73 brd ff:ff:ff:ff:ff:ff
inet6 fe80::3c6b:d2ff:fec5:6773/64 scope link
valid_lft forever preferred_lft forever
VM debian :
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug enp0s3
#iface enp0s3 inet dhcp
# This is an autoconfigured IPv6 interface
iface enp0s3 inet6 static
address 2a01:xx:xx:xx::164
netmask 64
gateway fe80::1a1e:78ff:xx:xx
auto enp0s8
iface enp0s8 inet manual
iface enp0s3 inet static
address 192.168.1.164
netmask 255.255.255.0
gateway 192.168.1.1
auto vxlan10
iface vxlan10 inet manual
pre-up ip link add vxlan10 type vxlan id 10 dev enp0s3 remote 192.168.1.10 dstport 4789 || true
up ip link set vxlan10 up
down ip link set vxlan10 down
post-down ip link del vxlan10 || true
auto br0
iface br0 inet static
bridge_ports enp0s8 vxlan10
address 192.168.10.254
netmask 255.255.255.0
(enp0s8 est l'interface attachée au réseau interne)
root@debian:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 08:00:27:88:13:f5 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.164/24 brd 192.168.1.255 scope global enp0s3
valid_lft forever preferred_lft forever
inet6 2a01:cb14:xx:xx::164/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe88:13f5/64 scope link
valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
link/ether 08:00:27:0f:c7:30 brd ff:ff:ff:ff:ff:ff
4: vxlan10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master br0 state UNKNOWN group default qlen 1000
link/ether 36:8f:1f:51:88:ad brd ff:ff:ff:ff:ff:ff
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
link/ether de:4a:81:2a:13:e5 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.254/24 brd 192.168.10.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::dc4a:81ff:fe2a:13e5/64 scope link
valid_lft forever preferred_lft forever
Merci
-
Bon, j'ai essayé d'augmenter la MTU pour que tout rentre, sauf que pas de bol, le chip du rasp ne supporte pas plus de 1500... Je suis donc condamné à faire avec.
Après recherche, j'ai vu qu'on pouvait faire du MSS clamping sur un bridge. J'ai donc essayé et ça fonctionne enfin sans toucher la MTU :
-charger le module : br_netfliter
-ajouter la règle iptables : iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1410
Par contre, il faudra qu'on m'explique : je n'ai pas touché à l'IPv6, et celui-ci semble fonctionner sans soucis avec un MSS de... 1440. Comment est-ce possible ?
Si j'augmente à 1420 en IPv4, j'ai de nouveau des soucis, il faut impérativement 1410 ce qui est logique si on enlève les 50 octets du VxLAN. J'ai cru au début que c'était un hasard car en fait je recevais en réponse un MSS bien en dessous de 1440 de certains serveurs, mais j'ai testé avec le forum ainsi que la weathermap de mylkywan qui répondent bien 1440 et ça fonctionne sans problème non plus.
-
Bon, j'ai essayé d'augmenter la MTU pour que tout rentre, sauf que pas de bol, le chip du rasp ne supporte pas plus de 1500... Je suis donc condamné à faire avec.
C'est un raspi 4? À mon sens le chip le supporte mais le driver n'a pas ce qu'il faut pour changer la MTU du hardware.
Après recherche, j'ai vu qu'on pouvait faire du MSS clamping sur un bridge. J'ai donc essayé et ça fonctionne enfin sans toucher la MTU :
-charger le module : br_netfliter
-ajouter la règle iptables : iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1410
Tu es sur que tu as besoin de br_netfilter ? J'utilise nftables de nos jours, je sais plus trop.
Tu dois pouvoir limiter ta règle au traffic venant de l'interface vxlan, sans quoi tout le traffic forwardé par le raspi aura une MSS réduite.
Par contre, il faudra qu'on m'explique : je n'ai pas touché à l'IPv6, et celui-ci semble fonctionner sans soucis avec un MSS de... 1440. Comment est-ce possible ?
Seuls les hotes fragmentent en IPv6, les routeurs ne le font pas.
Lorsqu'un routeur voit passer un paquet trop gros pour la MTU de l'interface sortante, il le jette et renvoie un ICMP packet too big à la source.
La source enregistre une MTU plus faible dans son route cache et ré-émet les segments TCP avec une MSS réduite. C'est ce qu'on appelle PMTUd (Path MTU Discovery), mais il me semble que tu connais déjà et que je radote :-)
Donc pas besoin de hack de MSS en IPv6 (pour peu que les ICMP packet too big ne soient pas filtrés, et avant que tu demandes, si, si, en 2023, les DSI de grosses boites maintiennent dûr comme fer qu'il faut bloquer ICMP car "on se fait hacker avec", mais c'est de plus en plus rare...).
-
C'est un raspi 4? À mon sens le chip le supporte mais le driver n'a pas ce qu'il faut pour changer la MTU du hardware.
Non, un "vieux" mais encore vaiillant Raspi 2B. Vu le prix du 4 en ce moment (200€ sur amazon), je suis pas prêt de le remplacer... Même le mien se vend encore 80 balles, honteux.
Tu es sur que tu as besoin de br_netfilter ? J'utilise nftables de nos jours, je sais plus trop.
Tu dois pouvoir limiter ta règle au traffic venant de l'interface vxlan, sans quoi tout le traffic forwardé par le raspi aura une MSS réduite.
Oui j'ai vu passer un truc à base de nftables qui se passe de br_filter mais là, je n'ai qu'une seule règle. Pas très grave.
table bridge t
delete table bridge t
table bridge t {
chain c {
type filter hook forward priority filter; policy accept;
oifname vxlan0 tcp flags syn tcp option maxseg size set 1400
}
}
Pour la limitation, oui faut que j'affine genre iptables -A FORWARD -i br0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1410
Seuls les hotes fragmentent en IPv6, les routeurs ne le font pas.
Lorsqu'un routeur voit passer un paquet trop gros pour la MTU de l'interface sortante, il le jette et renvoie un ICMP packet too big à la source.
La source enregistre une MTU plus faible dans son route cache et ré-émet les segments TCP avec une MSS réduite. C'est ce qu'on appelle PMTUd (Path MTU Discovery), mais il me semble que tu connais déjà et que je radote :-)
Ah oui c'est vrai que les routeurs ne fragmentent pas (je l'ai lu hier en plus ::)), j'ai donc bien des packet too big.
root@LEDE:~# tcpdump -i dsl0 icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on dsl0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:06:24.501731 IP6 2a01:cb14:xxxx:xxxx:9c6e:bf99:e8b7:6099 > fr.archive.ubuntu.com: ICMP6, packet too big, mtu 1450, length 1240
14:06:24.502161 IP6 2a01:cb14:xxxx:xxxx:9c6e:bf99:e8b7:6099 > fr.archive.ubuntu.com: ICMP6, packet too big, mtu 1450, length 1240
14:06:50.641458 IP6 fe80::ba0:bab > fe80::46a6:1eff:xxxx:xxxx: ICMP6, neighbor solicitation, who has fe80::46a6:1eff:xxxx:xxxx, length 32
14:06:50.641795 IP6 fe80::46a6:1eff:xxxx:xxxx > fe80::ba0:bab: ICMP6, neighbor advertisement, tgt is fe80::46a6:1eff:xxxx:xxxx, length 24
14:10:47.739630 IP6 fe80::ba0:bab > fe80::46a6:1eff:xxxx:xxxx: ICMP6, router advertisement, length 32
14:11:13.939693 IP6 2a01:cb14:xxxx:xxxx:9c6e:bf99:e8b7:6099 > fr.archive.ubuntu.com: ICMP6, packet too big, mtu 1450, length 1240
14:11:13.942018 IP6 2a01:cb14:xxxx:xxxx:9c6e:bf99:e8b7:6099 > fr.archive.ubuntu.com: ICMP6, packet too big, mtu 1450, length 1240
14:11:30.395438 IP6 2a01:cb14:xxxx:xxxx:9c6e:bf99:e8b7:6099 > hubble.milkywan.cloud: ICMP6, packet too big, mtu 1450, length 1240
14:11:30.396301 IP6 2a01:cb14:xxxx:xxxx:9c6e:bf99:e8b7:6099 > hubble.milkywan.cloud: ICMP6, packet too big, mtu 1450, length 1240
Donc pas besoin de hack de MSS en IPv6 (pour peu que les ICMP packet too big ne soient pas filtrés, et avant que tu demandes, si, si, en 2023, les DSI de grosses boites maintiennent dûr comme fer qu'il faut bloquer ICMP car "on se fait hacker avec", mais c'est de plus en plus rare...).
J'avoue que ça m'a fait sourire quand j'ai lu ça.
J'aimerais bien faire marcher PMTUd en v4, mais ça à l'air de coincer... ou il me manque des règles sur mon OWRT ? Sachant que tout est openbar sur le rasp et la debian.
-
J'aimerais bien faire marcher PMTUd en v4, mais ça à l'air de coincer... ou il me manque des règles sur mon OWRT ? Sachant que tout est openbar sur le rasp et la debian.
Oublie PMTUd en IPv4... entre les équipements qui fragmentent même lorsque le flag DF est à 1 (rare, mais ca existe, surtout sur les firewalls), les routeurs qui n'envoient jamais les ICMP "fragmentation needed and DF was set" (très courant), les NAT qui ré-écrivent les options TCP et ignorent les ICMP... ca n'a aucune chance de fonctionner en pratique.
Il y a toujours la méthode RFC 4821, mais comme elle est désactivée par défaut sur tous les OS, c'est d'efficacité limitée.
Si tu veux garder ton architecture à base de tunnels VxLAN, je pense que faire du MSS clamping pour TCPv4 et laisser PMTUd se débrouiller en IPv6 doit le faire.
-
Ouais alors y'a quand même des crétins comme Microsoft Azure qui bloquent ICMPv6 et qui empêchent PMTUd de fonctionner...
-
Heh, comment dire, IPv6 et Azure... hm, même AWS fait mieux de nos jours.
-
Ouais alors y'a quand même des crétins comme Microsoft Azure qui bloquent ICMPv6 et qui empêchent PMTUd de fonctionner...
Ah ben bravo Microsoft, une fois de plus ::)
Enfin, c'est pas trop étonnant quand on voit l'IPv6 sur Windows... Par ex depuis 11, le RDNSS est ignoré, sauf si on est en v6 only... Il faut du DHCPv6 pour avoir DNS v4 + v6. Ou encore cette manie d'envoyer des solicit alors qu'on a rien demandé et qui m'oblige à bloquer la distribution d'adresses.
-
Par ex depuis 11, le RDNSS est ignoré, sauf si on est en v6 only...
Je sais pas vous, mais moi, j'y vois une invitation à faire du v6-only :-)
-
Ou encore cette manie d'envoyer des solicit alors qu'on a rien demandé et qui m'oblige à bloquer la distribution d'adresses.
Qu'est ce qu'ils ont cassé? Et qu'est ce que tu bloques du coup?
-
Pour l'ipv6 only, il faudrait déjà qu'ils proposent le CLAT sur toutes les interfaces, c'est toujours pas le cas... Pour moi ils ont juste pété un truc et ils se sont sûrement dit que personne s'en servait ou n'y verrait que du feu vu que c'est quand même pris en compte si pas d'ipv4.
Côté solicit, c'est pas vraiment "cassé" quoi que... je sais pas si ça respecte les RFC. C'est juste que ça envoie un solicit au démarrage peu importe les flags dans les RA. Du coup, le DHCPv6 de mon routeur attribue une ipv6 en plus du SLAAC. Et je suis donc obligé de bloquer explicitement l'attribution.
Ce comportement a été introduit dans windows 8.1. Avec 7 les flags sont respectés et il n’envoie que les information-request si O=1 et M=0
-
Si tu veux garder ton architecture à base de tunnels VxLAN, je pense que faire du MSS clamping pour TCPv4 et laisser PMTUd se débrouiller en IPv6 doit le faire.
Sinon tu me préconiserais quoi comme autre archi ?
J'ai hésité avec du GRE ou PPPoE. Mais je les avais écarté car pour GRE, ça fait une couche de routage en plus (avec les difficultés que ça implique pour le DHCP) et le PPPoE, ça à l'air bien galère à configurer pour pas grand chose (je n'ai jamais touché à la partie v6). Mais peut-être que c'est pas si pire et que Hugues pourrait nous en dire un peu plus :)
-
VxLAN est pas mal, perso je n'ai rien contre :-) C'est L2 donc probablement plus facile à gérer pour ce que tu veux faire.
Aujourd'hui tu termines ce tunnel VxLAN sur une raspi. Est-ce que tu ne pourrais pas le faire directement sur le routeur, et mettre tes VM dans un (ou plusieurs) VLAN avec leur propre /64? Ca ferait moins d'équipements.
Pour l'ipv6 only, il faudrait déjà qu'ils proposent le CLAT sur toutes les interfaces, c'est toujours pas le cas... Pour moi ils ont juste pété un truc et ils se sont sûrement dit que personne s'en servait ou n'y verrait que du feu vu que c'est quand même pris en compte si pas d'ipv4.
J'ai toujours ce plan de tenter de forcer l'activation du CLAT sur une interface arbitraire, mais bon, faut se frotter à Windows.
Côté solicit, c'est pas vraiment "cassé" quoi que... je sais pas si ça respecte les RFC. C'est juste que ça envoie un solicit au démarrage peu importe les flags dans les RA. Du coup, le DHCPv6 de mon routeur attribue une ipv6 en plus du SLAAC. Et je suis donc obligé de bloquer explicitement l'attribution.
Ce comportement a été introduit dans windows 8.1. Avec 7 les flags sont respectés et il n’envoie que les information-request si O=1 et M=0
Yep, ils ignorent les flags des RA, c'est clairement une violation des specs. Poussé par la mentalité entreprise de vouloir faire du DHCP comme en IPv4, je suppose (qu'on se le dise, le 1er client de MS, c'est l'IT entreprise).
Je suppose que tu dois pouvoir influer sur ces comportements depuis des commandes PowerShell magiques, ou en changeant des valeurs dans le "registre" de Windows.
-
VxLAN est pas mal, perso je n'ai rien contre :-) C'est L2 donc probablement plus facile à gérer pour ce que tu veux faire.
Aujourd'hui tu termines ce tunnel VxLAN sur une raspi. Est-ce que tu ne pourrais pas le faire directement sur le routeur, et mettre tes VM dans un (ou plusieurs) VLAN avec leur propre /64? Ca ferait moins d'équipements.
Le VLAN termine bien sur le routeur. Le rasp sert juste de bridge. Ça fait : Debian (portable) > [eth0/vxlan] raspi [eth0.40] > pont wifi > [eth0.40] OpenWRT. Par contre avoir plusieurs /64, je sens que ça va être ingérable, si je veux me mettre à compartimenter j'ai pas fini avec une dizaine de VM (et bien plus sur mon fixe) ;D
Est-ce tu me confirme que les interfaces VxLAN sur OWRT se comportent comme n'importe quelle autre ? Je peux donc y mettre une IPv4, un DHCP et l'attribution automatique en v6 ? Si je veux intégrer le VLAN actuel pour desservir mes VM fixes, il me suffit de faire un bridge entre les 2 donc ? (et ça sera donc le bridge qui porte l'IP).
J'espère par contre que ça sera pas trop galère car faut tout gérer dans /etc/config/network. Je n'ai pas upgrade, donc adieu la gestion avec luci bien pratique il faut dire (dispo à partir de la 21 de ce j'ai vu [luci-proto-vxlan]) Je suis toujours en 19.07 qui tourne au poil car il y avait des problèmes de possible bootloop jusqu'à récemment sur la 22.03, apparemment corrigé sur la dernière révision et je n'avais pas du tout envie de le planter n'ayant pas le matos adéquat en cas de pépin.
J'ai toujours ce plan de tenter de forcer l'activation du CLAT sur une interface arbitraire, mais bon, faut se frotter à Windows.
J'avais essayé de bidouiller le registre sans succès. Du genre, faire croire au système que l'interface est de type WWAN, mais tout ce que ça faisait, c'est me la faire disparaître du panneau de config.
Yep, ils ignorent les flags des RA, c'est clairement une violation des specs. Poussé par la mentalité entreprise de vouloir faire du DHCP comme en IPv4, je suppose (qu'on se le dise, le 1er client de MS, c'est l'IT entreprise).
Je suppose que tu dois pouvoir influer sur ces comportements depuis des commandes PowerShell magiques, ou en changeant des valeurs dans le "registre" de Windows.
Alors là aussi, ce n'est pas simple. Le seul moyen que j'ai trouvé est de désactiver le DHCPv6 mais on perd les DNS du coup. Aucune idée s'il est possible de récupérer le comportement de 7 juste en bidouillant le registre et sans désactiver le DHCPv6.
-
Est-ce tu me confirme que les interfaces VxLAN sur OWRT se comportent comme n'importe quelle autre ? Je peux donc y mettre une IPv4, un DHCP et l'attribution automatique en v6 ? Si je veux intégrer le VLAN actuel pour desservir mes VM fixes, il me suffit de faire un bridge entre les 2 donc ? (et ça sera donc le bridge qui porte l'IP).
Je n'ai pas essaye moi-même, mais ce sont des interfaces Ethernet, donc tu devrais pouvoir les ajouter à un bridge sans souci. J'allais justement te proposer de le faire si jamais netifd ne te laisse pas lancer un serveur DHCP dessus.
J'espère par contre que ça sera pas trop galère car faut tout gérer dans /etc/config/network.
Configurer une interface et la rattacher à un bridge? Ca semble pas sorcier dit comme ca. Si c'est packagé et supporté par netifd, ca va le faire.
-
Ce n'est pas aussi facile que je le pensais. Avant de déployer sur mon routeur, je test d'abord en VM et j'ai bien fait : ça ne fonctionne pas... là j'essaie de connecter un OWRT avec mon raspi.
Le vxlan monte bien, par contre, j'ai un paquet sur deux des destination unreachable au milieu des requêtes ARP. Et aucun autre trafic. On dirait qu'il n'arrive pas à apprendre les MACs du sous réseau....
root@OpenWrt:~# arp
IP address HW type Flags HW address Mask Device
192.168.10.1 0x1 0x0 00:00:00:00:00:00 * vxlan0
192.168.1.10 0x1 0x2 b8:27:eb:ea:xx:xx * eth1
192.168.45.202 0x1 0x2 08:00:27:0a:59:36 * br-lan
192.168.1.1 0x1 0x2 18:1e:78:1a:xx:xx * eth1
192.168.10.253 0x1 0x0 00:00:00:00:00:00 * vxlan0
192.168.10.x est le sous réseau des VM.
De plus j'ai droit à des duplication d'adresses... qui n'existent pas. Pour je ne sais quelle raison, mon RPi répond aussi à la requête ARP que c'est lui qui porte l'adresse de mon routeur principal juste après celui-ci. Alors que je n'ai pas attribué d'adresse au bridge ??? Chose qui ne se produit pas avec la debian en face. Pour régler le problème, j'ai donc attribué une adresse au bridge et la duplication a disparue.
-
Il me semblait bien que j'avais un soucis : depuis que j'ai mis en place le bridge sur mon rasp, l'IPv6 disparaît de l'interface principale au bout un moment (on dirait que c'est au bout de 2 jours environ) il faut que je relance et c'est reparti pour un tour. Comme s'il se mettait à refuser les RA et vivait sur la validité des adresses.
Ce qui est bizarre c'est que tout disparaît, même la link local.
Y'aurait un bug connu chez debian ? J'ai rien trouvé.
Mon sysctl :
net.ipv4.ip_forward=1
net.ipv4.conf.all.proxy_arp = 1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.eth0.accept_ra=2
net.ipv6.conf.all.use_tempaddr=2
net.ipv6.conf.default.use_tempaddr=2
net.ipv6.conf.eth0.use_tempaddr=2
net.ipv6.conf.eth0.temp_valid_lft=90000
net.ipv6.conf.default.temp_valid_lft=90000
net.ipv6.conf.all.temp_valid_lft=90000
J'active les RA malgré le forwarding pour bénéficier des privacy extension et avec un token pour avoir une IP fixe.
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.10
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 127.0.0.1 80.10.246.2
iface eth0 inet6 auto
pre-up /sbin/ip token set ::192:168:1:10 dev eth0
auto eth0.10
iface eth0.10 inet static
address 192.168.3.1
netmask 255.255.255.0
vlan-raw-device eth0
auto eth0.832
iface eth0.832 inet static
address 192.168.32.10
netmask 255.255.255.0
vlan-raw-device eth0
iface eth0.832 inet6 static
address 2a01:cb14:xx:xx::10
netmask 64
vlan-raw-device eth0
auto eth0.40
iface eth0.40 inet manual
vlan-raw-device eth0
#address 192.168.3.1
#netmask 255.255.255.0
auto eth0.835
iface eth0.835 inet manual
up ip link set dev $IFACE up
up pppoe-server -I $IFACE -m 1452 -C isp -L 192.168.35.1 -p /etc/ppp/ips -O /etc/ppp/pppoe-server-options
post-up iptables -t nat -A POSTROUTING -s 192.168.35.0/24 -o eth0 -j MASQUERADE
down killall pppoe-server
down ip link set dev $IFACE up
post-down iptables -t nat -D POSTROUTING -s 192.168.35.0/24 -o eth0 -j MASQUERADE
vlan-raw-device eth0
auto wg0
iface wg0 inet static
pre-up /sbin/ip link add dev wg0 mtu 1440 type wireguard
post-up /usr/bin/wg setconf wg0 /etc/wireguard/wg0.conf
post-up /sbin/ip route add 192.168.2.0/24 dev wg0
post-up /sbin/ip -6 route add fd07:adec:7:0::/64 dev wg0
#post-up /sbin/ip route add 192.168.42.0/24 dev wg0
#post-up iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
post-down /sbin/ip link del wg0
address 172.16.2.2
netmask 255.255.255.0
iface wg0 inet6 static
address fd07:adec:7:1::2
netmask 64
auto vxlan10
iface vxlan10 inet manual
pre-up ip link add vxlan10 type vxlan id 10 dev eth0 remote 192.168.1.164 dstport 4789 || true
up ip link set vxlan10 up
down ip link set vxlan10 down
post-down ip link del vxlan10 || true
# address 192.168.4.253
# netmask 255.255.255.0
auto br0
iface br0 inet static
bridge_ports eth0.40 vxlan10
address 192.168.10.253
netmask 255.255.255.0
un ip a quand ça déconne :
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:eb:ea:13:a9 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
3: eth0.10@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether b8:27:eb:ea:13:a9 brd ff:ff:ff:ff:ff:ff
inet 192.168.3.1/24 brd 192.168.3.255 scope global eth0.10
valid_lft forever preferred_lft forever
inet6 fe80::ba27:ebff:feea:13a9/64 scope link
valid_lft forever preferred_lft forever
4: eth0.832@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether b8:27:eb:ea:13:a9 brd ff:ff:ff:ff:ff:ff
inet 192.168.32.10/24 brd 192.168.32.255 scope global eth0.832
valid_lft forever preferred_lft forever
inet6 2a01:cb14:xx:xx::10/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::ba27:ebff:feea:13a9/64 scope link
valid_lft forever preferred_lft forever
7: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1440 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 172.16.2.2/24 brd 172.16.2.255 scope global wg0
valid_lft forever preferred_lft forever
inet6 fd07:adec:7:1::2/64 scope global
valid_lft forever preferred_lft forever
27: eth0.835@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether b8:27:eb:ea:13:a9 brd ff:ff:ff:ff:ff:ff
28: vxlan10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master br0 state UNKNOWN group default qlen 1000
link/ether da:94:ae:01:43:04 brd ff:ff:ff:ff:ff:ff
29: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
link/ether b8:27:eb:ea:13:a9 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.253/24 brd 192.168.10.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::ba27:ebff:feea:13a9/64 scope link
valid_lft forever preferred_lft forever
30: eth0.40@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
link/ether b8:27:eb:ea:13:a9 brd ff:ff:ff:ff:ff:ff
-
Bon, c'est pire que ça : je ne sais pas si je m'en rends compte que maintenant, mais le simple fait de faire un ifup/ifdown sur le bridge me fait gicler l'ipv6 de eth0... Pourtant il me semble bien qu'au tout début, j'ai essayé diverses config avec ifup/down à chaque fois et ça n'a eu aucun effet.
Et même en mettant une ipv6 fixe, elle disparaît aussi :-\
Y'a un truc que je fais de travers ou quoi ?
EDIT : J'ai essayé en VM, et même comportement. On dirait que c'est lié au VLAN, qui entraîne l'interface parente avec, comme si ça faisait un ifup/down pas propre qui ne reconfigure pas la stack ipv6.