Auteur Sujet: [FTTH] Bypasser la neufbox avec un routeur ubiquiti Edgemax (Lu 97690 fois)

Marin · « **Réponse #180 le:** 24 juillet 2014 à 02:14:13 »

yrousse, pourquoi est-ce qu'au lieu de tâtonner comme ça, tu ne fais pas une capture de ce que ton logiciel envoie, une autre de ce que la Neufbox envoie, et tu compares les deux ? Ça devrait résoudre directement le problème si c'est lié à l'authentification, puisque les identifiants sont transmis en clair.

yrousse · « **Réponse #181 le:** 24 juillet 2014 à 05:16:21 »

J'ai comparé les 2 situations (NB6/ERL) et je coince à un endroit bien précis avec en conclusion : "No response to PAP authenticate-requests".

Avec ma NB6v, un PAP (0xc023) Authenticate-Ack (2) est renvoyé par le LNS suite au Authenticate-Request (1) de la box. Et le reste (IPV6CP, ICMPv6, DHCPv6...) se déroule...

Dans ma config avec l'ERL, j'établie bien le tunnel l2tp et j'envoie mon PAP Authenticate-Request qui est formé des valeurs identiques à celles qu'envoie ma NB6v.

Code: [Sélectionner]

sent [PAP AuthReq id=0x1 user="dhcp/IP_Publique@MAC_NB6v" password=<hidden>]
Là ou ça coince, c'est la réponse du LNS : Il ne me renvoie pas de Ack (2) ou de Nak (3). Mais ça : [proto=0x201] 00 05 00 avec la valeur proto qui s'incrèmente de 1 à chaque réponse au PAP AuthReq du ERL (dont l'id=0x1 aussi s'incrèmente à chaque tentative). Et je ne sais pas ce que c'est (ni l'ERL, manifestement, qui la "discarde" immédiatement).

À noter que, juste après cette "obscure" réponse, le LNS tente de continuer la négociation puisqu'il m'envoit un [proto=0x1] 06 00 0e 01 0a ca 4c 75 ff fe 78 ed 00. Je retrouve ici la valeur ca4c:75ff:fe78:ed00 (Interface Identifier du LNS ?) dans la négo avec la NB6 lors du IPv6 Control Protocol qui fera quelques échanges avant la phase ICMPv6 et enfin DHCPv6. En revanche, la valeur du proto (0x1) m'apparait curieuse.

Enfin, mettre la MAC address de ma NB6v sur l'interface de mon ERL ne résout pas le problème. Et contrairement, à ce que montre le script (-1), mon wireshark confirme que c'est exactement la même MAC qui est utilisé dans l'AuthReq de la session PPP.

Voilà...

Marin · « **Réponse #182 le:** 24 juillet 2014 à 05:28:25 »

S'il ne te répond pas la même chose ça doit être que tu ne lui envoies pas la même chose. Tu dois bien pouvoir observer une différence, à un moment ou un autre, sur ce que ta machine envoie sur le réseau, en comparant paquet par paquet (avec Wireshark en mode graphique de préférence, plus pratique) ? Au pire, tu peux m'envoyer les .pcap par MP si tu souhaites ce que je te dise ce que j'en pense.

yrousse · « **Réponse #183 le:** 24 juillet 2014 à 05:47:45 »

Je vais bien devoir en passer par là... Grmpf!
Je fais ça demain. Enfin, aujourd'hui... Je viens de voir que le jour se pointe. Besoin de dormir un chouilla quand même.

yrousse · « **Réponse #184 le:** 25 juillet 2014 à 03:53:47 »

Tcpdump me confirme que mon LNS me renvoie bien son PAP, Auth-ACK (0x02) suite à mon Authenticate-Request. Et comme je l'écrivais précédemment, il continue avec un IP6CP, Conf-Request.
SAUF QUE, l'ERL ne va jamais répondre au paquet IP6CP et continue à envoyer son Authenticate-Request, car il ne reconnait pas le Auth-Ack du LNS.

Donc, je monte correctement le tunnel L2TP et la session PPP, jusqu'à l'envoi des identifiants inclus, est ok.
J'ai bien vérifié que les échanges Conf-Request/Conf-Ack soient identiques entre ceux de NB6v/LNS et ERL/LNS. La conf à ce niveau est ok.

À ce niveau, ça sent le "nasty bug" pour moi. Et vous?

yrousse · « **Réponse #185 le:** 25 juillet 2014 à 06:47:14 »

Et hop! J'ai mon interface ppp0!

En regardant à quel moment xl2tpd n'était plus capable de comprendre ce que le LNS lui envoyait, j'ai commencé à jouer avec les paramètres propres aux formats des messages. Un noaccomp rajouté et je vais jusqu'au bout... Yes!

Il me reste à automatiser l'établissement la session l2tp/ppp au démarrage, configurer wide-dhcpv6-client et le radvd pour mon LAN. Je ne prévois pas de difficulté majeure.

Je vous tiens au courant...

yrousse · « **Réponse #186 le:** 25 juillet 2014 à 20:46:32 »

Je suis un grand optimiste, apparemment (en référence à "Je ne prévois pas de difficulté majeure")...

