Auteur Sujet: Test du MAP-T et MAP-E en LAB  (Lu 2349 fois)

0 Membres et 1 Invité sur ce sujet

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 379
Test du MAP-T et MAP-E en LAB
« le: 24 janvier 2024 à 21:35:10 »
Bonjour,

J'avais dit dans le topic FAI: Les solutions pour partager l'IPv4 entre plusieurs clients que je testerais bien le MAP-T. C'est chose faite, et je touche presque au but après il faut le dire des heures de fumage de cerveau, à essayer de trouver la bonne syntaxe jusqu'à ce que je retrouve la nouvelle adresse du très pratique générateur de config DHCPv6 de cisco (écrit par un français en plus, merci Arthur !) et pouf tout marche instantanément... mais il reste un soucis.

Le setup :
-Le BR : debian avec ISC-DHCP, Jool et radvd
-Le CE : Un openWRT

La conf :
-IPv4 prefix :192.168.46.0/30
-Ipv6 prefix (BMR) : 2001:db8:9400::/60
-CE prefix : 2001:db8:9400:: → 2001:db8:9400:c:: /62
-BR prefix (DMR) : 4464:ff9b:ce::/64 (je me suis inspiré du well know prefix du DNS64, c'est d'ailleurs ce que l'auteur de jool utilise pour sa démo, le vrai en /96, mais le générateur de cisco ne génère qu'avec des /64)

Pour la faire court tout fonctionne presque : les paquets v4 partent, sont translatés, reviennent, re-translation, mais je ne les vois jamais arriver. Je soupçonne le parefeu de l'opemwrt de les dropper, ce qui est étrange étant donné que la connexion est initiée depuis le LAN. idem depuis OWRT lui-même d'ailleurs. Le test est basique avec des ping, qui normalement ne sont pas bloqués, même en config par défaut. Si je connecte l'OWRT normalement à mon LAN, aucun soucis, tout fonctionne.

Vu que je provisionne par DHCP, une interface MAP virtuelle est créée, je ne sais pas si ça change quelque chose. Car un ip a, retourne une unique link local sur celle-ci et pas d'ipv4 alors que sur une conf manuelle, comme celle de Free par ex (mais c'est du MAP-E) on a bien l'ipv4 renseignée.

Le message du kernel lors de la création :
nat46: configure device (map-wan6_4) with 'local.style MAP local.v4 192.168.46.0/30 local.v6 2001:db8:9400::/60 local.ea-len 2 local.psid-offset 1 remote.v4 0.0.0.0/0 remote.v6 4464:ff9b:ce::/64 remote.style RFC6052 remote.ea-len 0 remote.psid-offset 0'
Pour la config, je fais d'abord simple avec une adresse complète car quand j'ai voulu tester le partage, ça n'a pas fonctionné et les paquets ne passaient plus le BR en retour. J'imagine que je me suis planté sur la règle de jool ou les paramètres DHCP, car je n'ai pas tout saisi ces histoires de PSID/EA-bits (je suis très nul en maths, faut pas trop m'en demander  ;D)

Les commandes pour jool :
jool_mapt instance add "BR" --netfilter --dmr 4464:ff9b:ce::/64
jool_mapt -i "BR" fmrt add 2001:db8:9400::/60 192.168.46.0/30 2 0
jool_mapt -i "BR" global update map-t-type BR

Je n'ai pas compris à quoi correspond le 0 après le 2, est-ce la valeur a dont l'auteur parle ici ? : https://www.jool.mx/en/map-t.html#the-a-k-and-m-configuration-variables Je me demande si c'est pas ça qui résoudrait l'énigme du partage de ports (mais on va tenter de résoudre le soucis avec un adresse complète d'abord).

Si quelqu'un a une idée sur ce qui cloche...

Merci d'avance  :)
« Modifié: 31 janvier 2024 à 04:17:21 par renaud07 »

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 092
  • Paris (75)
