La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: yrousse le 16 août 2016 à 13:41:03
-
J'ai besoin de vos lumières…
J'ai posé un Strongswan sur une Dedibox XC pour faire ceci en gros: clients (IPv4 en FTTH/4G) <-ipsec-> dedibox <-> internet(IPv4/IPv6)
Et j'obtiens bien mes IPs (v4/v6) sur mes clients (OSX/iOS).
Pour IPv4, c'est bien sur un /24 privé que je masquerade ensuite et ça se passe "bien" : je route avec un joli débit, de l'ordre 150-400 Mbps selon le serveur sollicité (iperf/curl) et selon la machine cliente. C'est cohérent et je suis content. :)
En revanche, sur IPv6, c'est plus compliqué… car j'ai des résultats insatisfaisants que je n'arrive pas à analyser.
À priori, j'ai des "trucs" qui fonctionnent: Je me donne un petit bout (/112) du /56 de la Dedibox pour mes clients et je peux pinguer dehors, faire des iperf avec des résultats plus que corrects et proches de l'IPv4. Toujours content… RàS ici, à part mon autosatisfaction. :P
Sauf que… Si je fais un curl sur mon OSX, c'est la catastrophe: Je ne vais pas dépasser les 100 kbps! Et ça pique…
Je vais voir aussi les conséquences de ce débit sur des services "IPv6-enabled" comme youtube.com, par exemple, sur lequel je vais buffériser en QVGA! :o
(pour info, si je wget en IPv6 les même fichiers depuis ma dedibox, je tape le gigabit sans sourciller)
Et là, je sèche… Car je ne vois pas sur quel aspect de ma config je dois me pencher. Je ne vois pas pourquoi HTTP/HTTPS poseraient spécifiquement un problème (vs le iperf qui performe très bien, par exemple). Aucun ratelimit sur mon firewall (géré avec Shorewall). En l'état de cette mise en place, pour la zone de ce "vpn", c'est openbar. Et j'ai un mss=1328 sur le tunnel IPv4 (encore une fois, la connectivité IPv4 est nickel (et les clients Apple posent un MTU=1280 par défaut pour IPv6 donc je doute fortement de subir une fragmentation excessive ici))
Je loupe un truc bien massif, je le sens.
Des suggestions?
-
Un petit wireshark sur ipsec0 de mon OSX : la connectivité IPv4 est sans reproche. Donc ici, je me dis que mon tunnel passe bien par les segments successifs du réseau, y compris mon routeur local, ma Dedibox, etc…
En revanche, sur IPv6, j'ai *énormèment* de paquets avec TCP Retransmission et DUP ACK.
Toujours demandeur de suggestions...
-
Est-ce que tu as un graphique?
-
Je dessine très mal… ;)
Et ce que j'ai monté reste simple (un tunnel pour le routeur @ home viendra plus tard):
Ipsec over IPv4 FAI
Net <====> Dedibox <=========> Clients OSX/iOS
IPv4_publique 10.42.42.0/24
2001:DB8:1:200::1/128 2001:DB8:1:210::/112
Quelques éléments de mon ipsec.conf
authby=pubkey
leftsubnet=0.0.0.0/0,::/0
left= IPv4_publique,2001:DB8:1:200::1
right=%any
rightsourceip=10.42.42.0/24,2001:DB8:1:210::/112
Les routes sont bonnes. Comme déjà évoqué, la connectivité IPv4 ne pose aucun soucis. Et je sors aussi en IPv6 (hormis les retransmissions TCP...) et je peux pinguer en IPv6 mes clients depuis l'extérieur.
-
Je pense que corrector parlait d'un graphe wireshark pour voir où sont perdus les paquets.
-
Heu… Ah oui, bien sur. Je ne sors pas souvent Wireshark et j'avais la tête dans mes logs. Ceci dit je n'ai rien vu qui me soit utile coté graphiques.
@corrector : quel graph te paraitrait le plus pertinent?
-
J'ai fait ce graph avec des filtres qui m'ont paru "pertinents"...
-
J'ai vérifié la situation IPv6 coté MTU du tunnel et ma Dedibox annonce bien son MTU physique - overhead IPsec (soit 1422 dans mon cas) quand je ping6 mon client avec du gros paquet flagué DF. Bref, elle fait son job d'intermédiaire sur ce point.
Et de son coté, mon client OSX annonce un MSS=1340 lors de ses TCP SYN.
Je pense que mon tunnel est ok de ce coté-là.
J'ai aussi fait un tcpdump sur la Dedibox. Tout est ok sur le segment Dedibox <-> Net mais je vois les mêmes erreurs TCP retransmission, Dup ACK quand les paquets voyagent pour mon client OSX.
Plus précisèment, des ACK de mon OSX qui ne sont pas vus et le serveur sollicité ré-èmet ses paquets. Éventuellement, "Normal, c'est TCP" mais le nombre de ces séquences est très important. Et si j'avais un soucis dans la cohésion de mon tunnel IPsec, la connectivité IPv4 en souffrirait également. Ce n'est pas le cas.
J'ai du drop de paquets IPv6 quelque part et je ne le vois pas. :-[ :-[
-
C'est normal de voir les mêmes paquets de demande de retransmission sur tout le réseau.
Pour analyser d'où viens la perte de paquet, qui engendre un faible débit, il faudrait capturer un même transfert au plusieurs endroits et voir entre quel segment du réseau le paquet suivit disparait.
-
C'est normal de voir les mêmes paquets de demande de retransmission sur tout le réseau.
Pour analyser d'où viens la perte de paquet, qui engendre un faible débit, il faudrait capturer un même transfert au plusieurs endroits et voir entre quel segment du réseau le paquet suivit disparait.
La seule chose que j'ai pu faire jusqu'à présent a été d'initier un transfert similaire en http directement depuis la Dedibox. Avec juste quelques retransmissions "normales" ici et là, je fais 1 Gbps facile sur ping6.online.net et plusieurs centaines de Mbps ailleurs.
Une chose est claire pour moi, je perds du paquet à l'un des extrémités de mon tunnel IPsec. Ce dernier en lui-même me semble ok (les paquets esp voyagent correctement) car IPv4 over IPsec est ok ici.
La config coté client (je devrais plutôt parler du coté "droit" du tunnel) est plutôt triviale et est essentiellement faite pour la gestion de la sécurité (certificat/clefs).
Donc c'est selon moi la config sur la Dedibox qui pose soucis et là, entre le fait d'avoir IPv4/IPv6 over IPsec over IPv4(FAI) et Shorewall pour la gestion des IPtables, je me sens un peu perdu. Aucune doc ou tuto ne couvre ce type de setup.
C'est pour celà que je sollicite des suggestions et que je n'ai pas posté mes fichiers de config: je vais devoir concilier le tout par moi-même. ;D
Le souci, c'est que ce n'est pas "tranché", du paquet IPv6 passe en TCP par le tunnel, des négos se font, etc… Et parfois (et donc ici, trop souvent) non.
Shorewall ne drop aucun paquet pourtant (à part tous ces amis à-moi-que-j'ai qui viennent vérifier mon port Telnet…).
-
J'ai fait ce graph avec des filtres qui m'ont paru "pertinents"...
Bah alors là j'ai appris un truc, je savais pas qu'on pouvait faire des graphs comme ça sur Wireshark :o
Merci pour l'info :p
-
yrousse, tu as trouvé la solution ?
Tu nous feras un petit tuto ?
@TroniQ89 Wireshark sait faire plusieurs types de graphes qui permettent de comprendre l'origine ds pb réseaux. C'est vraiment un outil génial et sans équivalent en propriétaire (heureusement que c'est de l'open source, beaucoup seraient prêt a payer cher ce type d'outil)
-
Salut Vivien,
Non, pas encore… :(
Du coup, je me suis attaqué à la réalisation d'un tunnel IPv6 over IPSEC over IPv4… entre mon Ubiquiti ER-X et ma Dedibox.
Je me demande encore pourquoi tellement je m'arrache le peu de cheveux qu'il me reste. ;) Au moins je "ping6" depuis l'ER-X. Ça sent déjà la prouesse, moi je dis. ::) D'autant que l'ER-X n'est pas prévu pour faire de l'IPv6 over IPSEC en natif depuis le CLI, il faut encapsuler (gre, vti, sit...) et je veux l'éviter compte tenu que StrongSwan sait le faire nativement. Mais j'ai un problème sur les routes dans le routeur ou le binding des interfaces plus probablement. Je cherche encore et j'ai sollicité le forum d'Ubiquiti.
Bref, j'espère que ça me rendra plus à même de résoudre ma perte de paquets sur mes machines clientes mentionnées plus haut… Je connais un peu mieux IPSEC à présent. Et si j'ai le même problème depuis l'ER-X, je pourrais regarder la config de ma Dedibox avec plus d'attention. Dans le cas contraire, je trollerai Apple pour une implèmentation défectueuse sur iOS et OSX. :) Un peu plus sérieusement, j'avais besoin d'avoir un "client" avec un OS différent, pour voir et là, c'est quasiment la même version de StrongSwan à chaque bout.
Et après tout ça, si je ne me suis pas suicidé de désespoir, je ferais un beau tuto.
-
Pourquoi tu ne fais pas juste un tunnel gre avec de l'IPv6 dedans ? déjà que l'ER-X ne tient pas le giga, t'as pas peur de le mettre à genoux ?
-
Pourquoi tu ne fais pas juste un tunnel gre avec de l'IPv6 dedans ? déjà que l'ER-X ne tient pas le giga, t'as pas peur de le mettre à genoux ?
C'est justement pour éviter de charger mes headers que je veux éviter une encapsulation supplèmentaire. Car ce que tu proposes me ferait un joli IPv6 over GRE over IPSEC over IPv4. En revanche, je t'accorde volontiers qu'à partir du moment où j'ai une interface sur l'ER-X, ça simplifierai les choses pour peaufiner des routes, re-diriger des protocoles vers ce tunnel, etc…
Bon, j'ai effleuré la question de GRE, je l'avoue, à cause de l'inflation coté headers et parce que je voudrais éviter de poser une interface sur GRE sur la Dedibox. Plus ça reste simple sur une machine en remote, plus ça me plait. (et les docs de Shorewall ne sont pas très étendues sur la question)
Mais si c'est la solution pour forcer un binding d'IPSEC sur un tun0 de mon ER-X et qu'il arrête de me monopoliser mon interface LAN en IPv6, je prendrai la solution évidemment.
Un commentaire sur les perfs de l'ER-X: perso, ça me va largement. J'entends bien qu'il va avoir du mal à faire du Gigabit tout rond (bah, déjà vu du +900 Mbps sur un curl depuis mon Mac) mais ça me gênera que lors des concours "qui-a-la-plus-grosse". Concours auxquels je parsicipe bien volontiers. ;)
-
Petit followup…
La bonne nouvelle: j'ai un tunnel IPv6 over IPSEC over IPv4 entre mon ER-X et ma Dedibox qui devient utilisable par mes clients LAN. Un iperf3 -c ping6.online.net me donne 235 Mbps depuis mon Mac.
Obligé quand même de m'éloigner de la config CLI de l'ER-X et de taper dans les .conf directement. C'est loin d'être idéal donc et sur certains détails, c'est pas très propre. Mais j'ai un prefix /64 servi chez moi et à 235 Mbps. Petite victoire.
En revanche, les retransmissions de paquets TCP sont toujours là. Donc je vais devoir regarder de près ma Dedibox.
-
Petit followup…
La bonne nouvelle: j'ai un tunnel IPv6 over IPSEC over IPv4 entre mon ER-X et ma Dedibox qui devient utilisable par mes clients LAN. Un iperf3 -c ping6.online.net me donne 235 Mbps depuis mon Mac.
Obligé quand même de m'éloigner de la config CLI de l'ER-X et de taper dans les .conf directement. C'est loin d'être idéal donc et sur certains détails, c'est pas très propre. Mais j'ai un prefix /64 servi chez moi et à 235 Mbps. Petite victoire.
En revanche, les retransmissions de paquets TCP sont toujours là. Donc je vais devoir regarder de près ma Dedibox.
Juste pour continuer à mettre à jour ce sujet...
Si iperf passait très correctement en IPv6 via le tunnel IPSEC (ERX<>Dedibox), il m'avait pas été possible de résoudre mon problème de TCP Retransmissions. Au point que j'ai abandonné la "curieuse" idée d'avoir un prefix IPv6 @ home...
L'explication finale quant à mes difficultés est donnée dans le changelog de EdgeOS 1.9.1:
https://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX-EdgeRouter-software-release-v1-9-1/ba-p/1766160 (https://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX-EdgeRouter-software-release-v1-9-1/ba-p/1766160)
Known issues
[IPSec] IPSec ofload on ER-X/ER-X-SFP/EP-R6 platforms is causing packet corruption of L2TP and IPV6 site-to-site VPN traffic. ... If you are using either L2TP or IPv6 site-to-site VPN then you should disable IPSEc offload:
Aujourd'hui, je me contente d'un IPSEC en IPv4 seulement, avec une config des plus basiques. Il me sert de tunnel depuis mon routeur (toujours l'ERX) vers mon propre Résolveur récursif posé sur une Dedibox et de VPN pour mes appareils mobiles.
Si/quand le bug affectant l'IPv6 en IPSEC offload aura disparu, on en reparlera. :)
-
Sinon tu peux le faire passer par du GRE, c'est pas chiffré mais ça marche nickel.
-
Sinon tu peux le faire passer par du GRE, c'est pas chiffré mais ça marche nickel.
Salut Hugues. :)
En effet... Mais je veux chiffrer, par principe. Il m'a déjà été difficile de résister à la tentation de router tout mon traffic domestique via ce tunnel. ;)
Et je pourrais bien entendu faire un IPv6 over GRE/VTI over IPSEC over IPv4. Et sans m'exposer dans ce cas au bug, je pense.
Mais... j'ai toujours la même réticence que cet été, à savoir que je n'apprécie guère encapsuler à outrance. Je pinaille surment mais du IPv6 site-to-site over IPSEC me parait "élégant" et c'est ce que je veux faire. :)
Maintenant que le bug est connu, je vais m'armer de patience... (ou changer de solution quant au routeur local si ça n'avance pas)