La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: dash 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
-
ip route get fd99:1234:beef:cafe:fade::7000 from fd99:1234:beef:cafe:fade::7fff
-
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.
-
Regarde la table local avant et après la création du tunnel.
$ ip -6 route show table local
-
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 ...
-
Qu'est-ce qui créé le tunnel? wg-quick ? systemd-networkd? ifupdown (/etc/network/interfaces) ?
ip -6 addr show wig0 ?
-
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
-
wg show wig0 allowed-ips ?
Est-ce que tu utilises l'intégration Wireguard d'ifupdown (https://github.com/ifupdown-ng/ifupdown-ng/blob/main/doc/interfaces-wireguard.scd) ou est-ce que tu configure à la main à coup de pre-up ?
-
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
-
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
-
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.
-
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.
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" ?
-
J'ai adapté comme demandé, rien n'y fait: si je ne remplace pas la route par
post-up ip r replace fd99:1234:beef:cafe:fade::7000 from fd99:1234:beef:cafe:fade::70ff dev $IFACE table local
c'est toujours l'interface lo qui répond et c'est là le problème. Avec la commande ci dessus cela route comme il faut.
Le 7000 est le serveur à l'autre extrémité. Concernant le metric à 128, c'est un reste de configuration antérieure, il a été retiré.
-
avec la modif mais sans ta route en plus ca donne quoi:
ip -6 aet
ip -6 r show table allet
ip route get fd99:1234:beef:cafe:fade::7000
et
ip route get fd99:1234:beef:cafe:fade::7000 from fd99:1234:beef:cafe:fade::7fff
on devrait y voir plus clair.
-
root@mango # ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:db8:120:1104::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::921b:eff:fe93:4cb1/64 scope link
valid_lft forever preferred_lft forever
5: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 500
inet6 fe80::3e73:2462:50ac:c643/64 scope link stable-privacy
valid_lft forever preferred_lft forever
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 500
inet6 fe80::c4b0:fd7:7945:dcc1/64 scope link stable-privacy
valid_lft forever preferred_lft forever
7: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fd99:1234:beef:cafe:fade::7010/124 scope global
valid_lft forever preferred_lft forever
inet6 2001:db8:120:1104::70:1/96 scope global
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe76:8e2e/64 scope link [2/207]
valid_lft forever preferred_lft forever
8: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 1000
inet6 fe80::fc54:ff:feda:7013/64 scope link
valid_lft forever preferred_lft forever
9: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 1000
inet6 fe80::fc54:ff:feda:7014/64 scope link
valid_lft forever preferred_lft forever
10: vnet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 1000
inet6 fe80::fc54:ff:feda:7015/64 scope link
valid_lft forever preferred_lft forever
11: vnet3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 1000
inet6 fe80::fc54:ff:feda:7011/64 scope link
valid_lft forever preferred_lft forever
12: vnet4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 1000
inet6 fe80::fc54:ff:feda:7012/64 scope link
valid_lft forever preferred_lft forever
31: wig1: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1436 state UNKNOWN qlen 1000
inet6 fd99:1234:beef:cafe:fade::71ff/120 scope global
valid_lft forever preferred_lft forever
32: wig0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1436 state UNKNOWN qlen 1000
inet6 fd99:1234:beef:cafe:fade::70ff/120 scope global
valid_lft forever preferred_lft forever
root@mango # ip -6 r show table all
::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 256 pref medium
fd99:1234:beef:cafe:fade::7000/120 dev wig0 proto kernel metric 256 pref medium
fd99:1234:beef:cafe:fade::7100/120 dev wig1 proto kernel metric 256 pref medium
fd99:1234:beef:cafe::/64 dev wig0 metric 1024 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev tun1 proto kernel metric 256 pref medium
fe80::/64 dev tun0 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
local ::1 dev lo table local proto kernel metric 0 pref medium
anycast 2001:db8:120:1104:: dev eth0 table local proto kernel metric 0 pref medium [18/267]
anycast 2001:db8:120:1104:: dev virbr0 table local proto kernel metric 0 pref medium
local 2001:db8:120:1104::2 dev eth0 table local proto kernel metric 0 pref medium
local 2001:db8:120:1104::70:1 dev virbr0 table local proto kernel metric 0 pref medium
anycast fd99:1234:beef:cafe:fade::7000 dev wig0 table local proto kernel metric 0 pref medium
local fd99:1234:beef:cafe:fade::7010 dev virbr0 table local proto kernel metric 0 pref medium
local fd99:1234:beef:cafe:fade::70ff dev wig0 table local proto kernel metric 0 pref medium
fd99:1234:beef:cafe:fade::7100 from fd99:1234:beef:cafe:fade::71ff dev wig1 table local metric 1024 pref medium
anycast fd99:1234:beef:cafe:fade::7100 dev wig1 table local proto kernel metric 0 pref medium
local fd99:1234:beef:cafe:fade::71ff dev wig1 table local proto kernel metric 0 pref medium
anycast fe80:: dev eth0 table local proto kernel metric 0 pref medium
anycast fe80:: dev tun0 table local proto kernel metric 0 pref medium
anycast fe80:: dev tun1 table local proto kernel metric 0 pref medium
anycast fe80:: dev vnet0 table local proto kernel metric 0 pref medium
anycast fe80:: dev vnet1 table local proto kernel metric 0 pref medium
anycast fe80:: dev vnet2 table local proto kernel metric 0 pref medium
anycast fe80:: dev virbr0 table local proto kernel metric 0 pref medium
anycast fe80:: dev vnet3 table local proto kernel metric 0 pref medium
anycast fe80:: dev vnet4 table local proto kernel metric 0 pref medium
local fe80::3e73:2462:50ac:c643 dev tun1 table local proto kernel metric 0 pref medium
local fe80::5054:ff:fe76:8e2e dev virbr0 table local proto kernel metric 0 pref medium
local fe80::921b:eff:fe93:4cb1 dev eth0 table local proto kernel metric 0 pref medium
local fe80::c4b0:fd7:7945:dcc1 dev tun0 table local proto kernel metric 0 pref medium
local fe80::fc54:ff:feda:7011 dev vnet3 table local proto kernel metric 0 pref medium
local fe80::fc54:ff:feda:7012 dev vnet4 table local proto kernel metric 0 pref medium
local fe80::fc54:ff:feda:7013 dev vnet0 table local proto kernel metric 0 pref medium
local fe80::fc54:ff:feda:7014 dev vnet1 table local proto kernel metric 0 pref medium
local fe80::fc54:ff:feda:7015 dev vnet2 table local proto kernel metric 0 pref medium
multicast ff00::/8 dev eth0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev tun1 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev tun0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev vnet0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev vnet1 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev vnet2 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev virbr0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev vnet3 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev vnet4 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev wig1 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev wig0 table local proto kernel metric 256 pref medium
root@mango # ip route get fd99:1234:beef:cafe:fade::7000
anycast fd99:1234:beef:cafe:fade::7000 from :: dev lo table local proto kernel src fd99:1234:beef:cafe:fade::70ff metric 0 pref medium
root@mango # ip route get fd99:1234:beef:cafe:fade::7000 from fd99:1234:beef:cafe:fade::7fff
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::70ff metric 0 pref medium
Merci pour ton aide
-
inet6 fd99:1234:beef:cafe:fade::70ff/120 scope global
ah c'est normal: 7000 c'est la premiere IP de ce subnet /120. Elle est réservée il ne faut pas s'en servir. c'est la "subnet router anycast addresses" , une address anycast qui permet de joindre le premier routeur du subnet.
c'est comme si tu utilisais l'adresse 0 d'un /64 (la premiere). on ne l'a pas vu de suite car on utilise jamais des /120 ou autre donc ce n'est pas un reflexe comme avec /64.
utilise 7001 par exemple ca devrait marcher.
verifiable avec "ip route get fd99:1234:beef:cafe:fade::7001"
pour eviter ceci tu peux utiliser l'utilitaire subnetcalc :
subnetcalc fd99:1234:beef:cafe:fade::7000/120
Address = fd99:1234:beef:cafe:fade::7000
fd99 = 11111101 10011001
1234 = 00010010 00110100
beef = 10111110 11101111
cafe = 11001010 11111110
fade = 11111010 11011110
0000 = 00000000 00000000
0000 = 00000000 00000000
7000 = 01110000 00000000
Network = fd99:1234:beef:cafe:fade::7000 / 120
Netmask = ffff:ffff:ffff:ffff:ffff:ffff:ffff:ff00
Wildcard Mask = ::ff
Hosts Bits = 8
Max. Hosts = 255 (2^8 - 1)
Host Range = { fd99:1234:beef:cafe:fade::7001 - fd99:1234:beef:cafe:fade::70ff }
Properties =
- fd99:1234:beef:cafe:fade::7000 is a NETWORK address
- Unique Local Unicast Properties:
+ Locally chosen
+ Global ID = 991234beef
+ Subnet ID = cafe
+ Interface ID = fade:0000:0000:7000
+ Sol. Node MC = ff02::1:ff00:7000
GeoIP Country = Unknown (??)
DNS Hostname = (Name or service not known)
ca indique le range des adresses valides: fd99:1234:beef:cafe:fade::7001 - fd99:1234:beef:cafe:fade::70ff
mais j'insiste vraiment des /120 ou autre horreur du genre ce n'est pas du tout recommandé.
-
dh@mango ~ $ ip route get fd99:1234:beef:cafe:fade::7001
fd99:1234:beef:cafe:fade::7001 from :: dev wig0 proto kernel src fd99:1234:beef:cafe:fade::70ff metric 256 pref medium
C'est effectivement fonctionnel sans avoir à remplacer la route. Je suis un peu honteux de ne pas avoir débusqué cette erreur, merci de l'avoir pointée. Pour le reste, j'adapterai suite à tes recommandations dès mon setup fonctionnel.
Un grand merci à toi et aux autres intervenants.