Test du MAP-T en LAB : J'y suis... presque
« Réponse #1 le: 24 janvier 2024 à 23:44:11 »
d'apres le code source c'est le "PSID Offset" dans la RFC. (donc c'est bien la valeur "a").

/* For MAP-T */
struct mapping_rule {
struct ipv6_prefix prefix6;
struct ipv4_prefix prefix4;
__u8 o; /* The EA-bits length, in bits. */

/*
* Length of the Port-Restricted Port Field's "i" slice. (Also known as
* the "A" slice.)
* The RFCs have an unfortunate long name for "a": "PSID offset."
* In my opinion, this is a poor choice because it only makes sense if
* you're looking at the Port-Restricted Port Field diagram, and is very
* confusing if you're looking at the MAP IPv6 Address Format diagram.
* (`a` does not have anything to do with `n + p`.)
*
* Remember that k = q = o - p, and m = 16 - a - k.
* So storing those fields would be redundant.
*
* Yes, I know the RFCs imply that `a` doesn't belong to mapping rules.
* But let's be honest: Those RFCs are massive, massive trainwrecks.
* In practice, there's no reason to force all mapping rules to share
* the same `a`.
*
* You see, the RFCs have a massive problem in that the notion of a
* "MAP domain" is not consistent through them. I've decided to go with
* the version that makes sense to me, which is "each MAP domain has a
* distinct BMR." According to that definition, it doesn't make sense to
* force every connected MAP domain to have the same Port-Restricted
* Port Field.
*/
__u8 a;
};

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 379
Test du MAP-T en LAB : J'y suis... presque
« Réponse #2 le: 25 janvier 2024 à 02:15:03 »
Merci, je commence à comprendre. Le pire c'est qu'il y a les détails sur le générateur lorsqu'on clique sur les règles avancées. Ça modifie le nombre de ports réservés et de ranges en fait.

J'ai donc réessayé avec 192.168.46.1/32, et un offset à 0 ce qui nous fait 16384 ports pour 4 CE et la commande jool kivabien jool_mapt -i "BR" fmrt add 2001:db8:9400::/60 192.168.46.1/32 2 0

Et... it works !
root@debian:~# tcpdump -i enp0s8 tcp port 80
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s8, link-type EN10MB (Ethernet), snapshot length 262144 bytes
01:28:07.257591 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49182 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [S], seq 3790998064, win 64240, options [mss 1440,sackOK,TS val 2133491635 ecr 0,nop,wscale 7], length 0
01:28:07.508276 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49183 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [S], seq 3576058630, win 64240, options [mss 1440,sackOK,TS val 2133491886 ecr 0,nop,wscale 7], length 0
01:28:07.541135 IP6 4464:ff9b:ce:0:33:9e9a:a900:0.http > 2001:db8:9400:c:0:c0a8:2e01:3.49183: Flags [S.], seq 453561669, ack 3576058631, win 65160, options [mss 1460,sackOK,TS val 1309919073 ecr 2133491886,nop,wscale 10], length 0
01:28:07.541546 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49183 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [.], ack 1, win 502, options [nop,nop,TS val 2133491919 ecr 1309919073], length 0
01:28:07.541634 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49183 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [P.], seq 1:361, ack 1, win 502, options [nop,nop,TS val 2133491920 ecr 1309919073], length 360: HTTP: GET / HTTP/1.1
01:28:07.581605 IP6 4464:ff9b:ce:0:33:9e9a:a900:0.http > 2001:db8:9400:c:0:c0a8:2e01:3.49183: Flags [.], ack 361, win 64, options [nop,nop,TS val 1309919110 ecr 2133491920], length 0
01:28:07.586303 IP6 4464:ff9b:ce:0:33:9e9a:a900:0.http > 2001:db8:9400:c:0:c0a8:2e01:3.49183: Flags [.], seq 1:1429, ack 361, win 64, options [nop,nop,TS val 1309919112 ecr 2133491920], length 1428: HTTP: HTTP/1.1 200 OK
01:28:07.587232 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49183 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [.], ack 1429, win 501, options [nop,nop,TS val 2133491965 ecr 1309919112], length 0
01:28:07.590272 IP6 4464:ff9b:ce:0:33:9e9a:a900:0.http > 2001:db8:9400:c:0:c0a8:2e01:3.49183: Flags [P.], seq 1429:2857, ack 361, win 64, options [nop,nop,TS val 1309919112 ecr 2133491920], length 1428: HTTP
01:28:07.591359 IP6 4464:ff9b:ce:0:33:9e9a:a900:0.http > 2001:db8:9400:c:0:c0a8:2e01:3.49183: Flags [P.], seq 2857:3488, ack 361, win 64, options [nop,nop,TS val 1309919112 ecr 2133491920], length 631: HTTP
01:28:07.591603 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49183 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [.], ack 2857, win 501, options [nop,nop,TS val 2133491969 ecr 1309919112], length 0
01:28:07.592460 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49183 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [.], ack 3488, win 501, options [nop,nop,TS val 2133491970 ecr 1309919112], length 0
01:28:07.615214 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49184 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [S], seq 1856372793, win 64240, options [mss 1440,sackOK,TS val 2133491993 ecr 0,nop,wscale 7], length 0
01:28:07.646146 IP6 4464:ff9b:ce:0:33:9e9a:a900:0.http > 2001:db8:9400:c:0:c0a8:2e01:3.49184: Flags [S.], seq 3639631816, ack 1856372794, win 65160, options [mss 1460,sackOK,TS val 1309919179 ecr 2133491993,nop,wscale 10], length 0
01:28:07.646825 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49184 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [.], ack 1, win 502, options [nop,nop,TS val 2133492025 ecr 1309919179], length 0
01:28:07.646991 IP6 2001:db8:9400:c:0:c0a8:2e01:3.49184 > 4464:ff9b:ce:0:33:9e9a:a900:0.http: Flags [P.], seq 1:330, ack 1, win 502, options [nop,nop,TS val 2133492025 ecr 1309919179], length 329: HTTP: GET /connectivity.php HTTP/1.1
01:28:07.679802 IP6 4464:ff9b:ce:0:33:9e9a:a900:0.http > 2001:db8:9400:c:0:c0a8:2e01:3.49184: Flags [.], ack 330, win 64, options [nop,nop,TS val 1309919215 ecr 2133492025], length 0
01:28:07.683130 IP6 4464:ff9b:ce:0:33:9e9a:a900:0.http > 2001:db8:9400:c:0:c0a8:2e01:3.49184: Flags [P.], seq 1:577, ack 330, win 64, options [nop,nop,TS val 1309919216 ecr 2133492025], length 576: HTTP: HTTP/1.1 200 OK
root@debian:~# tcpdump -i enp0s3 tcp port 80
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
01:29:20.341833 IP 192.168.46.1.49185 > fr.archive.ubuntu.com.http: Flags [S], seq 4137385102, win 64240, options [mss 1440,sackOK,TS val 2133564723 ecr 0,nop,wscale 7], length 0
01:29:20.371742 IP fr.archive.ubuntu.com.http > 192.168.46.1.49185: Flags [S.], seq 1165256997, ack 4137385103, win 65160, options [mss 1460,sackOK,TS val 1309991908 ecr 2133564723,nop,wscale 10], length 0
01:29:20.372454 IP 192.168.46.1.49185 > fr.archive.ubuntu.com.http: Flags [.], ack 1, win 502, options [nop,nop,TS val 2133564754 ecr 1309991908], length 0
01:29:20.372516 IP 192.168.46.1.49185 > fr.archive.ubuntu.com.http: Flags [P.], seq 1:361, ack 1, win 502, options [nop,nop,TS val 2133564754 ecr 1309991908], length 360: HTTP: GET / HTTP/1.1
01:29:20.408268 IP fr.archive.ubuntu.com.http > 192.168.46.1.49185: Flags [.], ack 361, win 64, options [nop,nop,TS val 1309991942 ecr 2133564754], length 0
01:29:20.408762 IP fr.archive.ubuntu.com.http > 192.168.46.1.49185: Flags [.], seq 1:1429, ack 361, win 64, options [nop,nop,TS val 1309991944 ecr 2133564754], length 1428: HTTP: HTTP/1.1 200 OK
01:29:20.410092 IP 192.168.46.1.49185 > fr.archive.ubuntu.com.http: Flags [.], ack 1429, win 501, options [nop,nop,TS val 2133564791 ecr 1309991944], length 0
01:29:20.411907 IP fr.archive.ubuntu.com.http > 192.168.46.1.49185: Flags [P.], seq 1429:2857, ack 361, win 64, options [nop,nop,TS val 1309991944 ecr 2133564754], length 1428: HTTP
01:29:20.412240 IP 192.168.46.1.49185 > fr.archive.ubuntu.com.http: Flags [.], ack 2857, win 501, options [nop,nop,TS val 2133564794 ecr 1309991944], length 0
01:29:20.412518 IP fr.archive.ubuntu.com.http > 192.168.46.1.49185: Flags [P.], seq 2857:3488, ack 361, win 64, options [nop,nop,TS val 1309991944 ecr 2133564754], length 631: HTTP
01:29:20.412769 IP 192.168.46.1.49185 > fr.archive.ubuntu.com.http: Flags [.], ack 3488, win 501, options [nop,nop,TS val 2133564794 ecr 1309991944], length 0
01:29:20.432203 IP 192.168.46.1.49186 > fr.archive.ubuntu.com.http: Flags [S], seq 902139922, win 64240, options [mss 1440,sackOK,TS val 2133564813 ecr 0,nop,wscale 7], length 0
01:29:20.463630 IP fr.archive.ubuntu.com.http > 192.168.46.1.49186: Flags [S.], seq 1840750512, ack 902139923, win 65160, options [mss 1460,sackOK,TS val 1309991998 ecr 2133564813,nop,wscale 10], length 0
01:29:20.464133 IP 192.168.46.1.49186 > fr.archive.ubuntu.com.http: Flags [.], ack 1, win 502, options [nop,nop,TS val 2133564845 ecr 1309991998], length 0
01:29:20.464253 IP 192.168.46.1.49186 > fr.archive.ubuntu.com.http: Flags [P.], seq 1:330, ack 1, win 502, options [nop,nop,TS val 2133564845 ecr 1309991998], length 329: HTTP: GET /connectivity.php HTTP/1.1
01:29:20.500685 IP fr.archive.ubuntu.com.http > 192.168.46.1.49186: Flags [.], ack 330, win 64, options [nop,nop,TS val 1309992034 ecr 2133564845], length 0
01:29:20.503893 IP fr.archive.ubuntu.com.http > 192.168.46.1.49186: Flags [P.], seq 1:577, ack 330, win 64, options [nop,nop,TS val 1309992035 ecr 2133564845], length 576: HTTP: HTTP/1.1 200 OK

Maintenant, je n'ai plus qu'à tester avec plusieurs CPE et aussi retenter avec un /30 vu que ça n'avait pas l'air de vouloir fonctionner.

Et à priori pour l'interface virtuelle, la link local seule est normal, il n'y a pas eu apparition de l'ipv4.

ppn_sd

  • Abonné RED by SFR fibre FttH
  • *
  • Messages: 137
  • FLG (28190)
Test du MAP-T en LAB : J'y suis... presque
« Réponse #3 le: 25 janvier 2024 à 08:55:11 »
Pourrais-tu faire un retour sur une liste complète des commandes si cela diffère de la doc (https://www.jool.mx/en/run-mapt.html#configuration) ?
Les exemples de la documentation (sur d'autres configurations en tout cas) laissent parfois de côté des commandes.

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 379
Test du MAP-T en LAB : J'y suis... presque
« Réponse #4 le: 25 janvier 2024 à 15:34:07 »
Oui pas de soucis.

Pour le moment je n'ai utilisé que la partie BR. La conf full manuelle était inutile dans mon cas vu que j'utilise openwrt et pas une debian nue en guise de CE (cela dit c'est bien pour voir comment ça marche en backstage). Je voulais un minimum de réel pour communiquer avec mon LAN et internet.

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 379
Test du MAP-T en LAB : J'y suis... presque
« Réponse #5 le: 25 janvier 2024 à 21:04:41 »
Il semblerait que tout soit nickel : les 4 CPE marchent de concert, le forwarding/découpage des ports aussi  8) Et même avec des ipv6 invalides (range pour la doc), je peux quand même accéder au net en v4. Je vais tester avec mon préfixe orange histoire de valider la v6 aussi, mais à mon avis, c'est une simple formalité.

Je n'ai pas encore retesté avec une IPv4 complète.

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 379
Test du MAP-T en LAB : J'y suis... presque
« Réponse #6 le: 26 janvier 2024 à 17:59:53 »
Je suis en train de tester avec mon préfixe orange, mais étant en wifi sur mon PC portable, y'a des problèmes avec l'ipv6 et virtualbox. Du coup, j'avais monté un système de VXLAN pour bypasser les restrictions.

Sauf que maintenant, j'ai un soucis de routage : je voudrais router le trafic sortant du BR ou du moins le /60 sur le VXLAN et non sur la route par défaut. Et j'ai un doute sur si c'est possible ou pas (je n'arrive pas à trouver d'explication claire). J'imagine qu'il faut utiliser l’argument src avec ip route, mais je trouve pas d'exemple avec IPv6.

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 459
  • Lyon (69) / St-Bernard (01)
    • Twitter
Test du MAP-T en LAB : J'y suis... presque
« Réponse #7 le: 26 janvier 2024 à 18:12:21 »
src c'est autre chose, tu veux plutôt faire du PBR je pense

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 379
Test du MAP-T en LAB : J'y suis... presque
« Réponse #8 le: 26 janvier 2024 à 18:25:13 »
En effet, c'est ça, je retrouvais plus le nom.

Du coup, ça donnerait un truc comme (en omettant les autres commandes) :
ip -6 rule add from 2001:DB8:9400::/60 table vxlan
ip -6 route add default via fe80::linklocal-vxlan dev vxlan table vxlan

J'ai bon ? Inspiré de ce post : https://serverfault.com/questions/854094/linux-ipv6-policy-based-routing-fails

EDIT : À priori on est obligé de mettre une GUA dans ce cas.
« Modifié: 27 janvier 2024 à 02:36:56 par renaud07 »

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 379
Test du MAP-T en LAB : J'y suis... presque
« Réponse #9 le: 27 janvier 2024 à 03:31:44 »
On dirait bien que c'est un succès, dual stack fonctionnel, le tout par dessus du VXLAN  8) Après pas mal de bourdes dont j'ai le secret (comme remplacer les b par des d dans le préfixe et s'étonner que les paquets reviennent pas ou choisir la mauvaise interface pour la route  :P) L'ipv4 complète fonctionne aussi, il faut simplement mettre les EA bits lenght et le PSID offset à 0 côté jool.

Il ne manque plus que la cerise sur le gâteau : écrire un bout de code pour luci afin d'indiquer l'ipv4 publique et le/les ranges/nombre de ports sur l'interface MAP virtuelle (à la manière de Free). C'est compliqué ou pas ?

J'avais aussi oublié de poster à quoi doit ressembler l'option 95 si vous voulez tester (vaut mieux se servir du générateur, au risque d'envoyer une chaîne totalement pétée et chose appréciable, il fonctionne sur le navigateur rien n'est envoyé)
« Modifié: 27 janvier 2024 à 03:58:00 par renaud07 »

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 379
Test du MAP-T en LAB
« Réponse #10 le: 29 janvier 2024 à 04:24:29 »
J'essaie de faire fonctionner le MAP-E de façon simplifiée.

J'ai tenté le tunnel ipip6 statique BR → CE (vu que dans l'autre sens c'est déjà monté), sauf que le BR n'a pas de "vrai" tunnel avec chaque CE, si ? Et évidemment en l'état, rien ne passe. Je me doute que c'est un poil plus compliqué et qu'il faut décapsuler l'ipv4 avant de forwarder.

Une idée ?

Si seulement jool supportait le MAP-E... en plus ça à l'air, du moins en apparence, moins compliqué que MAP-T vu qu'il n'y a pas de translation.

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 379
Test du MAP-T en LAB
« Réponse #11 le: 30 janvier 2024 à 18:31:39 »
Quelqu'un a déjà utilisé VPP ? https://wiki.fd.io/view/VPP

Je vois que ça implémente MAP-E (la seule implémentation que j'ai trouvé pour du BR), mais impossible à faire fonctionner. Je n'arrive même pas à sortir sur le net. C'est une tannée à configurer...