Auteur Sujet: IPv6 over IPv4 ipsec tunnel (Lu 7165 fois)

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.

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!

(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?

yrousse · « **Réponse #1 le:** 16 août 2016 à 20:10:24 »

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...

corrector · « **Réponse #2 le:** 16 août 2016 à 20:24:26 »

Est-ce que tu as un graphique?

yrousse · « **Réponse #3 le:** 16 août 2016 à 21:28:49 »

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.

vivien · « **Réponse #4 le:** 16 août 2016 à 22:41:54 »

Je pense que corrector parlait d'un graphe wireshark pour voir où sont perdus les paquets.

yrousse · « **Réponse #5 le:** 16 août 2016 à 23:24:29 »

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?

yrousse · « **Réponse #6 le:** 17 août 2016 à 00:17:54 »

J'ai fait ce graph avec des filtres qui m'ont paru "pertinents"...

yrousse · « **Réponse #7 le:** 17 août 2016 à 13:37:40 »

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.

vivien · « **Réponse #8 le:** 17 août 2016 à 14:31:07 »

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.

yrousse · « **Réponse #9 le:** 17 août 2016 à 16:01:37 »

Citation de: vivien le 17 août 2016 à 14:31:07

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.

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…).

TroniQ89 · « **Réponse #10 le:** 18 août 2016 à 21:33:06 »

Citation de: yrousse le 17 août 2016 à 00:17:54

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

Merci pour l'info :p

vivien · « **Réponse #11 le:** 20 août 2016 à 07:18:36 »

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)