En config à la mimine, la config DHCPv6 toute simple fonctionne :

Code: [Sélectionner]

interface ppp0 {
     request domain-name-servers;
     request domain-name;
     send ia-na 1;
     send ia-pd 1;
     send rapid-commit;
     script "/etc/wide-dhcpv6/dhcp6c-script";
};
#
id-assoc pd 1 {
     prefix ::/56 infinity;
     prefix-interface eth1 {
          sla-id 1;
          sla-len 8;

     };
};
#
id-assoc na 1 { };

Il récupère mon prefix IPv6 et me rêgle mon interface LAN (eth1) sans problème.
Derrière, le radvd fait son job et je ping6 depuis mes clients LAN.

Cependant, ma difficulté du jour (!) est de pouvoir être certain que la phase xl2tpd/ppp soit achevée avant que wide-dhcpv6-client ne se met au boulot.
Or j'avais tenté de mettre mon echo "c l2tp-IPv6" > /var/run/xl2tpd/l2tp-control dans /etc/rc.local (et cette phase fonctionne: j'ai bien mon ppp0 Up au démarrage) mais ça semble arrivé trop tard, le client DHCPv6 ne retentera pas de faire son job.

J'ai donc décidé de déplacer le montage de ppp0 beaucoup plus tôt et de m'assurer que eth0 (mon WAN IPv4) soit bien up avant... Donc j'ai viré certains critères pour eth0 dans la config CLI/ERL (et moi qui voulait éviter à tout prix de modifier directement trop de fichiers de conf, il y a quelques semaines...).
J'ai donc dans /etc/network/interfaces :

Code: [Sélectionner]

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
        hwaddress xx:xx:xx:xx:xx:xx
        vendor &quot;neufbox-bypassedby-monemail@gmail.com&quot;;

auto ppp0
iface ppp0 inet manual
        pre-up /etc/init.d/xl2tpd start; sleep 3
        pre-up echo "c l2tp-IPv6" > /var/run/xl2tpd/l2tp-control; sleep 3
        down echo "d l2tp-IPv6" > /var/run/xl2tpd/l2tp-control; sleep 3
        post-down /etc/init.d/xl2tpd stop

eth0 obtient bien son IP publique et... ppp0 ne monte pas!

Pourtant, si je fais des ifdown ppp0 et ifup ppp0, là, ça fonctionne comme déterminé dans /etc/network/interfaces et j'ai mon ppp0.

Qu'est-ce-que je rate ?

