Auteur Sujet: Trafic ipv6 vers interface wireguard répondu par interface lo  (Lu 579 fois)

0 Membres et 1 Invité sur ce sujet

dash

  • Client FAI autre
  • *
  • Messages: 35
  • Zellwiller 67
    • TOOTAi Télécommunications
Trafic ipv6 vers interface wireguard répondu par interface lo
« le: 14 septembre 2021 à 22:45:29 »
Bonjour,
je me bats avec wireguard sous Debian 11: le trafic d'une des extremités est renvoyé par l'interface lo comme ci dessous (tcpdump -ni any icmp6)

19:23:50.287492 wig0 In IP6 fd99:1234:beef:cafe:fade::7000 > fd99:1234:beef:cafe:fade::7fff: ICMP6, echo request, id 18272, seq 5, length 64
19:23:50.287509 lo In IP6 fd99:1234:beef:cafe:fade::7fff > fd99:1234:beef:cafe:fade::7000: ICMP6, echo reply, id 18272, seq 5, length 6

J'ai testé avec 2 peers différents -également Debian11- le résultat est identique. La sortie ip est

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000                   
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 90:1b:0e:93:4c:b1 brd ff:ff:ff:ff:ff:ff               
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 500
    link/none                                                                                                                                                 
5: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 500
    link/none                                                                                                                                                 
6: virbr0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:76:8e:2e brd ff:ff:ff:ff:ff:ff
7: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether fe:54:00:da:70:14 brd ff:ff:ff:ff:ff:ff
8: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether fe:54:00:da:70:12 brd ff:ff:ff:ff:ff:ff
9: vnet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether fe:54:00:da:70:11 brd ff:ff:ff:ff:ff:ff
10: vnet3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether fe:54:00:da:70:13 brd ff:ff:ff:ff:ff:ff     
11: vnet4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr0 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether fe:54:00:da:70:15 brd ff:ff:ff:ff:ff:ff
20: wig0: <POINTOPOINT,NOARP,ALLMULTI,UP,LOWER_UP> mtu 1436 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

et ip -6 r

::1 dev lo proto kernel metric 256 pref medium
2001:db8:120:1104::/96 dev virbr0 proto kernel metric 256 pref medium
2001:db8:120:1104::/64 dev eth0 proto kernel metric 256 pref medium
fd99:1234:beef:cafe:fade::7010/124 dev virbr0 proto kernel metric 128 pref medium
fd99:1234:beef:cafe:fade::7000/116 dev wig0 proto kernel metric 256 pref medium
fd99:1234:beef:cafe::/64 via fd99:1234:beef:cafe:fade::7000 dev wig0 metric 1024 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
fe80::/64 dev tun1 proto kernel metric 256 pref medium
fe80::/64 dev vnet0 proto kernel metric 256 pref medium
fe80::/64 dev vnet1 proto kernel metric 256 pref medium
fe80::/64 dev vnet2 proto kernel metric 256 pref medium
fe80::/64 dev virbr0 proto kernel metric 256 pref medium
fe80::/64 dev vnet3 proto kernel metric 256 pref medium
fe80::/64 dev vnet4 proto kernel metric 256 pref medium
default via fe80::1 dev eth0 metric 1024 onlink pref medium

Ce serveur fait tourner libvirt pour des MV, aucun problème d'accès entre elles (fd99:1234:beef:cafe:fade::7010/124 dev virbr0) ni avec le serveur fd99:1234:beef:cafe:fade::7000/116 Les interfaces tunX sont des liens OpenVPN ipv4 fonctionnels.

Si quelqu'un avait une idée de la source du problème je serai ravi de la connaître ;)

Daniel

cali

  • Officiel Ukrainian Resilient Data Network
  • Fédération FDN
  • *
  • Messages: 2 328
    • Ukrainian Resilient Data Network
Trafic ipv6 vers interface wireguard répondu par interface lo
« Réponse #1 le: 14 septembre 2021 à 23:11:30 »
ip route get fd99:1234:beef:cafe:fade::7000 from fd99:1234:beef:cafe:fade::7fff

