Auteur Sujet: Supprimer une Mini-4K avec boitier ONTv2 en ZMD - Problème d'authentification ? (Lu 4529 fois)

Mikrotik · « **Réponse #36 le:** 13 février 2024 à 19:28:28 »

Citation de: jeremyp3 le 13 février 2024 à 19:23:53

Non. test fait à l'instant. et c'est logique, quand on y pense, vu qu'on peut pas choisir quel freebox pinguer, vu que ICMP n'a pas de notion de port

ICMP n'a pas de notion de port mais il a un numéro de requête dans chaque paquet. C'est ce qui permet d'établir la correspondance d'adresse dans un NAT. C'est peu connu, mais une règle src-nat s'occupe donc aussi de l'ICMP en cachète, sauf si on la confine à un protocole.

Évidemment lorsqu'on spécifie les ports de sortie, les règles src-nat sont restreintes à TCP et UDP. Si on ajoute une règle src-nat pour l'ICMP, ça ne marche pas. Parce que évidemment comme l'IP est partagée, il ne peut pas y avoir de retour d'ICMP par ce que pas de numéro de port pour ce protocole, sauf s'il y avait une règle spéciale chez l'opérateur pour remettre les paquets au bon client en fonction du numéro de requête. C'est possible mais cela ne semble pas avoir été développé chez Free.

Dans ce cas il suffirait d'ajouter une troisième règle src-nat pour le protocole ICMP. Je confirme que cela ne fonctionne pas même avec cet ajout.

Donc IP partagée restreinte à UDP et TCP.

renaud07 · « **Réponse #37 le:** 13 février 2024 à 20:11:11 »

Dommage pour ICMP, mais c'est bon à savoir que ça fonctionne pour MAP-E juste avec les règles de NAT !

Le module de Jool ne sert donc que pour la translation qui est plus complexe à faire.

Donc, même un ping initié depuis le routeur ne marche pas ? Car de l'extérieur c'est sûr que c'est impossible, vu qu'il n'y a pas de port à spécifier. Et avec la freebox ça marchait pas non plus ?

Sur mon lab de test, ICMP fonctionne correctement, c'est quand même bizarre que free n'ai rien implémenté, car il me semble que c'est une obligation de la norme.

jeremyp3 · « **Réponse #38 le:** 13 février 2024 à 20:14:32 »

Citation de: renaud07 le 13 février 2024 à 20:11:11

Dommage pour ICMP, mais c'est bon à savoir que ça fonctionne pour MAP-E juste avec les règles de NAT ! Le module de Jool ne sert donc que pour la translation qui est plus complexe à faire.

Donc, même un ping initié depuis le routeur ne marche pas ? Car de l'extérieur c'est sûr que c'est impossible, vu qu'il n'y a pas de port à spécifier. Et avec la freebox ça marchait pas non plus ?

pour préciser, avec la box et une ip partagé, un ping vers l'extérieur passe bien sûr

Mikrotik · « **Réponse #39 le:** 13 février 2024 à 20:37:12 »

Citation de: jeremyp3 le 13 février 2024 à 20:14:32

pour préciser, avec la box et une ip partagé, un ping vers l'extérieur passe bien sûr

Ok cela semble normal. Donc la box fait quelque chose de probablement spécifique pour l'ICMP. Il faudrait regarder quoi exactement en sortie d'une box avec IP partagée.

renaud07 · « **Réponse #40 le:** 13 février 2024 à 20:41:15 »

Tu me rassure^^ Je trouvais bizarre que Free n'ai pas implémenté tout un pan de la norme. Et je crois avoir trouvé ce qui ne va pas :

ICMP messages should be supported in MAP domains. Hence, the NAT44
in the MAP CE MUST implement the behavior for ICMP messages
conforming to the best current practice documented in [RFC5508].

If a MAP CE receives an ICMP message having the ICMP Identifier field
in the ICMP header, the NAT44 in the MAP CE MUST rewrite this field
to a specific value assigned from the port set. BRs and other CEs
must handle this field in a way similar to the handling of a port
number in the TCP/UDP header upon receiving the ICMP message with the
ICMP Identifier field.