(et question à venir (parce que je n'ai pas encore trouvé comment faire...) : comment je référence ppp0 dans le CLI? Parce que pour set interface xxxx ppp0 firewall... Heu.... Je vois pas.)

kgersen · « **Réponse #187 le:** 25 juillet 2014 à 22:23:00 »

Citation de: yrousse le 25 juillet 2014 à 20:46:32

Cependant, ma difficulté du jour (!) est de pouvoir être certain que la phase xl2tpd/ppp soit achevée avant que wide-dhcpv6-client ne se met au boulot.

pour quelle raison as tu besoin de cette certitude ?

t'as un "send ia-na 1" et un assoc vide c'est pas bon : ca déclenche une stateful configuration de l'IP.
"rapid commit" aussi a enlever, il faut attendre le RA.

en general le client DHCPv6 est déclenché lors du Neighbor Discovery (par réception d'un message RA avec O et/ou M a 1) donc quand une IPv6 est attribuée au tunnel.

Sinon le delai de retry entre 2 solicit est de 120 secondes.

DHCPv6 et DHCPv4 sont tres differents et on utilise tres rarement DHCPv6 pour attribué des adresses IP alors qu'en V4 ca sert a ca avant tout.

Comme souvent en IPv6 il faut eviter de transposer et raisonner comme on a l'habitude de faire en v4, ca evite les problemes.

yrousse · « **Réponse #188 le:** 25 juillet 2014 à 23:48:09 »

Pour le ia-na, il me semble être le seul moyen d'avoir une adresse globale sur mon interface LAN (le role du id-assoc na 1 { }; d'après toutes les descriptions et exemples que j'ai pu consulté). Mais je veux bien avoir tort. Tu confirmes?

Rapid-commit : bien vu. La raison pour laquelle le DHCPv6 n'écoute pas le RA sur ppp0, j'imagine. Je l'enlève.
Donc je peux revenir sur mon cas de configure où je lance mon echo "c l2tp-IPv6" > /var/run/xl2tpd/l2tp-control dans /etc/rc.local et virer ce que j'avais mis dans /etc/network/interfaces. wide-dhcpv6-client, maintenant sans rapid-commit, se déclenchera un peu plus tard.

Ça simplifie. Tant mieux. J'essaie ça après avoir mis ma téléspectatrice au lit.

Je reviens sur une de mes questions précédentes : comment puis-je continuer à gérer le firewall via l'interface CLI pour l'interface ppp0? Si je peux éviter de devoir poser des rêgles iptables à la mano...

kgersen · « **Réponse #189 le:** 26 juillet 2014 à 02:19:31 »

Oui il ne faut pas de ia-na, en tout cas la NBox n'en met pas, elle ne met que le ia-pd.

En principe tu recois une IPv6 coté wan par un Neighboor Discovery classique:

la chronologie:

- l'interface monte (via IPV6CP tel que définit dans les options de la connexion l2tp) et cherche a se configurer toute seule une IP globale
- émission d'un RS (router solicitation) sur cette interface en utilisant son @ link-local
- réception d'un RA (router advertissemnt) de la part du routeur en face chez SFR
- si dans le RA y'a l'option M est a 1 ca veut qu'il faut configurer son IP via DHCP (mais en general c'est 0 et dans le cas present ca devrait aussi). si M a 0, il faut configurer son IP coté WAN automatiquement en utilisant le préfix fournit dans le RA.
- si dans le RA y'a l'option O est a 1: d'autres options sont dispo par DHCP (dans le cas present y'a que l'option Prefix Delegation qui sera fournit): c'est ca qui doit déclencher le client DHCP.

donc enleve bien le ia-na et le rapid-commit de ta config. ca 'devrait' marcher ...

yrousse · « **Réponse #190 le:** 26 juillet 2014 à 08:39:39 »

Je viens de tenter ta suggestion : Plus de ia-na et ni de rapid-commit et bien sur,

Code: [Sélectionner]

net.ipv6.conf.ppp0.accept_ra = 2
net.ipv6.conf.ppp0.autoconf = 1
net.ipv6.conf.all.forwarding = 1

Mais l'autoconf ne donnera pas d'IPv6 global et DHCPv6 ne va pas se déclencher.

Quand je fais un radvdump, je vois que Managed Flag et Other Config sont à off sur ppp0 et surtout, je n'ai pas d'annonce de prefix:

Code: [Sélectionner]

interface ppp0
{
	AdvSendAdvert on;
	# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
	AdvManagedFlag off;
	AdvOtherConfigFlag off;
	AdvReachableTime 0;
	AdvRetransTimer 0;
	AdvCurHopLimit 64;
	AdvDefaultLifetime 1800;
	AdvHomeAgentFlag off;
	AdvDefaultPreference high;
	AdvLinkMTU 1450;
}; # End of interface definition

En revanche, si je restart wide-dhcpv6-client, il vient me donner mon prefix et mon adresse global sur mon interface LAN.
J'ai l'impression que lorsque ce dernier se lance au boot, son problème est que ppp0 n'existe pas encore et il lache complètement l'affaire, au lieu de continuer à écouter.
Quoiqu'il en soit, il me semble pas inutile de m'assurer que ppp0 monte le plus tôt possible, quelque soit la façon dont je traite DHCPv6 ensuite...

Donc avant de me battre avec DHCPv6 (que j'arrive à faire fonctionner, même si ce n'est pas selon les rêgles IPv6 les plus clean...), que puis-je faire pour que /etc/network/interfaces fonctionne (voir mon post précédent (les paramètres ppp0 sont bien pris en compte (ifup & ifdown sont ok) mais l'interface ne monte pas au boot)) :

Code: [Sélectionner]

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
        hwaddress xx:xx:xx:xx:xx:xx
        vendor &quot;neufbox-bypassedby-monemail@gmail.com&quot;;

auto ppp0
iface ppp0 inet manual
        pre-up /etc/init.d/xl2tpd start; sleep 3
        pre-up echo "c l2tp-IPv6" > /var/run/xl2tpd/l2tp-control; sleep 3
        down echo "d l2tp-IPv6" > /var/run/xl2tpd/l2tp-control; sleep 3
        post-down /etc/init.d/xl2tpd stop

kgersen · « **Réponse #191 le:** 26 juillet 2014 à 17:35:12 »

c'est curieux pour l'autoconf ou alors une particularité propre a SFR ou IPv6 sur PPP. je vais enquêter la dessus.

t'as que /etc/network/interfaces pour enchainer les trucs? tu peux faire avec des scripts sinon.

L'interface ppp est mieux en manuel plutot qu'en auto, c'est pas vraiment une interface auto car elle dépend d'une autre interface et c'est une commande qui la monte (echo ... l2tp-control);

je mettrai plutot le lancer du script xl2tpd et de la connexion (echo...l2tp-control) quand le wan est up (en 'post-up' de l'interface wan donc si ton client dhcp v4 est bloquant).
le demon xl2tpd peut etre lancer auto aussi et juste mettre la connexion dans le post-up du wan (avec un check/wait que le demon tourne).

idealement pour etre propre, la connexion/déconnexion du ppp devrait se faire en post de la config DHCP du wan notamment s'il y a un renew avec changement d'addresse du wan . Mais comme l'ip est fixe c'est pas 'trop' grave.( ca se fait par des hooks dhcpcd).

Dans l'interface ppp0, je mettrais le lancer du client dhcpv6:

Code: [Sélectionner]

iface ppp0 inet manual
    post-up /etc/init.d/wide-dhcpv6-client start
    pre-down /etc/init.d/wide-dhcpv6-client stop

enfin y'a plein de facon faire suivant ce dont on dispose dans le systeme.