dash

  • Client FAI autre
  • *
  • Messages: 35
  • Zellwiller 67
    • TOOTAi Télécommunications
Trafic ipv6 vers interface wireguard répondu par interface lo
« Réponse #2 le: 15 septembre 2021 à 09:52:58 »
Bingo !

anycast fd99:1234:beef:cafe:fade::7000 from fd99:1234:beef:cafe:fade::7fff dev lo table local proto kernel src fd99:1234:beef:cafe:fade::7fff metric 0 pref medium

#ip r replace fd99:1234:beef:cafe:fade::7000 from fd99:1234:beef:cafe:fade::7fff dev wig0 table local

et tout rentre en ordre. La question est: pourquoi ?

Merci pour la solution.

cali

  • Officiel Ukrainian Resilient Data Network
  • Fédération FDN
  • *
  • Messages: 2 328
    • Ukrainian Resilient Data Network
Trafic ipv6 vers interface wireguard répondu par interface lo
« Réponse #3 le: 15 septembre 2021 à 13:05:54 »
Regarde la table local avant et après la création du tunnel.

$ ip -6 route show table local

dash

  • Client FAI autre
  • *
  • Messages: 35
  • Zellwiller 67
    • TOOTAi Télécommunications
Trafic ipv6 vers interface wireguard répondu par interface lo
« Réponse #4 le: 15 septembre 2021 à 19:25:58 »
Bonsoir. Uniquement les routes rajoutées par l'interface wireguard se rajoutent. Voici un diff:

dh@mango ~ $ diff local.before local.after
6a7,9
> anycast fd99:1234:beef:cafe:fade::7000 dev wig0 proto kernel metric 0 pref medium
> local fd99:1234:beef:cafe:fade::7010 dev virbr0 proto kernel metric 0 pref medium
> local fd99:1234:beef:cafe:fade::70ff dev wig0 proto kernel metric 0 pref medium
33a37
> multicast ff00::/8 dev wig0 proto kernel metric 256 pref medium

Dans la table je vois bien
anycast fd99:1234:beef:cafe:fade::7000 dev wig0 proto kernel metric 0 pref medium

mais ip route get fd99:1234:beef:cafe:fade::7000 from fd99:1234:beef:cafe:fade::70ff montre
anycast fd99:1234:beef:cafe:fade::7000 from fd99:1234:beef:cafe:fade::70ff dev lo table local proto kernel src fd99:1234:beef:cafe:fade::70ff metric 0 pref medium

Pour le moment je m'en sors en remplacant cette route dans post-up de l'interface wireguard mais j'aimerai tout de même comprendre ...

thenico

  • Expert.
  • Client OVH
  • *
  • Messages: 929
  • FTTH >500 Mb/s (13)
Trafic ipv6 vers interface wireguard répondu par interface lo
« Réponse #5 le: 16 septembre 2021 à 00:02:17 »
Qu'est-ce qui créé le tunnel? wg-quick ? systemd-networkd? ifupdown (/etc/network/interfaces) ?

ip -6 addr show wig0 ?

dash

  • Client FAI autre
  • *
  • Messages: 35
  • Zellwiller 67
    • TOOTAi Télécommunications
Trafic ipv6 vers interface wireguard répondu par interface lo
« Réponse #6 le: 16 septembre 2021 à 00:10:19 »
Bonsoir. C'est /etc/network/interfaces qui lance le tunnel

root@mango /etc # ip -6 addr show wig0
3: wig0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1436 qdisc noqueue state UNKNOWN group default qlen 1000
    inet6 fd99:1234:beef:cafe:fade::70ff/120 scope global
       valid_lft forever preferred_lft forever

Attention: j'ai modifié le masque, il est passé de /116 à /120

thenico

  • Expert.
  • Client OVH
  • *
  • Messages: 929
  • FTTH >500 Mb/s (13)
Trafic ipv6 vers interface wireguard répondu par interface lo
« Réponse #7 le: 16 septembre 2021 à 00:24:45 »
 wg show wig0  allowed-ips ?