https://datatracker.ietf.org/doc/html/rfc7597#section-8.2

Il faut donc réécrire l'identifiant comme TCP et UDP, ce qui est logique.

Mikrotik · « **Réponse #41 le:** 13 février 2024 à 21:36:17 »

Le problème c'est que dans le cas de Free c'est un NAT opérateur spécial avec mappage de ports et partage d'IP publique entre clients, je ne pense pas que cela corresponde à une norme et donc je pense qu'ils font quelque chose de spécial pour l'ICMP.

Je me suis demandé d'ailleurs comment reproduire ça sur une maquette en interne. Cela semble compliqué.

Citer

Je trouvais bizarre que Free n'ai pas implémenté tout un pan de la norme.

En réalité je ne pense pas que Free ait implémenté du code pour traiter le MAP-E. Ils utilisent probablement des routeurs haut de gamme de chez Cisco (ASR 9000 ?) ou Juniper qui sont capables de délivrer du MAP-E simplement à partir de quelques lignes de configuration.

Habituellement le NAT opérateur se fait avec des adresses IP privées non partagées, sur une classe d'adresse spécifique pour les clients, normalement dans la classe 100.64.0.0/10. Ensuite ces adresses sont nattées de façon classique avec si possible un ratio nombre d'IP publiques / nombre d'IP privées < 10. Pour ce CGNAT 444 classique, les règles de firewall sont standards, et l'ICMP passe sans problème.

renaud07 · « **Réponse #42 le:** 14 février 2024 à 02:01:34 »

Il n'y a rien de spécial dans l'implémentation de Free, c'est du MAP-E banal à priori.

Il suffit de suivre la norme et ça devrait fonctionner. Comme je te l'ai suggéré vas faire un tour sur mon topic, y'a toutes les infos utiles pour monter le lab

Je pars du principe qu'on est a l'aise avec linux et les commandes de base, ainsi qu'en réseau (je n'ai pas tout détaillé ça serait trop long). Attention y'a du map-t aussi.

J'ai testé le provisinning des paramètres de Free ça fonctionne parfaitement avec openwrt. Avec un préfixe au hasard, j'obtiens bien une ipv4 partagée.

Je détaillerais plus demain, pas le PC sous la main.

Mikrotik · « **Réponse #43 le:** 14 février 2024 à 10:45:55 »

Pour moi le but était d'avoir une configuration full stack sur Mikrotik, donc à ce niveau ça fonctionne complètement. L'adresse IP partagée est plus une curiosité, il manque donc juste le support du ping.

Sinon pour ceux que cela intéresse, le résultat du test CGN en IPv4 sur IP partagée, pour 2048 connections. Les points oranges ou rouges montrent les ports sources utilisés plus d'une fois. Le taux de réutilisation est de 5% dans ce cas. Au dessus le mappage en 2D, en dessous l'histogramme de répartition :

hsd · « **Réponse #44 le:** 03 mars 2024 à 09:15:21 »

Hello,

Ayé! Installation faite. J'ai pris l'offre révolution light. Elle est livrée avec l'ONU V1. Je suis à Paris.
Donc j'ai suivi les étapes, et tout fonctionne, y compris au redémarrage de l'ensemble.
Encore un petit truc, pour l'instant mon IP vu de l'extérieure est celle obtenue en DHCP donc hors du préfix affecté.

Je constate effectivement une baisse de performance. D'ailleurs avez-vous un test de débit en full ipv6 car j'utilise speedtest en cli qui ne fait que de l'IPv4.

En tous cas, merci de ce partage.

Mikrotik · « **Réponse #45 le:** 03 mars 2024 à 13:59:00 »

Citation de: hsd le 03 mars 2024 à 09:15:21

Hello,

Ayé! Installation faite. J'ai pris l'offre révolution light. Elle est livrée avec l'ONU V1. Je suis à Paris.
Donc j'ai suivi les étapes, et tout fonctionne, y compris au redémarrage de l'ensemble.
Encore un petit truc, pour l'instant mon IP vu de l'extérieure est celle obtenue en DHCP donc hors du préfix affecté.

