La Fibre
Télécom => Réseau => IPv6 => Discussion démarrée par: StardustOne le 05 juin 2020 à 20:19:21
-
Salut,
voici mon besoin fonctionnel:
____ ____ .-,( ),-.
| | | | .-( )-.
|____|--------------- |____|---------------> internet V6 )
/::::/ \ /::::/ '-( ).-'
desktop \ dedibox srv 1Gbps '-.( ).-'
400mbps symetrique
\ \
\ \
\ \
\ \
v \
.-,( ),-. v ____
.-( )-. | |
( internet V4 ) |____|
'-( ).-' /::::/
'-.( ).-' Hurricane Electric V6 tunnel
SFR FTTH IPV4
Mon desktop Debian10 a une interface avec IPv4 native SFR (je souhaite garder l'IPv4 de SFR sans passer par un VPN dual-stack avec l'IP dedibox). Il n'a pas dIPv6 malgré ma tentative d'activation (status 'non connecté via la box NB6VAC-MAIN-R4.0.41).
Je voudrais ajouter une stack IPv6. Je pourrais créer un tunnel ou un VPN avec l'IPv6 dedibox, mais les IPv6 sont souvent blacklistées pour de la navigation desktop (https://lafibre.info/ipv6/tunnel-hurricane-electric-peut-pinger-mais-pas-de-trafic/msg765937/#msg765937).
J'ai créé un tunnel Hurrican Electric (=~ 648mbps en DL) sur ma dedibox et viré mon interface SLAAC IPv6 dedibox.
Ce tunnel fonctionne bien (test OK avec 'traceroute -6 -i he-ipv6 lafibre.info').
Je ne peux pas utiliser le tunnel Hurrican Electric directement sur mon desktop, because le CPE SFR fait du caca avec le protocol 41, voir ce fil (https://lafibre.info/ipv6/tunnel-hurricane-electric-peut-pinger-mais-pas-de-trafic/12/) où on a investigué pour que j'en arrive à créer ce post de synthèse.
Ce que j'aimerais donc à présent faire, c'est de créer une interface virtuelle sur mon desktop, qui se servirait de ma dedibox comme relais pour accéder à l'IPv6 de Hurrican Electric.
J'aimerais utiliser un protocole qui fonctionne avec les CPE SFR et qui soit véloce en BP, j'ai une connexion 400mbps symétrique :
- OpenVPN beaucoup trop lent (et ma dedibox n'est pas un foudre de guerre en ressources système, je suis à 100% sur 4 coeurs dans 'htop' avec OpenVPN)
- ipsec: encore trop lent
- 'protocol 41', merde chez moi (CPE SFR)
- wireguard ?
- autre ?
Quelles seraient vos recommandations SVP pour récupérer une interface virtuelle IPv6 sur mon desktop avec dedibox comme relais et Hurrican Electric comme source de connectivité IPV6 ? (pas de solution dual-stack, IPv6 only)
Je suis loin d'être un expert réseau, je suis sysadmin Linux.
-
wireguard cf l'autre post. il te suffit d'activer le /48 chez HE , il sera routé vers ton dédibox.
du coup dans le dedibox tu peux renvoyer le 1er /64 du /48 via wireguard ou carrement tout le /48 si tu veux faire plusieurs réseaux (ou du docker) dans ton debian desktop.
(https://nimbus-screenshots.s3.amazonaws.com/s/05a68ba2c139b66496af2d8a7b33f85f.png)
donc la partie peer coté dedibox t'as juste à mettre dans "AllowedIPs =" ce bloc /48 ou juste un /64 de ce bloc (ou un /60 , suivant tes besoins).
Tu peux aussi te contenter du "Routed /64" fournit par HE mais s"il n'est pas utilisé dans la dedibox.
-
OK, j'ai activé le /48 et j'ai mis à jour l'IPv6 de Hurrican Electric dans la conf wireguard.
Conf coté serveur dedibox :
[Interface]
Address = fe80::1/64
SaveConfig = true
ListenPort = 1094
PrivateKey = x
[Peer]
PublicKey = y
AllowedIPs = 2001:<CUT>::/48, fe80::/64
Endpoint = <IPv4 publique desktop>
Coté desktop:
[Interface]
Address = fe80::2/64
PrivateKey = a
PostUp = ip -6 route add fe80::1 dev wg0
PostDown = ip -6 route del fe80::1 dev wg0
DNS = 80.67.169.12
ListenPort = 1094
[Peer]
PublicKey = b
Endpoint = <IPv4 public dedibox>:1094
AllowedIPs = ::/0, fe80::/64
PersistentKeepalive = 25
Grace à la route que j'ai ajouté coté desktop, je peux ping sans préciser l'interface:
$ ping -c1 fe80::1
PING fe80::1(fe80::1) 56 data bytes
64 bytes from fe80::1%wg0: icmp_seq=1 ttl=64 time=3.76 ms
--- fe80::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.764/3.764/3.764/0.000 ms
Par contre, il me manque sûrement quelque chose, car je n'ai pas de connectivité IPv6 sur mon desktop vers l'internet mondial:
$ ping6 -c1 lafibre.info
PING lafibre.info(lafibre.info (2a01:6e00:10:410::2)) 56 data bytes
From fe80::1%wg0 (fe80::1%wg0): icmp_seq=1 Destination unreachable: Beyond scope of source address
--- lafibre.info ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
routes coté desktop (pas clair pour moi ce qui est pris par le VPN ou pas...)
$ ip -6 r
::1 dev lo proto kernel metric 256 pref medium
fe80::1 dev wg0 metric 1024 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 256 pref medium
fe80::/64 dev wg0 proto kernel metric 256 pref medium
PS: Ne pars pas du principe que je suis à l'aise en réseau, STP si tu peux me donner les commandes à taper. J'ai essayé plein de bidouilles, mais je galère ;)
-
deja simplifions la conf:
pas besoin de mettre cela:
PostUp = ip -6 route add fe80::1 dev wg0
PostDown = ip -6 route del fe80::1 dev wg0
car ce n'est pas une bonne pratique.
les addresse fe80... sont particulieres en IPv6, elles ne sont pas forcement unique globalement mais toujours liés a une interface et uniques que sur le lien local a cette interface (on les appele link-local). il est donc plus que conseillé de ne pas faire cela.
pour le reste, voici quelques commandes pour debug:
il faudrait voir les routes coté dedibox et coté desktop:
ip -6 route table all
on met "table all" car wg-quick utilise une table speciale pour la route par défaut quand on met ::/0 dans AllowedIPs
on peut aussi utiliser juste:
ip -6 route list table all default
[/tt]
'default' indique qu'on que voir la route par défaut.
coté desktop ca doit être "dev wg0" sinon c'est pas bon.
coté dedibox ca doit être le tunnel he
et coté dedibox il doit y avoir une route pour le /48 vers wg0
tu peux aussi utilise "ip route get ip_de_destination" pour voir la route utilisé pour joindre une ip particuliere:
lafibre.info = 2a01:6e00:10:410::2
ip route get 2a01:6e00:10:410::2
sur le desktop ca doit afficher un truc du genre:
2a01:6e00:10:410::2 from :: dev wg0 table ttttt src 2001:xxxxxxx metric 1024 pref medium
c'est pratique ca montre quelle ip source (src) ca utilise pour joindre cette destination.
fait la meme sur le dedibox pour voir.
pour voir les IPv6 des interfaces de facon résumé:
ip -br -6 a
avant de ping lafibre.info essai de ping l'ip du tunnel he coté dedibox par exemple ('Client IPv6 Address' dans la page HE).
-
OK pour mes routes de lien locaux, enlevés.
J'ai remis la conf en /64 partout.
Je ping mon IPv6 HE serveur et toutes adresses IPv6 depuis ma dedibox. Je ne ping pas l'IPv6 HE serveur depuis le desktop :
$ ping -c1 2001:<CUT>:38f::1
PING 2001:<CUT>:38f::1(2001:470:1f12:38f::1) 56 data bytes
From fe80::1%wg0: icmp_seq=1 Destination unreachable: Beyond scope of source address
--- 2001:<CUT>:38f::1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
Pour rappel, je peux ping l'IP HE dedibox depuis mon desktop mais pas d'autres ipv6 autres que sur le serveur dedibox (fe80::1).
'ip -6 route table all' ne fonctionne pas, en revanche 'ip -6 route list table all default' si, donc:
Sur le desktop:
route par defaut (OK):
ip -6 route list table all default
default dev wg0 table 51820 metric 1024 pref medium
routes:
ip -6 r
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 256 pref medium
fe80::/64 dev wg0 proto kernel metric 256 pref medium
route vers lafibre.info (OK):
ip route get 2a01:6e00:10:410::2
2a01:6e00:10:410::2 from :: dev wg0 table 51820 src fe80::2 metric 1024 pref medium
ip -br -6 a
lo UNKNOWN ::1/128
enp0s31f6 UP fe80::3ad5:47ff:fe15:d0f3/64
wg0 UNKNOWN fe80::2/64
Sur dedibox:
route par defaut (OK):
default via 2001:<CUT>:38f::1 dev he-ipv6 metric 1024 onlink pref medium
routes:
ip -6 route·
::1 dev lo proto kernel metric 256 pref medium
2001:<CUT>::/64 dev wg0 metric 1024 pref medium
2001:<CUT>:38f::1 dev he-ipv6 metric 1024 pref medium
2001:<CUT>:38f::/64 dev he-ipv6 proto kernel metric 256 pref medium
fe80::/64 dev enp1s0 proto kernel metric 256 pref medium
fe80::/64 dev he-ipv6 proto kernel metric 256 pref medium
fe80::/64 dev wg0 proto kernel metric 256 pref medium
default via 2001:<CUT>:38f::1 dev he-ipv6 metric 1024 onlink pref medium
route vers lafibre.info (OK):
ip route get 2a01:6e00:10:410::2
2a01:6e00:10:410::2 from :: via 2001:<CUT>:38f::1 dev he-ipv6 src 2001:<CUT>:38f::2 metric 1024 pref medium
ip -br -6 a
lo UNKNOWN ::1/128
enp1s0 UP fe80::208:a2ff:fe0c:631a/64
he-ipv6@NONE UNKNOWN 2001:<CUT>::2/64 fe80::339f:3773/64
wg0 UNKNOWN fe80::1/64
Je vois que ça avance, mais il reste une conf quelque part pour laisser opérer la 'magie' :)
-
c'est normal tu n'a pas d'IPv6 public sur ton desktop du coup il ne peut aller au dela du tunnel...
route vers lafibre.info (OK):
ip route get 2a01:6e00:10:410::2
2a01:6e00:10:410::2 from :: dev wg0 table 51820 src fe80::2 metric 1024 pref medium
c'est tres visible la: pour joindre lafibre.info ta source est une ip link-local (src fe80::2) ce qui n'est pas bon: tes paquets de retour n'arrivent jamais car ton desktop n'a pas d'adresse public.
Les pings vers dedibox marchent parce que la dedibox sait joindre fe80::2%wg0.
ip -br -6 a
lo UNKNOWN ::1/128
enp0s31f6 UP fe80::3ad5:47ff:fe15:d0f3/64
wg0 UNKNOWN fe80::2/64
on voit qu'il te manque cette IPv6 public (on dit GUA = global unicast address) , aucune interface n'en a.
tu peux la mettre sur enp0s31f6 (lan?) par exemple ou sur une interface virtuelle (on peut aussi la mettre sur wg0 mais ce n'est pas propre...) ou sur le looback (lo) (idéalement sur une interface physique pour avoir les accélérations matérielles du driver).
une bonne pratique est toujours de faire un dessin avec le plan d'adressage pour voir ou son les réseaux (/64 ou plus) et si on en a pas oublié.
-
OK, j'ai donc ajouté une nouvelle IPv6 publique à mon interface physique sur mon desktop:
ip addr add 2001:<CUT>::3/64 dev enp0s31f6
IPs HE:
la *:1 est le serveur HE
la *:2 dedibox
et la *:3 le desktop
route vers lafibre.info (passe par ma nouvelle ip publique et via l'interface wireguard):
ip route get 2a01:6e00:10:410::2
2a01:6e00:10:410::2 from :: dev wg0 table 51820 src 2001:<CUT>:38f::3 metric 1024 pref medium
Je ne peut pas ping ma nouvelle ip publique desktop depuis la dedibox ni ping l'ip HE de la dedibox depuis mon desktop.
Évidement pas ping une IPv6 du net publique.
Il doit manquer une ou des routes, mais je sèche malgré pas mal d'essais infructueux.
-
la *:1 est le serveur HE
la *:2 dedibox
et la *:3 le desktop
deja ca ce n'est pas bon.
Un meme prefix /64 ne peut etre sur plusieurs liens.
un lien =
- un réseau local (ethernet+wifi par exemple)
- un tunnel wg
- un tunnel he
Les machines qui tu cites ne peuvent avoir des IPv6 sur le meme /64 car elle ne partagent pas le meme lien.
- le serveur HE et le dedibox partagent un lien, le tunnel HE, ils ont chacun une IPv6 d'un meme /64 a chaque bout de ce lien ("Server IPv6 Address" et "Client IPv6 Address" dans la page de config d'HE). Ce /64 n'est pas utilisable ailleurs.
- le dedibox et le desktop partagent un lien,le tunnel wireguard, on n'a pas besoin d'IP (v4 ou v6) la dessus, on a mis des IPv6 de type "link-local" (fe80...) uniquement pour faire des tests locaux de ping.
HE fournit 2 /64 de base plus un /48 optionnel.
- le /64 pour le tunnel : il n'a que 2 IPv6 utilisables: Server IPv6 Address et Client IPv6 Address
- le /64 routé: le 'Routed /64' que tu peux utiliser soit dans le dedibox soit dans le desktop mais pas les 2. Si tu l'utilise dans le dedibox dans ce cas il te faut utilise le /48 pour le desktop (ou au moins un /64 du /48). Si tu n'utilise pas le /64 dans le dedibox dans ce cas tu peux l'utiliser dans le desktop, du coup tu n'a pas besoin du /48.
cas 1: pas besoin du /48
- tu mets le "Routed /64" dans la config wg du dedibox dans la partie "AllowedIPs" du peer desktop
- tu prend une adresse quelconque du "Routed /64" (..::1 par exemple) et tu la met sur l'interface enp0s31f6 du desktop
(chez HE le /64 pour le tunnel et le Routed /64 sont tres proches, ils différent de 1 dans la 3eme partie des l'adresse- attention donc a pas les confondre)
cas 2: utilisation du /48
- tu mets le "Routed /48" (ou une sous partie) dans la config wg du dedibox dans la partie "AllowedIPs" du peer desktop
- tu prend une addesse quelconque du "Routed /48" (..::1 par exemple) et tu la met sur l'interface enp0s31f6 du desktop
- tu peux utiliser le "Routed /64" sur la dedibox (vm, docker, etc ou pour un autre tunnel wg).
-
OK, cas N°1.
Donc j'ai mon tunnel HE sur dedibox avec 'Client IPv6 Address' de set, qui fonctionne parfaitement.
J'ai viré mon ip du même /64 que le tunnel de la dedibox sur mon desktop et créé une nouvelle IPv6 HE: ip 'Routed /64' (*::1).
Par contre il doit rester encore au moins une étape :)
(https://i.imgur.com/Y9etJr3.jpg)
-
(https://drive.google.com/file/d/1g9Khs2kZVjtBcl3yC2YTm8DpRveyMVnL[quote author=StardustOne link=topic=43196.msg766442#msg766442 date=1591452731]
OK, cas N°1.
Donc j'ai mon tunnel HE sur dedibox avec 'Client IPv6 Address' de set, qui fonctionne parfaitement.
J'ai viré mon ip du même /64 que le tunnel de la dedibox sur mon desktop et créé une nouvelle IPv6 HA: ip 'Routed /64' (*::1).
Par contre il doit rester encore au moins une étape :)
[/quote])
ajuster la config wireguard (allowedips dans la partie peer) dans le dedibox et rafraichir le tunnel.
"ip -6 route" coté dedibox ca donne quoi ?
-
j'ai repris un schéma et adapté a ton cas:
(https://drive.google.com/uc?id=1g9Khs2kZVjtBcl3yC2YTm8DpRveyMVnL)
En réseau; toujours faire un schéma meme a la main avec les prefix réseaux bien indiqués et toujours penser aux flux dans les 2 sens (un ping est un aller et retour).
source du schéma : https://app.diagrams.net/?title=tunnel%20he%20and%20wg.html#Uhttps%3A%2F%2Fdrive.google.com%2Fuc%3Fid%3D0B5ma-el6j-bDU1Zwd2haMXRULXc%26export%3Ddownload
-
routes coté dedibox:
::1 dev lo proto kernel metric 256 pref medium
2001:<CUT>:38f::1 dev he-ipv6 metric 1024 pref medium
2001:<CUT>:38f::/64 dev he-ipv6 proto kernel metric 256 pref medium
fe80::/64 dev enp1s0 proto kernel metric 256 pref medium
fe80::/64 dev he-ipv6 proto kernel metric 256 pref medium
default via 2001:<CUT>:38f::1 dev he-ipv6 metric 1024 onlink pref medium
Dans wireguard:
AllowedIPs = 2001:<CUT>::/64, fe80::/64 # correspond à 'routed /64' sur HE
-
la dedibox ne sait pas joindre "routed /64" il n'apparait pas dans sa table de routage.
tu fais comment pour monter les tunnels wg ?
-
A chaque étape, je fais un :
systemctl restart wg-quick@wg0
des 2 cotés
-
oui c'est ca. mais il manque la route la.
journalctl -b -t wg-quick
pour voir les détails.
-
Dernier lancement:
Jun 06 16:03:10 mail1 wg-quick[7597]: [#] wg showconf wg0
Jun 06 16:03:10 mail1 wg-quick[7597]: [#] ip link delete dev wg0
Jun 06 17:06:13 mail1 wg-quick[8126]: [#] ip link add wg0 type wireguard
Jun 06 17:06:13 mail1 wg-quick[8126]: [#] wg setconf wg0 /dev/fd/63
Jun 06 17:06:13 mail1 wg-quick[8126]: [#] ip -6 address add fe80::1/64 dev wg0
Jun 06 17:06:14 mail1 wg-quick[8126]: [#] ip link set mtu 1420 up dev wg0
Jun 06 17:06:14 mail1 wg-quick[8126]: [#] ip -6 route add 2001:<CUT>::/64 dev wg0
La dernière commande étant l'IP du réseau du 'Routed /64'
-
donc y'a bien la route ? c'est plus tres clair
pour debugger il faut les routes et les adresses des 2 cotés.
"ip -6 route" coté dedibox
"ip -6 route list table all" coté deskstop (ou juste "ip -6 route list default table all" si le 1er est trop long)
"ip -br -6 a" des 2 cotés.
-
dedibox
# ip -6 route
::1 dev lo proto kernel metric 256 pref medium
2001:<Server IPv6 Address>:38f::1 dev he-ipv6 metric 1024 pref medium
2001:<Server IPv6 Address>:38f::/64 dev he-ipv6 proto kernel metric 256 pref medium
2001:<Routed /64>::/64 dev wg0 metric 1024 pref medium
fe80::/64 dev enp1s0 proto kernel metric 256 pref medium
fe80::/64 dev he-ipv6 proto kernel metric 256 pref medium
fe80::/64 dev wg0 proto kernel metric 256 pref medium
default via 2001:<Server IPv6 Address>:38f::1 dev he-ipv6 metric 1024 onlink pref medium
ip -br -6 a
lo UNKNOWN ::1/128·
enp1s0 UP fe80::208:a2ff:fe0c:631a/64·
he-ipv6@NONE UNKNOWN 2001:<Server IPv6 Address>:38f::2/64 fe80::339f:3773/64·
wg0 UNKNOWN fe80::1/64·
desktop:
# ip -6 route list table all
default dev wg0 table 51820 metric 1024 pref medium
::1 dev lo proto kernel metric 256 pref medium
2001:<Routed /64>::/64 dev enp0s31f6 proto kernel metric 256 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 256 pref medium
fe80::/64 dev wg0 proto kernel metric 256 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local 2001:<Routed /64>::1 dev enp0s31f6 table local proto kernel metric 0 pref medium
anycast fe80:: dev wg0 table local proto kernel metric 0 pref medium
local fe80::2 dev wg0 table local proto kernel metric 0 pref medium
local fe80::3ad5:47ff:fe15:d0f3 dev enp0s31f6 table local proto kernel metric 0 pref medium
ff00::/8 dev enp0s31f6 table local metric 256 pref medium
ff00::/8 dev wg0 table local metric 256 pref medium
ip -br -6 a
lo UNKNOWN ::1/128·
enp0s31f6 UP 2001:<Routed /64>::1/64 fe80::3ad5:47ff:fe15:d0f3/64·
wg0 UNKNOWN fe80::2/64
-
ca a l'air correct.
y'a bien le routage IPv6 d'activé dans le dedibox ?
sudo sysctl net.ipv6.conf | grep forwarding
affiche quoi ?
-
sysctl net.ipv6.conf | grep '\.forwarding'
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.enp1s0.forwarding = 1
net.ipv6.conf.he-ipv6.forwarding = 1
net.ipv6.conf.lo.forwarding = 1
net.ipv6.conf.sit0.forwarding = 1
net.ipv6.conf.wg0.forwarding = 1
(idem en IPv4)
sysctl net.ipv6.conf | grep 'forwarding'
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.mc_forwarding = 0
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.default.mc_forwarding = 0
net.ipv6.conf.enp1s0.forwarding = 1
net.ipv6.conf.enp1s0.mc_forwarding = 0
net.ipv6.conf.he-ipv6.forwarding = 1
net.ipv6.conf.he-ipv6.mc_forwarding = 0
net.ipv6.conf.lo.forwarding = 1
net.ipv6.conf.lo.mc_forwarding = 0
net.ipv6.conf.sit0.forwarding = 1
net.ipv6.conf.sit0.mc_forwarding = 0
net.ipv6.conf.wg0.forwarding = 1
net.ipv6.conf.wg0.mc_forwarding = 0
-
hum curieux. relis bien les IP peut-etre y'a une erreur quelque part ?
il doit pas manquer grand chose.
"traceroute -6 -n" depuis le desktop vers "Server IPv6 Address" ca donne quoi? puis vers lafibre.info ?
et depuis l'exterieur vers 2001:<Routed /64>::1 ? (par exemple avec ce site: https://www.ultratools.com/tools/traceRoute6 )
-
Depuis un autre serveur (OVH):
ovh # ping -c1 2001:<Routed /64>::1
PING 2001:<Routed /64>::1(2001:<Routed /64>::1) 56 data bytes
From 2001:470:0:7b::2: icmp_seq=1 Destination unreachable: No route
--- 2001:<Routed /64>::1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
Par contre, via ton site https://www.ultratools.com/tools/traceRoute6Result, les 3 premiers 'hop' sont en time-out, mais il arrive à retrouver 'tserv1.par1.he.net' en 10 'hop' (last hop)
Et 'mtr' s'en sort mieux, il trouve très bien sa route:
ovh # mtr -6btz 2001:<Routed /64>::1
My traceroute [v0.92]
xxx (xxx) 2020-06-07T02:39:14+0200
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. AS16276 xxxxxxxxxxxxxxxx.fr.eu (2001:<XXXXXXXXXXXXXX>) 0.0% 11 0.8 0.9 0.8 1.4 0.2
2. AS16276 2001:41d0:0:5:3::10a (2001:41d0:0:5:3::10a) 0.0% 11 0.7 0.7 0.6 0.7 0.1
3. AS16276 2001:41d0:0:5:2::42 (2001:41d0:0:5:2::42) 0.0% 11 0.9 0.9 0.8 1.1 0.1
4. AS16276 be100.rbx-g1-nc5.fr.eu (2001:41d0::60a) 70.0% 11 88.0 59.1 1.6 88.0 49.8
5. AS16276 be100-1048.ams-1-a9.nl.eu (2001:41d0::61d) 36.4% 11 6.4 6.2 6.0 6.4 0.1
6. ???
7. AS6939 100ge9-2.core1.par2.he.net (2001:470:0:349::1) 0.0% 11 9.8 13.0 9.7 27.5 7.0
8. ???
Depuis le desktop:
desktop # traceroute -6 -n 2001:<Client IPv6 Address>:38f::1
traceroute to 2001:<Client IPv6 Address>:38f::1 (2001:<Client IPv6 Address>:38f::1), 30 hops max, 80 byte packets
1 2001:<Client IPv6 Address>:38f::2 3.838 ms 3.819 ms 3.811 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
desktop # traceroute -6 -n lafibre.info
traceroute to lafibre.info (2a01:6e00:10:410::2), 30 hops max, 80 byte packets
1 2001:<Client IPv6 Address>:38f::2 3.785 ms 3.802 ms 4.448 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
-
ca bloque dans le debibox on dirait. y'a pas un firewall ou truc du genre ?
-
Je viens de 'flush' desktop ET dedibox, sans changement.
Edit:Si je lance un 'tcpdump', je constate qu'un ping6 depuis le desktop vers une ip publique n'a jamais de réponse contrairement au même ping depuis dedibox.
(on a que src->dst et non src->dst/dst->src)
-
bonjour,
quelque chose m'intrigue et du coup me fait me poser une question sur ce que je fais moi :)
on voit qu'il te manque cette IPv6 public (on dit GUA = global unicast address) , aucune interface n'en a.
tu peux la mettre sur enp0s31f6 (lan?) par exemple ou sur une interface virtuelle (on peut aussi la mettre sur wg0 mais ce n'est pas propre...) ou sur le looback (lo) (idéalement sur une interface physique pour avoir les accélérations matérielles du driver).
pourquoi ce n'est pas propre que wg0 porte l'ipv6 vu que c'est par lui que ça sort ?
merci,
Jerem
-
Je viens de 'flush' desktop ET dedibox, sans changement.
Edit:Si je lance un 'tcpdump', je constate qu'un ping6 depuis le desktop vers une ip publique n'a jamais de réponse contrairement au même ping depuis dedibox.
(on a que src->dst et non src->dst/dst->src)
le mieux est de tcpdump l'interface he-ipv6 du dedibox et faire un ping sortant depuis le desktop et un ping entrant depuis l'exterieur et voir ce qui passe/passe pas.
si le ping entrant n'est pas visible c'est que le souci est chez HE (ou 'routed ipv6' n'est pas bon).
bonjour,
quelque chose m'intrigue et du coup me fait me poser une question sur ce que je fais moi :)
pourquoi ce n'est pas propre que wg0 porte l'ipv6 vu que c'est par lui que ça sort ?
merci,
Jerem
parce que ca consomme un /64 pour rien d'autre que ca. Apres c'est sur que tant qu'il n'a qu'une machine (virtuelle ou réelle) ca revient au meme mais ce n'est pas forcement tres évolutif et souple (dans le cas d'HE on a un /48 en plus mais ce n'est pas toujours le cas).
en plus en terme de sécurité c'est mieux que le tunnel n'ai pas d'IPv6 globale comme ca pas besoin d'avoir de firewalling dessus.
en terme de conf aussi c'est plus souple, la conf du tunnel est indépendante de ce qui passe dedans (car on n'utilise pas forcement wg-quick).
bref si en réseau, si on peut autant séparer les choses le plus possible.
-
OK, suis repartis from scratch, et j'utilise à présent le routed /48. A tète reposée ça va mieux qu'en insistant quand 'ça marche pas'.
C'est beaucoup mieux. Tout fonctionne ! (à part ip6tables)
Il reste un dernier point, c'est que je suis obligé de commenter la regle par defaut FORWARD dans ip6tables sur dedibox.
De quelle règle spécifique de FORWARD a t-il besoin ?
Voici sa conf:
*filter
:INPUT DROP [0:0]
#:FORWARD DROP [780:62400] # probleme ici, il me faut autoriser le FORWARD de façon plus spécifique que de commenter la ligne
:OUTPUT ACCEPT [4914:487934]
-A INPUT ...
[... autres ligne traitant le filtre INPUT ...]
COMMIT
Test de perfs de notre œuvre:
- dl ipv4: 459 Mbits/sec
- dl ipv6: 280 Mbits/sec # pas ouf
- ping latency ipv4 13 ms
- ping latency ipv6 17 ms
Bon en tout cas, voici une dual-stack fonctionelle
-
Le debit c'est pas étonnant, ca dépend de la puissance cpu de chaque coté du tunnel wireguard. Il faut comparer avec le débit IPv6 du dedibox aussi pour voir combien le tunnel wireguard impact sur le debit HE. Si ca trouve la limite ne vient pas du tunnel wireguard.
Si ton systeme rajoute des blocages iptables6 sur l'interface wg0 , ca c'est toi qui décide en fonction de ce que tu veux filtrer ou pas vers le desktop. Chaque distro Linux a ses différences la. Par défaut la plupart n'ont pas de règles iptables6 actives par défaut.
Le plus simple est virer les regles ip6tables si y'en a et faire les sécurité sur le desktop (ou les virer que sur wg0).
sinon un statefull firewall = les memes regles que tu as mais sur la chaine FORWARD (limité éventuellement a l'interface wg0 ou pas).
le trafic IPv6 venant du Net et entrant dans le tunnel he-ipv6 puis en sortant ne passe par INPUT mais par FORWARD:
donc si tu FORWARD DROP tout par défaut ca bloque tout.
Il faut aussi autoriser les ICMPv6 sur INPUT et OUTPUT pour notamment pour signaler les paquets trop grands par exemple.
(https://i.stack.imgur.com/4wdkF.png)
-
Mon test de débit ipv6, sur le dedibox, j'obtiens un très correct 90MB/s (720Mbps) avec:
wget -O /dev/null http://ipv6.bouygues.testdebit.info/10G.iso
(interfaces 1Gbps dedibox/desktop)
Donc le tunnel wireguard bouffe une très grosse partie (1 tier) de BP en calculs, sauf erreur.
Lors du test, 'top' sur dedibox me donne 23% d'utilisation CPU pour 'kworker/0:2-wg-crypt-wg0'
(Ce qui est peu par rapport à un OpenVPN de base). 5% d'utilisation CPU sur le desktop qui est mieux fournit en ressources.
Comment crée tu tes schémas réseaux ? Sûrement visio?
__ __ _____ ____ ____ ___
| \/ | ____| _ \ / ___|_ _|
| |\/| | _| | |_) | | | |
| | | | |___| _ <| |___ | |
|_| |_|_____|_| \_\\____|___|
88 88
,d 88 88
88 88 88
MM88MMM 88,dPPYba, ,adPPYYba, 8b,dPPYba, 88 ,d8 8b d8 ,adPPYba, 88 88
88 88P' "8a "" `Y8 88P' `"8a 88 ,a8" `8b d8' a8" "8a 88 88
88 88 88 ,adPPPPP88 88 88 8888[ `8b d8' 8b d8 88 88
88, 88 88 88, ,88 88 88 88`"Yba, `8b,d8' "8a, ,a8" "8a, ,a88
"Y888 88 88 `"8bbdP"Y8 88 88 88 `Y8a Y88' `"YbbdP"' `"YbbdP'Y8
d8'
d8'
-
de rien.
pour les schémas j'utilise https://app.diagrams.net/ (anciennement https://draw.io ) c'est gratuit, open source (https://github.com/jgraph/drawio) et ca tourne 100% dans un navigateur web avec stockage local ou dans le cloud.