Est-ce que tu utilises l'intégration Wireguard d'ifupdown ou est-ce que tu configure à la main à coup de pre-up ?

kgersen

  • Modérateur
  • Client Free Pro
  • *
  • Messages: 8 135
  • Paris (75)
Trafic ipv6 vers interface wireguard répondu par interface lo
« Réponse #8 le: 16 septembre 2021 à 01:41:05 »
Bonsoir. C'est /etc/network/interfaces qui lance le tunnel

c'est trop vague.
comme indique thenico, il manque l'information importante: comment wg est invoqué pour construire le tunnel.

et c'est triste de voir des /120 et des /116 ... surtout avec des ULA. ;D

Pourquoi mettre ces IPv6 sur les interfaces du tunnel ?
un tunnel wg peut transporter de l'IPv6 sans pourtant avoir des ULA ou des GUA sur ses extrémités (=l'interface wig0 dans ton cas).
Perso j'utilise que des link-local manuelles aux extremities des tunnels mais ce n'est meme pas obligé.

exemple d'un .conf:

[Interface]
#site 1
Address = fe80::1/64
ListenPort = 51820
PrivateKey = ....

[Peer]
# site 2
PublicKey =....
AllowedIPs = 2001:a:b:c:d::/64
Endpoint = ....

et dans le .conf du site2 son  Address = fe80::2/64

C'est simple et lisible, le site X  a son interface wg en fe80:X


dash

  • Client FAI autre
  • *
  • Messages: 35
  • Zellwiller 67
    • TOOTAi Télécommunications
Trafic ipv6 vers interface wireguard répondu par interface lo
« Réponse #9 le: 16 septembre 2021 à 08:35:31 »
Bonjour

allowed ips: 192.168.10.0/24, 192.168.12.0/24, fd99:1234:beef:cafe::/64

auto wig0                                                                                                                                                     
iface wig0 inet6 static                                                                                                                                       
    address fd99:1234:beef:cafe:fade::70ff/120                                                                                                               
    pre-up ip link add dev $IFACE mtu 1436 type wireguard                                                                                                     
    pre-up wg setconf $IFACE /etc/wireguard/keewi.conf                                                                                                       
    post-up ip -6 a del fd99:1234:beef:cafe:fade::/96 dev virbr0                                                                                             
    post-up ip -6 a add fd99:1234:beef:cafe:fade::7010/124 metric 128 dev virbr0 || true                                                                     
    post-up ip -6 r add fd99:1234:beef:cafe::/64 via fd99:1234:beef:cafe:fade::7000 dev $IFACE                                                               
    post-up ip r replace fd99:1234:beef:cafe:fade::7000 from fd99:1234:beef:cafe:fade::70ff dev $IFACE table local   ; cmd qui règle le problème                                   
    post-up ping -c 1 fd99:1234:beef:cafe:fade::7000 2>&1 >/dev/null || true                                                                                 
    post-down ip -6 a del fd99:1234:beef:cafe:fade::7010/124 dev virbr0 || true                                                                               
    post-down ip link del dev $IFACE

et c'est triste de voir des /120 et des /116 ... surtout avec des ULA. ;D

pas besoin de plus d'ips, au prix ou elles coûtent ;)

Perso j'utilise que des link-local manuelles aux extremities des tunnels mais ce n'est meme pas obligé.

Parceque ce lien traverse des routeurs par ex ? Les link-local pour du lien local je te l'accorde, la on parle de joindre des serveurs dans des DC distants.

Daniel

dash

  • Client FAI autre
  • *
  • Messages: 35
  • Zellwiller 67
    • TOOTAi Télécommunications
Trafic ipv6 vers interface wireguard répondu par interface lo
« Réponse #10 le: 16 septembre 2021 à 08:52:31 »
Perso j'utilise que des link-local manuelles aux extremities des tunnels mais ce n'est meme pas obligé.