Je constate effectivement une baisse de performance. D'ailleurs avez-vous un test de débit en full ipv6 car j'utilise speedtest en cli qui ne fait que de l'IPv4.

En tous cas, merci de ce partage.

Oui il n'y a pas besoin d'IPv6 globale sur le routeur, le routage se fait depuis son adresse IPv6 link local. Les IPv6 globales servent uniquement pour l'établissement des tunnels IPIPv6. Donc en IPv6 cela fonctionne sans IPv6 globale sur le WAN.

Il y a une petite perte de performance par rapport à la Freebox, mais assez faible, avec un RB5009.

Pour les tests de perf en IPv6, il y a ça par exemple, mais les résultats sont en dessous de la réalité pour moi :

https://ipv6-test.com/speedtest/

Ces tests dépendent beaucoup de la qualité des peering inter opérateurs, de l'heure de la journée, du nombre de sauts, ce n'est pas très fiable.

En IPV6 pur la vitesse évidemment est un peu meilleure, parce que le tunnel IPIPv6 n'est pas utilisé. Avec ce test j'obtiens moins qu'en IPv4, ce qui est impossible.

Actullement en IPv4 j'ai 870 mb/s down et 680 mb/s up sur degrouptest.

hsd · « **Réponse #46 le:** 06 mars 2024 à 23:15:02 »

Bonsoir,

L'affectation de l'ip par le DHCP de Free hors du préfix alloué me perturbe.
Quitte à paraitre maniaque, je souhaite que mon ip de navigation, celle de mon routeur soit la première du préfixe.
La requête DHCP étant nécessaire pour ouvrir les flux, j'ai ajouté ce script à dans le client DHCP

Code: [Sélectionner]

:local prefix [/ipv6 dhcp-client get [find interface=vlan836] value-name=prefix]
:set prefix ([:pick $prefix 0 ([:find $prefix ","]-3)])
:local gw [/ipv6 dhcp-client get [find interface=vlan836] value-name=address]
:set gw ([:pick $gw 0 ([:find $gw ","])])
/ipv6 address remove [find address="$prefix/128"]
delay 3s
/ipv6 address remove [find address="$gw/128"]
/ipv6 address add address="$prefix/128" interface="vlan836" advertise=no

Le script récupère le préfixe, l'IP, supprime l'IP et ajoute la première IP du préfixe.

Du coup, c'est de mon point de vue plus propre.

Autre point, j'ai choisi d'apporter la config suivante toujours au niveau du client DHCP IPV6

Puis d'ajouter l'adresse comme suit :

Du coup, la distrib des ipv6 publiques se fait automatiquement. Juste intéressant si vous publiez des ressources.

Mikrotik · « **Réponse #47 le:** 06 mars 2024 à 23:47:46 »

Il n'y a pas besoin d'adresses IPv6 globale sur le routeur, hormis celles nécessaires pour établir le ou les tunnels IPIPv6 pour obtenir de l'IPv4. Le routage vers le WAN se fait avec les adresses link-local en FE80.

Sauf éventuellement pour joindre le routeur depuis l'extérieur en IPv6. Auquel cas un pointeur DNS AAAA sur l'adresse du tunnel IPIPv6 ou sur cette adresse obtenue en DHCPv6 est encore plus simple que la première adresse du /60 qui peut alors être utilisée coté LAN.

Dans l'absolu, si IPv4 n'est pas utilisé, il n'y a besoin d'aucune IPv6 globale sur le routeur, sauf une par interface LAN pour le ND dynamique. Et encore, il est possible de supprimer les adresses IPv6 globales sur les interfaces LAN du routeur, auquel cas il faut juste ajouter dans le ND un préfixe statique par interface LAN en décochant l'option "On Link" (vérifié).

L'IPv6 source "de navigation" est celle du PC utilisé, sauf si vous configurez un NAT IPv6.

Pour éviter d'obtenir cette adresse hors du prefix /60 lors de la requête DHCP IPv6, il est tout simplement possible de demander le prefix, au lieu de demander une adresse au niveau du client DHCPv6. C'est suffisant pour activer la connectivité. Auquel cas cette adresse hors /60 n'existera tout simplement pas.