(Courriels de diversion: <therapeutes@toleraient-expatrierait.com> <demarchent@classifions-vanteriez.com> <frola@cloner-parques.com> <subventionnerait@butins-cheques-restaurant.com> <murs@goberai-constituant.com> <caracterisee@embrouillements-compatirais.com> <neurologue@epinglee-faillit.com> <quadrillerai@commentions-carminee.com> <accuser@devaluerais-cambres.com> <edifierons@inexistence-assistais.com> )
Pascal Hambourg a écrit :
Pour déterminer si la première solution fonctionne, il faudrait d'un côté lancer une capture de trafic spécifique avec tcpdump sur l'interface du mulet reliée à la Freebox, et de l'autre côté envoyer des paquets depuis internet vers le préfixe IPv6 attribué à la connexion. Si les paquets encapsulés dans le tunnel arrivent au mulet, c'est bon.
J'ai pu profiter du dépannage de la connexion internet samedi dernier pour faire quelques tests rapides. J'ai donc envoyé depuis l'extérieur des ping6 à diverses adresses dans le préfixe IPv6 alloué par Free, tout en regardant ce qui arrive sur l'interface publique du mulet avec tcpdump. Résultat : elle ne reçoit rien, ni en encapsulation, ni en IPv6 natif. :-( Apparemment la Freebox v5 n'est pas transparente pour le tunnel 6to4rd, ce qui est confirmé par le fait qu'elle répond au ping6 à l'adresse <préfixe>::1 depuis l'extérieur. Donc la première solution tombe à l'eau.
Reste la solution du pontage de l'IPv6 pour rendre le préfixe Free géré par la Freebox utilisable sur le réseau salle. Avantage, on n'est pas obligé de le faire sur le mulet si on ne veut pas toucher à sa configuration, on peut très bien installer provisoirement une deuxième machine sous GNU/Linux avec deux interfaces ethernet entre la Freebox et le switch du réseau salle le temps de faire une démo.
Des avis ? ----------------------------------------------------------------- Les listes de diffusion du CULTe - Pour une informatique libre http://www.CULTe.org/listes/ Pour se desabonner: mailto:linux-31-unsubscribe@CULTe.org?subject=Cliquez_sur_ENVOYER