OK, j'avais lu de travers. De mon côté j'aime bien avoir les adresses dans le même range, et au bureau le range est fd99:1234:beef:fade::/64 est utilisé, j'ai donc une continuité dans ma logique. Pour pousser plus loin, les extremités d'un tunnel sont toujours en xx00 et xxff et l'interface libvirt -si elle est présente- en xx10 Bref, une autre logique.

kgersen

  • Modérateur
  • Client Free Pro
  • *
  • Messages: 8 135
  • Paris (75)
Trafic ipv6 vers interface wireguard répondu par interface lo
« Réponse #11 le: 16 septembre 2021 à 11:21:44 »
mettre un ping en post-up : pas recommandé du tout.

    post-up ip -6 r add fd99:1234:beef:cafe::/64 via fd99:1234:beef:cafe:fade::7000 dev $IFACE                                                               
pourquoi ce "via ...::7000" ? qui porte cette IP (7000) , c'est configuré ou ?

c'est normal que ca route pas correctement:

ip -6 route add subnet1 via next-hop dev interface

si next-hop est dans subnet1 et qu'il n'y a pas de route plus spécifique qui dit comment joindre next-hop ca ne peut marcher.
c'est pour cela qui tu dois ajouter une route plus spécifique qui indique comment joindre le "via".

Mais le "via" n'est pas utile la car c'est le principe de wg: on n'a pas besoin de 'route via l'ip du tunnel a l'autre bout' c'est déjà pris en charge par les "allowed-ips". Il suffit de router sur l'interface et le code de wg se charge d'envoyer au bon bout du tunnel en fonction des "allowed-ips". C'est pour cela que les adresses des tunnels importent peu et qu'on a surtout pas besoin de ce compliquer la vie à mettre des addresses dans le meme subnet en plus.

Citer
AllowedIPs — a comma-separated list of IP (v4 or v6) addresses with  CIDR  masks  from  which  incoming
              traffic for this peer is allowed and to which outgoing traffic for this peer is directed. The catch-all
              0.0.0.0/0 may be specified for matching all IPv4 addresses, and ::/0 may be specified for matching  all
              IPv6 addresses. May be specified multiple times.

donc

post-up ip -6 r add fd99:1234:beef:cafe::/64 dev $IFACE                                                               

devrait suffire. Le code wireguard saura a quel bout du tunnel envoyé cela. pas besoin de 'via'. ni de route spécifique pour le via.


pas besoin de plus d'ips, au prix ou elles coûtent ;)

C'est pas une question de prix... utiliser des /124 ou /96 c'est juste pas recommandé et absolument pas une bonne façon de faire. Il ne faut jamais faire plus petit que /64 sauf si on a vraiment pas le choix.

On a justement des milliards d'IPv6 disponibles c'est donc pas pour faire des contorsions a découper un /64 en plusieurs parties (sans parler des bugs que ca peut causer car peu de gens testent leur code avec des subnets plus petits que 64).

OK, j'avais lu de travers. De mon côté j'aime bien avoir les adresses dans le même range, et au bureau le range est fd99:1234:beef:fade::/64 est utilisé, j'ai donc une continuité dans ma logique. Pour pousser plus loin, les extremités d'un tunnel sont toujours en xx00 et xxff et l'interface libvirt -si elle est présente- en xx10 Bref, une autre logique.

oui mais utiliser un subnet ULA ou GUA pour le tunnel lui-meme , qui est plus est un sous-subnet d'un subnet /64 ce n'est juste pas une bonne pratique non plus.
Si tu veux vraiment des IP routables pour le tunnel tu peux utiliser un /64 spécifique a ce tunnel. Mais il faut une bonne raison pour cela (certain protocoles de routage par exemple) sinon c'est juste de la complexité inutile.

Chacun utilise sa logique certes mais y'a des recommendations issues de l'expérience qui sont bonnes a suivre aussi.

sinon:
                                                                                             
post-up ip -6 a add fd99:1234:beef:cafe:fade::7010/124 [b]metric 128[/b] dev virbr0 || true                                                                     
pourquoi ce "metric 128" ?