La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la Freebox par un routeur => Discussion démarrée par: Mikrotik le 20 janvier 2024 à 00:34:55
-
J'ai remplacé ma Mini-4K en ZMD, donc avec l'ONT v2, par un routeur Mikrotik RB5009. J'ai pris le modèle avec sorties POE, ce qui me permet de supprimer la Freebox, mais aussi un switch POE 8 ports qui se trouvait à coté de la Freebox. Économies d'énergie substantielles et silence de fonctionnement (plus de ventilateurs). Ce routeur chauffe peu, grâce à la fréquence de fonctionnement dynamique du CPU, entre 350 et 1700 MHz.
J'ai donc conservé l'ONT qui est relié au SFP+ du routeur par le câble DAC cuivre d'origine. Le port SFP+ monte sans problème, en autoconfiguration (1Gbps).
Configuration : adresse MAC de la Freebox sur l'interface SFP+ du routeur, Vlan 836, MTU 1700, DHCPv6, adresse IPv6 source forgée pour le Tunnel IPIPv6. Ipv4 full stack en /32.
J'ai également monté un Vlan 835 avec un client DHCPv4. J'obtiens bien une adresse en 10.x.x.x/24.
La connectivité IPv6 et IPv4 fonctionne parfaitement, à condition d'initialiser le boitier ONT sur la Freebox, puis de rebrancher le DAC à chaud sur le SFP du routeur Mikrotik. Si ensuite je débranche et rebranche la fibre, ou si je débranche puis rebranche l'alimentation de l'ONT, je ne reçois alors plus de trafic. C'est la rupture du lien coté fibre qui entraîne la fermeture du trafic Internet.
Pour corriger le problème, je dois alors remettre le câble DAC dans le SFP de la Freebox, attendre qu'elle fasse son authentification, puis rebrancher le DAC sur le routeur Mikrotik pour que l'accès Internet fonctionne à nouveau.
Il semble donc que FREE ne vérifie pas seulement l’adresse MAC de la Freebox pour l’authentification, sinon l'authentification fonctionnerait avec le Routeur Mikrotik.
Y'aurait il quelque chose en plus dans la requête DHCP, comme chez Orange, ou une authentification du genre 802.1x à lancer, pour activer la connexion ? Ou bien la Freebox serait nécessaire pour injecter une configuration dans le boitier ONTv2 ?
J'ai vu que je n'était pas le seul à avoir ce problème, mais il semble que d'autres ne l'ont pas... Donc je me pose des questions...
Quelqu'un aurait-il une analyse Wireshark du trafic entre l'ONT et la FreeBox pour essayer de comprendre ce que fait la Freebox pour déverrouiller l'ONT ou une règle de filtrage chez Free ?
-
Quelques pistes possibles pour obtenir le déverrouillage du trafic entrant :
- envoi d'une option dans la requête DHCPv6
- authentification 802.1x (je n'y crois pas trop)
- envoi d'une authentification chez Free, autrement que par 802.1x ou DHCP.
- envoi d'une configuration ou échange entre la FreeBox et l'ONT.
- envoi d'une configuration dans l'ONT depuis les serveurs Free peut être en passant par le port de sortie coté FreeBOX de l'ONT.
Si c'est cette dernière option qui est utilisée, elle nécessite probablement une IP spécifique sur le port SFP+ du routeur, pour que Free puisse dialoguer avec l'ONT par son port de sortie, et cette adresse est pourrait être différente de celle forgée sur le prefix /60 pour pouvoir établir le tunnel IPIPv6.
Il y a justement quelque chose qui interroge dans la configuration IPv6 de la FreeBox et qui pourrait se rattacher à l'hypothèse précédente : lors de la requête du client DHCPv6 sur le VLAN 836, on reçoit une adresse IPv6 en /64, commençant par 2a01:e00, qui se trouve en dehors du préfixe IPv6 / 60 reçu pour l'exploitation de IPv6. Il se pourrait que cette adresse soit utilisée pour rebondir vers le boitier ONT.
Après vérification par un ping depuis l'extérieur, cette adresse est routée par Free, elle est accessible depuis l'Internet publique. Si elle n'est pas utilisée pour une quelconque configuration, à quoi sert-elle (si on la désactive, tout semble fonctionner normalement) ?
Quelques notes :
- l'obtention de l'adresse IPv4 en 10.x.x.x/24 sur le VLAN 835 ne semble à priori ne pas avoir d'influence sur le déverrouillage du trafic Internet.
- la requête DHCPv6 client ne semble pas non plus avoir une influence, on peut s'en passer en configurant manuellement la route par défaut IPv6 et les préfixes des sous réseaux LAN, sans que cela ne change quoique ce soit à la connectivité. L'adresse de passerelle IPv6 se trouve dans la route par défaut obtenue dynamiquement par DHCPv6. Une fois que l'on a cette adresse (une adresse link-local en FE80), on peut se passer du client DHCPv6.
- lorsque que l'ONT n'est pas initialisé, le tunnel IPIPv6 ne peut pas se monter et l'accès Internet même en IPv6 n'est pas possible. Par contre, une requête DHCPv6 fonctionne, sans être réellement nécessaire par la suite si configuration IPv6 manuelle. Cela tendrait à montrer* que le mécanisme de requête DHCPv6 est là pour donner l'accès à Internet par une autorisation accordée dans une règle de firewall chez Free.
*Le DHCPv6 n'est pas indispensable pour la distribution du préfixe en /60 et de la route par défaut IPv6 : l'autoconfiguration stateless par RA (router advertisement) est suffisante. Etant donné que les RA sont aussi disponibles dans le VLAN 836, on peut se demander pourquoi DHCPv6 a été mis en place si ce n'est pour effectuer une authentification par une option DHCP spécifique lors de la requête cliente.
-
Bonjour,
- la requête DHCPv6 client ne semble pas non plus avoir une influence, on peut s'en passer en configurant manuellement la route par défaut IPv6 et les préfixes des sous réseaux LAN, sans que cela ne change quoique ce soit à la connectivité. L'adresse de passerelle IPv6 se trouve dans la route par défaut obtenue dynamiquement par DHCPv6. Une fois que l'on a cette adresse (une adresse link-local en FE80), on peut se passer du client DHCPv6.
selon ce que j'avais observer, la requêtes dhcpv6 est obligatoire, même si le bail fourni était d'environ une semaine, si aucune nouvelle requête dhcpv6 n'est effectuée, tu perdras la connectivité, et les RA
-
Bonjour,
selon ce que j'avais observer, la requêtes dhcpv6 est obligatoire, même si le bail fourni était d'environ une semaine, si aucune nouvelle requête dhcpv6 n'est effectuée, tu perdras la connectivité, et les RA
Je n'ai pas encore une semaine de recul. Ce qui est certain c'est que ce n'est pas la requête IPv6 dans mon cas qui ouvre le trafic Internet, en tout cas pas celle que j’envoie depuis mon routeur qui remplace la Freebox.
Pour ouvrir le trafic Internet, je dois connecter le DAC qui sort du module ONTv2 sur la Freebox, et attendre l'authentification par la Freebox. Puis rebrancher sur mon routeur.
-
Pour ma part, tant que mon routeur n'a pas récupéré une IPv6 via DHCPv6, j'ai rien qui sort de l'ONT.
C'est une "nouveauté" car il y a quelques années t'avais tout le traffic (IPv6 & IPv4) dès que l'ONT passait au vert.
-
Pour ma part, tant que mon routeur n'a pas récupéré une IPv6 via DHCPv6, j'ai rien qui sort de l'ONT.
C'est une "nouveauté" car il y a quelques années t'avais tout le traffic (IPv6 & IPv4) dès que l'ONT passait au vert.
Que se passe t'il si vous coupez momentanément l'alimentation de l'ONT, est ce que le trafic repart après la requête DHCPv6 ?
Pour moi ça ne repart pas. Je dois remettre la sortie de l'ONT sur la Freebox pour avoir une authentification par la Freebox, puis remettre sur mon routeur. Peut être une nouveauté qui n'est pas encore implémentée partout ?
-
Il n’y a pas d’authentification autre que l’adresse mac chez Free. S’il y a besoin de connecter à la box, c’est que le problème est ailleurs…. Et à priori, comme chez de nombreux opérateurs, c’est la requête DHCP qui déclenche l’accès.
-
Il n’y a pas d’authentification autre que l’adresse mac chez Free. S’il y a besoin de connecter à la box, c’est que le problème est ailleurs…. Et à priori, comme chez de nombreux opérateurs, c’est la requête DHCP qui déclenche l’accès.
Pourquoi mon ONTv2 a besoin de la box pour s'initialiser alors ? Vous avez essayer de brancher la sortie de l'ONTv2 sur un routeur, la requête DHCPv6 est suffisante ?
Pour moi ça ne fonctionne pas. L'ONTv2 doit faire un petit tour sur le port de la box avant de se mettre à fonctionner. Pourtant sur mon routeur tout semble se passer normalement, y compris l'autonégociation avec le port de sortie de l'ONT.
Mon authentification DHCPv6 passe pourtant sans problème, je demande le prefix et une adresse, et je reçois bien les deux. Et j'ai bien l'adresse MAC de ma box sur le port SFP de mon routeur. Donc ça devrait marcher direct.
Je suis preneur si vous avez une idée.
-
Que se passe t'il si vous coupez momentanément l'alimentation de l'ONT, est ce que le trafic repart après la requête DHCPv6 ?
Pour moi ça ne repart pas. Je dois remettre la sortie de l'ONT sur la Freebox pour avoir une authentification par la Freebox, puis remettre sur mon routeur. Peut être une nouveauté qui n'est pas encore implémentée partout ?
S'il y a une coupure de l'ONT, il se passe que je dois rebooter openWRT (une VM) car il a du mal a ré-initialiser l'interface map. Mais ça c'est un bug propre à openWRT. Une fois redémarré j'ai tout qui se remonte. La freebox dort dans sa boite depuis le début.
-
Je suis preneur si vous avez une idée.
Mon idée c'est que le tunnel ipip6 force l'interface ipv6 a être toujours valide (genre il ne détecte pas la coupure de l'interface en ipv6) et du coup quand on rebranche le routeur ne fait pas le dhcpv6 initiale. C'est aussi je pense ce qui arrive avec le module map d'openWRT quand je réinitialise l'interface wan6 (DEVICE_CLAIM_ERROR). A mon avis une commande "ip device remove" n'a pas bien été scripté.
-
Mon idée c'est que le tunnel ipip6 force l'interface ipv6 a être toujours valide (genre il ne détecte pas la coupure de l'interface en ipv6) et du coup quand on rebranche le routeur ne fait pas le dhcpv6 initiale. C'est aussi je pense ce qui arrive avec le module map d'openWRT quand je réinitialise l'interface wan6 (DEVICE_CLAIM_ERROR). A mon avis une commande "ip device remove" n'a pas bien été scripté.
Non je ne pense pas car si je coupe le client DHCPv6 et que je le relance, tout se passe normalement, la requête se fait bien, mais toujours pas de connectivité malgré que le routeur ait bien reçu son prefix, son adresse IPv6 et sa route par défaut en DHCP.
Apparemment il y a vraiment quelque chose qui se passe en plus dans le boitier ONTv2 lorsque je le rebranche sur la FreeBox pour l'authentification initiale.
Au niveau tu routeur Mikrotik je ne vois rien d'anormal, j'ai tout essayé et vérifié, tout semble ok. J'ai même essayé de mettre l'interface SFP en disable puis enable, supprimer la négociation auto et forcer le débit en manuel, rien n'y fait. C'est toujours le fait de rebrancher l'ONT sur la Freebox qui permet le redémarrage du trafic Internet.
-
Ce ne serait pas un problème spécifique avec le tunnel IPv4 ?
Sur openWRT si je laisse le script map.sh faire, il ne récupère pas la bonne IPv6 source et le tunnel ne se monte pas correctement.
Autre possibilité mais que j'ai vu sur un routeur particulier en configuration VDSL IPv4 + 6rd: le routeur chez Free (x.254) ne répond pas aux requêtes ARP, et du coup la ligne avait beau être OK, pas de réseau. Sur un autre routeur c'était tout OK. Ici il n'y aurait pas un problème équivalent, du genre le routeur fait sa requête DHCPv6, et quand il reçoit une réponse il essaye via l'équivalent d'ARP en IPv6 (NDP je crois - me souviens plus du nom) de récupérer la MAC, mais va savoir pourquoi le routeur ne le fait qu'une fois, et pas à chaque relance de DHCPv6 ?
-
Non, J'ai désactivé le tunnel pour faire des tests. Le problème à la base est sur la connectivité IPv6.
En effet il y a bien deux adresses IPv6 globales utilisées par la Freebox, une pour le tunnel IPIPv6, qu'il faut mettre manuellement, et une autre en /64, bizarrement en dehors du prefix IPV6 /60 attribué, qui est récupérée par la requête DHCPv6.
Cette adresse en /64 est en dehors du prefix /60, mais elle est bien routée par Free, j'ai pu la pinger depuis l'extérieur. Elle sert peut être dans la Freebox pour l'accès de FreeBox OS depuis l'extérieur, si l'option est activée. Si on la supprime dans le routeur, cela ne change rien.
En IPv6 il n'y a pas d'ARP effectivement, il y a des adresses IPv6 locales, commençant par FE80, qui sont déterminées lors du boot du routeur pour chaque interface, forgées sur les adresses MAC. Ces adresses en FE80 sont non routables, elles servent seulement à établir les liaisons point à point. Celle de l'interface WAN du routeur chez Free est utilisée par exemple dans la route par défaut du routeur client.
Je ne pense pas qu'il y ait un problème de ND. Je pense qu'il y a plutôt une règle de firewall qui s'ouvre chez Mikrotik, uniquement lorsque la FreeBox fait la requête IPV6, elle doit y ajouter quelque chose en plus. Ce qui est étrange c'est que cela ne semble pas être le cas pour tout le monde.
J'obtiens un bail de 30 jours en réponse à la requête IPv6 sur le VLAN 836. Cela semble différent du bail de 1 semaine obtenu par d'autres.
-
Le fait que J'obtienne un bail de 30 jours en réponse à la requête IPv6 sur le VLAN 836 semble montrer que je suis sur une plateforme différente, comme certains utilisateurs, car d'autres semblent recevoir un bail d'une semaine.
Etant donné que ma requête DHCPv6 ne suffit pas à déverrouiller l'accès Internet (j'ai vu un autre fil dans lequel un utilisateur a le même problème), quelques hypothèses :
- Il y a une règle de firewall chez Free qui s'active après une authentification (autre que l'adresse MAC) par la FreeBox.
- Il y a une règle de firewall qui s'activerait dans le boitier ONTv2, toujours après authentification par la FreeBox, je n'y crois pas trop mais c'est possible, si le boitier ONT gère jusqu'au niveau 3.
Pour mémoire pour obtenir l'accès Internet avec mon routeur, en remplacement de la FreeBox, je dois brancher la Freebox sur l'ONTv2, attendre la fin de l'authentification, puis la débrancher et brancher mon routeur à la place.
Une fois que mon routeur est branché, je n'ai pas besoin de faire une requête DHCPv6 sur le VLAN 836, ni de l'autoconfiguration IPv6, ni d'une requête DHCPv4 sur le VLAN 835. J'ai l'accès IPv6 directement (avec la configuration IP en dur bien sûr, adresses IPv6 et route par défaut), et je peux monter le tunnel IPIPv6 sans soucis.
Le fait que la requête DHCPv6 puisse de faire même après coupure de l'alimentation de l'ONTv2, alors que le retour du trafic Internet nécessite une réauthentification par la FreeBox, semble montrer qu'il y a bien une règle de firewall chez Free pour accéder au trafic Internet.
Je pense que cela va nécessiter une analyse pour voir ce qu'il se passe entre le boitier ONTv2 et la Freebox lors de l'authentification.
-
Bon, mon problème semble avoir disparu. Je ne suis pas certain de la raison exacte. Donc je peux maintenant couper l'alimentation du boitier ONTv2, et le lien remonte sans problème. Je peux aussi redémarrer le routeur.
Je pense néanmoins que le problème provenait simplement de l'autonégociation avec le boitier ONTv2, après redémarrage de ce dernier. C'est peut être une mise à jour de RouterOS qui a résolu le problème (actuellement en 7.14.beta9). Ou peut être le boitier ONTv2 qui se serait mis à jour depuis les serveurs Free.
J'ai ajouté une option 6 dans la requête DHCPv6, pour demander la configuration MAP-E, pour faire comme la Freebox, mais cela n'a aucune influence au final. Cela marche sans.
Donc configuration pour le moment validée avec un RB5009.
La requête DHCPv6 semble obligatoire pour ouvrir le trafic IPv6 vers Internet. Par contre la mise en place du VLAN 835 n'est pas obligatoire, et ICMPv6 (ND, Router sollicitation, Router Advertisement...) n'est pas nécessaire, coté WAN.
Enfin, l'adresse source pour le tunnel MAP-E est obligatoire, mais on peut la mettre en /128 sur le VLAN 836 ou sur l'interface de bouclage local du routeur pour éviter de perdre un /64 complet.
Au passage, j'ai remarqué quelque chose d'étrange : Free présente un border router MAP-E avec une adresse qui ne fonctionne pas.
Dans la réponse DHCPv6 de Free, suite à la sollicitation DHCPv6 de la FreeBox, il est indiqué 2a01:e00:29:200a::fff9 comme adresse de border router MAP-E ; elle ne fonctionne pas.
La bonne adresse, pour moi, est 2a01:e00:29:200a::fffd
Je suppose que la Freebox n'utilise donc pas DHCPv6 pour établir le tunnel MAP-E.
-
T'as bien une IP fullstack ? Dans ce cas c'est normal. Le DHCPv6 ne délivre que les paramètres pour l'IP partagée (c'est comme ça depuis le début à priori).
Le paramétrage pour le fullstack doit se faire manuellement par le VLAN 835 comme plusieurs fois évoqué, d'où l'adresse de BR différente. Il ne font à priori pas de reconfiguration de leur DHCP pour envoyer les bonnes options à chaque client qui en fait la demande. J'imagine que c'est lourd à gérer et que c'est plus simple de le faire avec un bête fichier de conf.
-
T'as bien une IP fullstack ? Dans ce cas c'est normal. Le DHCPv6 ne délivre que les paramètres pour l'IP partagée (c'est comme ça depuis le début à priori).
Le paramétrage pour le fullstack doit se faire manuellement par le VLAN 835 comme plusieurs fois évoqué, d'où l'adresse de BR différente. Il ne font à priori pas de reconfiguration de leur DHCP pour envoyer les bonnes options à chaque client qui en fait la demande. J'imagine que c'est lourd à gérer et que c'est plus simple de le faire avec un bête fichier de conf.
Oui j'ai une IP fullstack. Je comprends maintenant. Pourquoi VLAN 835 ? C'est le 836 pour Internet ??
Oui les configurations spécifiques se font peut être par provisionning.
Si je comprends bien quand on est en fullstack, l'adresse IPv6 reçue par DHCPv6 serait une adresse IPv6 CGNAT ? C'est bizarre car chez moi elle est pingable depuis l'extérieur. Je pensais que c'était une IPv6 normale. Y'a t'il un intérêt pour un opérateur à faire du CGNAT en IPv6 ?
Je pensais que la différenciation CGNAT / Fullstack était limité à IPv4.
Autre chose intéressante, Free envoit un prefixe IPv6 en /80 dans son Router Advertisement, (ainsi que l'option MTU = 1700, ce qui est normal pour laisser de la place au tunnel MAP-E). Ce préfixe correspond avec l'adresse IPv6 reçue en DHCP :)
Pourquoi /80 ? A noter, 128 - 80 = 48, soit la taille d'une adresse MAC.
-
Le 835 c'est le VLAN de config/services annexes. Et non il n'y a pas de CGNAT en ipv6, ça ne sert à rien (il ya largement assez d’adresses, sauf cas tordus, coucou orange et sa LB) et c'est très crado, on évite donc.
Pour le préfixe annoncé, si c'est dans le RA, c'est sans doute l'IP côté WAN, non ? Après c'est normalement du /64 pour le SLAAC, on ne peut pas faire plus petit (en théorie). Tu ne confonds pas avec une route des fois ? Ou alors c'est une conf stateless + statefull (mais pour faire quoi...). La box demande une IA_NA en plus du IA_PD dans sa requête DHCPv6 ?
La MTU à 1700 est normale oui.
Si tu pouvais m'envoyer une capture wireshark de la séquence DHCP en MP, ça m'aiderais à y voir plus clair ;)
-
Oui c'est une IP coté WAN, mais à quoi sert-elle ? Pour la configuration à distance de FreeBox OS ?
S'il n'y a pas de CGNAT en IPv6, je ne comprends pas trop pourquoi l'adresse IPv6 délivré dans DHcPv6 n'est pas dans le prefix en /60.
En plus, il n'y a pas besoin d'adresse Globale IPv6 sur le WAN, sauf l'adresse source pour le tunnel MAP-E. Si on a pas besoin d'IPv4, l'IPv6 fonctionne sans IPv6 globale sur le WAN. L'adresse link local en FE80 de l'interface WAN suffit pour le routage.
Non c'est bien un préfixe en /80, qui inclut l'adresse délivrée en DHcPv6 :
Le RA des équipements Free :
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0xc868 [correct]
[Checksum Status: Good]
Cur hop limit: 128
Flags: 0xc8, Managed address configuration, Other configuration, Prf (Default Router Preference): High
Router lifetime (s): 9000
Reachable time (ms): 3600
Retrans timer (ms): 0
ICMPv6 Option (Prefix information : 2a01:e00:30:xxxx:xxxx::/80)
ICMPv6 Option (Route Information : High ::/0)
ICMPv6 Option (MTU : 1700)
ICMPv6 Option (Source link-layer address : 00:07:cb:xx:xx:xx)
-
Tu as quels flags sur le préfixe ? A doit être à 0 en théorie (pas de SLAAC et de tout façon impossible). Car j'avais déjà zappé, mais le DHCPv6 ne se préoccupe pas de la longueur du préfixe, il faut donc quand même annoncer celui-ci pour que la route se crée, comme rappelé ici : https://blog.ipspace.net/2012/11/ipv6-router-advertisements-deep-dive.html
DHCPv6 does not carry prefix length information, so a prefix information option with L=1 is the only way a host may acquire an on-link route.
Donc à priori tout est normal. La FB récupère une IP WAN globale en DHCPv6 et la taille du préfixe suggère, comme tu l'as remarqué, qu'ils utilisent la MAC pour le suffixe. À quoi elle sert ? Sans doute pour l'admin oui, ça doit être plus simple pour eux j'imagine de repérer les FB par leur adresse MAC (si c'est bien ça) avec un préfixe commun.
Car en effet, pas besoin de GUA sur le WAN, celle que s'attribue la FB côté LAN suffit pour être joignable de l'extérieur. C'est comme ça chez Orange par ex. Et dans ce cas le MAP-E utilise le préfixe délégué, aucun soucis.
-
Oui c'est bien 0 pour le flag Autonomous address-configuration.
Donc c'est une annonce de route. Qui ne doit pas servir à grand chose d'ailleurs puisqu'il y a déjà une route par défaut attribuée par DHcPv6 ??
En tout cas sans la FreeBOX, la route par défaut obtenue en DHcPv6 suffit.
Effectivement pour un routeur, on y peut y accéder par n'importe quelle adresse IP située sur l'une de ses interfaces. Même par une IP qui ne se trouve pas sur une interface physique, par exemple une IP montée sur une interface de bouclage locale (lo). Sauf filtrage spécifique par le firewal évidement.
On peut même éventuellement en IPv4 avoir la même adresse IP sur plusieurs interfaces ! (adresses IP unumbered, pas dispo sous linux ou Mikrotik d'ailleurs) :)
Dans le cas de la FreeBox, le tunnel MAP-E utilise aussi une adresse source dans le préfixe délégué /60; et en adresse destination une adresse située dans le préfixe en /80 annoncé dans le RA, et dont une adresse est distribuée par DHcPv6. Simple n'est ce pas ?
Le flag du RA :
ICMPv6 Option (Prefix information : 2a01:e00:30:xxxx:xxxx::/80)
Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 80
Flag: 0x80, On-link flag(L)
1... .... = On-link flag(L): Set
.0.. .... = Autonomous address-configuration flag(A): Not set
..0. .... = Router address flag(R): Not set
...0 0000 = Reserved: 0
Valid Lifetime: 86400
Preferred Lifetime: 14400
Reserved
Prefix: 2a01:e00:30:xxxx:xxxx::
Pour IPv6 qu j'avais étudié quelque peu il y a bien longtemps, il me semblait que rien n'empêchait d'utiliser des préfixes plus petits que /64. Avec une restriction majeure qui est que l'autoconfiguration stateless ne fonctionne plus sur des sous réseaux plus petits que /64. Évidemment, pour des réseaux LANs avec des PCs, c'est plus que gênant ;D
-
On ne peut pas annoncer de route par DHCPv6 (contrairement à IPv4, ce qui dans certains cas est un peu hadicapant). Seul le RA annonce la route. D'ailleurs, je me demande à quoi sert d'envoyer explicitement la ::/0 vu que un simple RA "vide" (comme chez orange) suffit à définir celle-ci.
L'annonce du préfixe permet surtout de définir la taille du subnet (car une ipv6 via DHCP, c'est de fait une /128 donc difficile de dialoguer avec les voisins).
Pour IPv6 qu j'avais étudié quelque peu il y a bien longtemps, il me semblait que rien n'empêchait d'utiliser des préfixes plus petits que /64. Avec une restriction majeure qui est que l'autoconfiguration stateless ne fonctionne plus sur des sous réseaux plus petits que /64. Évidemment, pour des réseaux LANs avec des PCs, c'est plus que gênant
Oui c'est exactement ça. D'où l'obligation du DHCPv6 dans ce cas. Après rien n’empêche d'avoir un LAN 100% DHCPv6, mais ça implique de sacrifier certains appareils, genre android qui ne le supporte pas...
-
On ne peut pas annoncer de route par DHCPv6
....
Je pense que si. Un client peut demander les options de routes dans sa sollicitation DHCPv6. (OPTION_IA_RT). Même principe qu'en DHCP IPv4 avec l'option 121 (static classless route distribution).
J'ai testé cette option 121 en IPv4, elle fonctionne sans problème avec Windows 7 et probablement 10 voir 11. Elle permet de distribuer une route par défaut explicite, si besoin avec d'autres routes classless. Cela peut être utile pour éviter de devoir installer un client RIP sur les PC qui ont besoin de recevoir des routes spécifiques (par exemple pour ne pas perdre l'accès à des sous réseaux locaux lors du montage d'une interface VPN qui change la route par défaut).
Dans le cas de Mikrotik RouterOS, on peut demander au client DHCP (v4 ou v6) de monter une route par défaut. Sur le serveur DHCP en IPv4, c'est le champ gateway qui définit la passerelle. En IPv6 c'est l'adresse link local du serveur DHCP qui est utilisée comme passerelle pour la route par défaut. Idem pour les clients Windows et Linux de mémoire.
-
De ce que je vois, c'est resté à l'état de draft et n'a pas été approuvé... Tu peux le vérifier sur le site de l'IANA, aucune mention de IA_RT : https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml Cela dit ça m'a permis de découvrir que ça avait bien été envisagé et c'est dommage que ça n'ait pas abouti :-\
Pour IPv4, ça marche très bien oui, je m'en sers sur mon LAN.
En IPv6 c'est l'adresse link local du serveur DHCP qui est utilisée comme passerelle pour la route par défaut. Idem pour les clients Windows et Linux de mémoire.
La route par défaut est toujours annoncée par un routeur, jamais un DHCP puisque par définition ce n'est pas son rôle. L'une des premières choses que fait un hôte en v6 est un router solicitation et ensuite une requête DHCPv6 s'il y a lieu.
Ton raisonnement est uniquement valable si routeur et DHCPv6 sont la même machine.
Si tu ne me crois pas, voici une petite capture (la séquence est raccourcie, j'ai le rapid commit activé) :
-
Oui effectivement mon raisonnement n'est valable que si routeur et serveur DHCP sont sur la même machine, en IPv6.
Pour ceux que cela pourrait intéresser, j'ai réalisé une feuille de calcul pour obtenir simplement la chaîne de caractères nécessaire à la mise en place de l'option DHCP 121, pour la distribution de routes en IPv4 par DHCP, sans nécessiter un protocole de routage. Elle a un intérêt pratique mais surtout didactique, j'y ai intégré notamment quelques aspects pratiques relatifs à l'utilisation de cette option (peu connue) avec Windows et Linux.
https://www.stonerecording.art/createur-de-chaines-pour-loption-dhcp-121/
J'avais également utilisé cette possibilité sur mon réseau avant de finalement utiliser RIPv2, pour lequel il existe un client Windows assez ancien (Qbik Ripv2). Il fonctionne toujours sous Windows 10. Finalement c'est plus simple et c'est dynamique. Pas besoin de modifier l'option 121 si une nouvelle route doit être diffusée.
L'option 121 a surtout un intérêt pour diffuser un petit nombre de routes qui ne changent que rarement. Elle peut éviter la mise en place d'un protocole de routage et de ses clients. On peut l'utiliser sur un LAN avec des PC, mais il y a peut être quelques autres utilisations possibles. Je n'ai jamais essayé entre routeurs, cela fonctionne peut être.
A noter que chez Mikrotik avec RouterOS 7 il est désormais possible de spécifier des routes dans une une réservation d'adresse DHCP. Je n'ai pas encore essayé mais je suppose que cela génère automatiquement cette chaîne et l'option 121. Pour le moment c'est limité à une réservation d'adresse, on ne peut pas définir une liste de routes pour un network, à moins de définir et spécifier manuellement une option 121.
-
Bonjour Mikrotik,
Saurais-tu partager ta configuration, car j'ai commencé à regarder celle de certains autres fils, mais elle me semble incomplète.
Par exemple, modifier le MTU n'est pas suffisant, car sans effet si on ne modifie pas le L2 MTU. Combien de plus, 8 bits? Pour les vlan quel MTU?
Bref, un bon petit partage de conf pour les adorateurs de Mtk serait top. Je suis aussi en 7.14 beta (qui ne corrige toujours pas mon problème actuel)
Merci d'avance.
Stéphane.
-
Je ne crois qu'il soit nécessaire de modifier la L2 MTU, elle est implicite et s'ajuste en fonction (je me demande si c'est possible d'ailleurs). Si le chip du routeur ne prend pas plus de 1500 en L3 (donc 1518 L2) le paquet sera rejeté de toute façon et tu vas sans doute avoir une erreur si tu essaies de set la L3 à plus de 1500 (j'ai le cas sur un vieux raspbery pi).
En théorie, tout doit être automatique puisque Free annonce la MTU dans les RA, fixée à 1700 L3. Le WAN ne se configure pas tout seul ? Un cas à tester sur mon LAB tiens.
-
Le L2MTU maxi dépend du modèle de routeur. Sur le RB5009 il est de 9796 sur les interfaces Ethernet.
Les réglages MTU ne sont pas automatiques, sur Mikrotik en tout cas, il faut configurer à la main si on a besoin de plus de 1500, le plus souvent pour faire passer des tunnels avec un MTU interne de 1500.
Il faut commencer par monter le L2MTU à une valeur au moins égale à celle du MTU désiré.
Puis régler le MTU à la valeur désirée pour l'interface.
Etant donné que pour le VLAN836 il faut un MTU de 1700, il faudra un MTU de 1704 sur l'interface Ethernet parente pour pouvoir mettre 1700 sur le VLAN !! (car il faut une réserve de 4 octets pour le VLAN).
Free a choisis un MTU de 1700, mais je doute que des paquets de 1700 octets transitent sur le WAN, en effet dans le tunnel IPIPv6 le MTU est de 1500, et l'encapsulation IPIPv6 nécessite 40 octets. Donc en théorie un MTU de 1540 sur le VLAN 836 serait suffisant :)
Dans le tunnel IPIPv6, mettre un MTU de 1500.
Attention, si le port WAN se trouvait dans un bridge, tous les ports du bridge devraient avoir un MTU égal ou supérieur à celui désiré pour le bridge, sinon impossible de monter le MTU de l'interface bridge à la valeur désirée. C'est important car c'est bien l'interface bridge (ou plutôt une interface VLAN 836 montée sur ce bridge) qui reçoit et émet les paquets dans le cas de l'encapsulation IPIPv6.
Je n'ai pas fait de bridge pour le WAN, étant donné qu'on a besoin d'un seul port coté WAN.
En plus, un seul bridge peut être accéléré en hardware, j'ai préféré réserver l'accélération hardware pour le coté LAN.
Par curiosité j'avais essayé de faire un bridge coté WAN, pour accélérer l'encapsulation VLAN, mais ça n'a pas vraiment d'influence.
Pour la config il faut que je regarde et que je fasse un résumé. Rien de compliqué.
-
Bonjour Mikrotik,
Saurais-tu partager ta configuration, car j'ai commencé à regarder celle de certains autres fils, mais elle me semble incomplète.
Par exemple, modifier le MTU n'est pas suffisant, car sans effet si on ne modifie pas le L2 MTU. Combien de plus, 8 bits? Pour les vlan quel MTU?
Bref, un bon petit partage de conf pour les adorateurs de Mtk serait top. Je suis aussi en 7.14 beta (qui ne corrige toujours pas mon problème actuel)
Merci d'avance.
Stéphane.
Pour la config avec un routeur Mikrotik, je donne les grandes lignes (une config routeur, ça se mérite :).
Pour ceux qui ne se sentent pas capable de réussir cette configuration à partir des informations données ici, je leur conseil d'apprendre et de se documenter sur IPv4, IPv6 et RouterOS pour arriver au niveau requis, sous peine de créer des problèmes de sécurité sur leur installation, voir vers l'extérieur, ou d'encombrer le support Free qui de toutes façons ne prendra pas en charge la demande avec un routeur tierce.
Ne pas oublier également que rien ne garantit que cela fonctionnera dans le futur, même si on peut supposer (et fortement espérer) que Free ne se coupera pas de ses clients passionnés qui ont aussi permis son succès.
Prérequis : une Freebox avec un boitier ONTv2 externe, demander et obtenir une adresse IP full stack. Un routeur puissant, au moins un RB5009 pour obtenir un débit proche du maxi, upgradé en RouterOS 7.15 (version testée ici), upgrader également le firmware dans le menu system/routerboard. Config testée sur RB5009, et partiellement sur RB3011. Même avec un RB5009, le tunnel MAP-E saturera un cœur de processeur au débit maxi. Malheureusement ces tunnels, comme les autres tunnels d'ailleurs, ne sont pas accélérés en hardware sur les routeurs Mikrotik (ni probablement sur tous les autres routeurs dans la gamme SOHO chez les autres fabricants).
Pour IPv6 :
1) Vérifier la configuration du Firewall pour éviter tout risque. Autoriser l'ICMPv6, et le DHCPv6 (udp 546) pour les adresses sources fe80::/10 en input.
2) Changer l'adresse MAC de l'interface SFP pour celle de la FreeBOX (à récupérer sur l'étiquette de la Freebox ou sur l'interface web), ne peut se faire qu'en ligne de commande. Aide disponible dans l'aide RouterOS.
3) Si le SFP est dans un bridge, le retirer du bridge. Vérifier que le lien monte (link ok) lorsque le câble DAC en provenance du boitier ONTv2 est branché sur le port SFP du routeur. S'il ne monte pas, c'est probablement un problème d'autonégociation. Retirer les options autres que 1G BaseX dans l'autonégociation. On peut laisser tout ce qui est en 1G, 2.5G, 5G, 10G sans normalement que cela ne pose de problème. Si le lien ne monte pas, ce n'est pas la peine d'aller plus loin. Problème avec la fibre, le boitier ONTv2, le câble DAC, éventuellement un problème de compatibilité SFP.
4) Passer le L2MTU du SFP à 1704 puis le MTU à 1704.
5) Ajouter une interface vlan 836 sur l'interface SFP avec un MTU à 1700. Mettre l'interface vlan 836 dans la liste des interfaces WAN (pour simplifier la reconfiguration du Firewall lors de changements de configuration éventuels). L'interface SFP parente n'a pas besoin d'être dans cette liste. Vérifier que les règles du firewall utilisent bien cette liste d'interfaces au lieu de l'interface VLAN 836 en elle-même.
6) Ajouter un client DHCPv6, avec demande d'adresse seulement, sur l'interface VLAN 836. Ne pas cocher "Request Info" ni "prefix". Cocher "Use Interface DUID" et "Add default route". On doit obtenir une IPv6 globale dans un préfixe autre que le /60 délivré par Free. Cette adresse semble ne pas servir, tout du moins avec un routeur. On obtient donc aussi une route dynamique par défaut vers l'adresse link-local de l'équipement Free en face. Cette requête DHCPv6 est obligatoire pour ouvrir la connectivité Internet, y compris pour avoir accès au border router MAP-E. Une configuration manuelle sans DHCPv6 ne fonctionnera pas. Pour faire comme la Freebox, on peut éventuellement ajouter une option 6 dans la requête, avec en valeur 0x0017005e pour demander les DNS et l'adresse du border router MAP-E. Mais ce n'est pas utile, juste éventuellement intéressant pour observer la réponse dans Wireshark. En plus, l'adresse de Border Router MAP-E fournie par la réponse DHCPv6 n'est pas celle du serveur BR pour les IPv4 full stack, mais celle du serveur pour les IP partagées :)
Si on veut utiliser le DNS IPv6 Free, cocher "Use Peer DNS", sinon ajouter un serveur DNS IPv6 custom dans le menu IP/DNS.
A partir de là, on doit avoir une connectivité IPv6 au moins depuis le routeur.
Edit : j'ai du ajouter un script de démarrage pour stopper et relancer le serveur DHCPv6 au reboot du routeur, sinon perte de connectivité.
Il semble que le problème se produit uniquement si l'interface VLAN 836 est montée sur un Bridge Vlan aware, ce qui est mon cas. C'est probablement un bug sur RouterOS. Le problème provient de la route par défaut qui est corrompue après reboot.
-------------------------------------------------------------
add name="DHCPv6 restart" on-event=\
"delay 2\r\
\n/ipv6/dhcp-client/disable numbers=0\r\
\ndelay 3\r\
\n/ipv6/dhcp-client/enable numbers=0\r\
\n" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-time=startup
-------------------------------------------------------------
Une autre solution : mettre la route par défaut en statique, et décocher "Add default route" dans le client DHCPv6.
7) Pour chaque interface LAN, ajouter une adresse IPv6 dans un préfixe /64 issu du /60 délivré par Free (16 préfixes disponibles :)
8) Activer le ND pour chaque interface LAN afin de distribuer les préfixes sur les LANs.
9) Vérifier la configuration du firewall, vers le WAN, entre LANs, etc... A partir de là, on doit obtenir de l'IPv6 dans tous les LANs. Penser à bien fermer l'accès depuis le WAN en forward, car étant donné qu'il n'y a pas de NAT en IPv6, le trafic entrant est autorisé par défaut si aucune configuration firewall.
Pour IPv4 :
1) Vérifier la configuration du Firewall IPv4 pour éviter tout risque. NAT et règles de forwarding, règles Input, etc...
Dans le firewall IPv6, Ouvrir le protocole ipencap (4) sur l'interface Vlan 836 en input.
2) Déterminer l'adresse IP source pour le tunnel MAP-E. Elle est composée du premier sous réseau / 64 issu du /60 délivré par Free, auquel on ajoute 0:ffff:ffff:0 à la fin. Si vous ne connaissez pas le /60, il est dispo sur l'interface WEB Free, ou bien on peut l'obtenir en le demandant dans la requête DHCPv6.
3) Ajouter cette adresse, en /128, sur le Vlan 836. Les autres adresses du /64 dont elle est issue restent éventuellement disponible pour utilisation sur une interface LAN.
4) Ajouter un tunnel MAP-E (IPIPv6) et y mettre un MTU de 1500.
local address : Ip source précédemment déterminée
remote address : normalement c'est toujours 2a01:e00:29:200a::fffd
Attention, j'ai remarqué que l'option KeepAlive posait problème avec le border router qui délivre les IP partagée. Le tunnel se coupe régulièrement avec cette option. Pour le serveur des IP full stack dont on parle ici, elle semble utilisable sans soucis.
5) Ajouter l'interface du tunnel dans la liste des interfaces WAN
6) Ajouter l'IPv4 publique full stack sur l'interface du tunnel, en /32
7) Ajouter la route par défaut IPv4 (0.0.0.0) avec l'interface du tunnel comme gateway
8) Revérifier et si besoin ajuster les règles de firewall pour la configuration IPv4 décrite ci-dessus.
Edit : sur mon RB5009, où j'ai le port WAN dans le bridge principal (mettre le port WAN dans le bridge permet de bridger certains VLAN sans utiliser un switch externe), le MTU de l'interface VLAN 836 saute et revient à 1500 à chaque redémarrage. Pour l'instant j'ai corrigé le problème avec un script de démarrage pour remettre le MTU du VLAN 836 à 1700, en passant par 1600 sinon ça ne marche pas.
NB : Le problème a été résolu dans RouterOS version 7.15.
delay 15
/interface vlan set VLAN-Free mtu=1600
delay 4
/interface vlan set VLAN-Free mtu=1700
J'ai remonté le problème à Mikrotik qui a pu le reproduire. Cela devrait être corrigé dans la version Ros 7.15 à venir. C'est corrigé.
-
@Mikrotik : Je vois que t'as viré la ref à l'ip partagée, marche ou marche pas du coup ? Car il doit falloir faire toutes les règles de parefeu/NAT à la main, vu que pas de support du MAP en natif. J'avais bien quelques doutes que ça puisse se faire aussi facilement que la full stack, où un bête tunnel suffit.
Sinon, pour le calcul de l'IP et des range de ports, un truc assez pratique (mais ça fait du boulot en plus) : une VM openwrt à la place et on obtient un truc comme ça (vrai test de ma part, fonctionnel via DHCPv6) :
~# cat /tmp/map-wan6_4.rules
rule=type=map-e,ealen=2,prefix4len=30,prefix6len=60,ipv4prefix=192.0.2.0,ipv6prefix=2001:db8:940e::,offset=0,psidlen=0,psid=0,br=2001:db8:940e::1,
RULE_1_FMR=0
RULE_1_EALEN=2
RULE_1_PSIDLEN=0
RULE_1_OFFSET=0
RULE_1_PREFIX4LEN=30
RULE_1_PREFIX6LEN=60
RULE_1_IPV4PREFIX=192.0.2.0
RULE_1_IPV6PREFIX=2001:db8:940e::
RULE_1_IPV6PD=2001:db8:940e:4::
RULE_1_PD6LEN=62
RULE_1_PD6IFACE=wan6
RULE_1_IPV6ADDR=2001:db8:940e:4:0:c000:201:0
RULE_BMR=1
RULE_1_IPV4ADDR=192.0.2.1
RULE_1_ADDR4LEN=32
RULE_1_BR=2001:db8:940e::1
RULE_COUNT=1
-
Pour l'IP partagée, cela fonctionnait à moitié, trafic montant possible, mais pas de retour. Il est possible que je n'ai pas la bonne IP publique partagée. Ou bien que l'iP partagée ne soit pas routée en retour lorsqu'on est en IP full stack. J'ai trouvé cette IP partagée en écoutant dans le second tunnel, mais je n'en suis pas sur. Et on ne peut pas l'obtenir en DHCP puisque les tunnels sont en IP. Il faudra que j'essaie avec mon ancienne IP partagée, c'est peut être la même.
Et oui cela occasionne une modification au niveau niveau du NAT et du firewall, ainsi que le changement de la route par défaut, ou mise en place de règles de routage par mangle, ou mise en place d'un VRF pour isoler cette partie. On rentre dans les joies du multihoming.
Je n'ai pas bien saisi à quoi servent ces règles sur OpenWRT, elles permettent de calculer quelles adresses exactement ? Au niveau des ports cela permet de trouver le range utilisé par l'IP partagée ?
Sinon je pense qu'on peut utiliser cela pour trouver le range de ports de l'IP partagée :
http://ip.bieringer.net/cgn-test.html
Au passage, en faisant des tests de NAT avec l'IP full stack, je n'ai pas réussi à obtenir un NAT full cone (Endpoint Independent Mapping et Endpoint Independent Filtering, selon la nouvelle RFC5780). Pourtant RouterOS 7.13 ou 7.14 supporte ce type de NAT avec la nouvelle action NAT endpoint-independant-nat.
Voir ici :
https://help.mikrotik.com/docs/display/ROS/NAT#NAT-Endpoint-IndependentNAT
J'ai réalisé les tests avec NatType Tester version 8.02.
https://github.com/HMBSbige/NatTypeTester/releases
https://github.com/HMBSbige/NatTypeTester/blob/master/README.md
J'ai l'impression que Free (et probablement d'autres opérateurs) réalise un filtrage sur l'IP full stack dans son réseau pour éviter l'ouverture du NAT en Full Cone.
Pourtant chez Mikrotik leurs tests montrent que la nouvelle action NAT fonctionne correctement. Il faudrait tester avec un serveur Stun privé pour vérifier que c'est bien Free qui verrouille le NAT full cone.
J'ai testé aussi avec un NAT 1:1 en utilisant des règles Netmap qui devrait également donner une ouverture Full Cone et le résultat est un NAT avec adresses et ports dépendants en entrée.
-
Pour l'IP partagée, cela fonctionnait à moitié, trafic montant possible, mais pas de retour. Il est possible que je n'ai pas la bonne IP publique partagée. Ou bien que l'iP partagée ne soit pas routée en retour lorsqu'on est en IP full stack. J'ai trouvé cette IP partagée en écoutant dans le second tunnel, mais je n'en suis pas sur. Et on ne peut pas l'obtenir en DHCP puisque les tunnels sont en IP. Il faudra que j'essaie avec mon ancienne IP partagée, c'est peut être la même.
Et oui cela occasionne une modification au niveau niveau du NAT et du firewall, ainsi que le changement de la route par défaut, ou mise en place de règles de routage par mangle, ou mise en place d'un VRF pour isoler cette partie. On rentre dans les joies du multihoming.
Je me doutais que ce n'était pas aussi simple. Rien que si tu loupes ta plage de ports, ça ne risque pas de fonctionner.
Je n'ai pas bien saisi à quoi servent ces règles sur OpenWRT, elles permettent de calculer quelles adresses exactement ? Au niveau des ports cela permet de trouver le range utilisé par l'IP partagée ?
Oui, ça affiche les ports et l'ipv4 correspondante, exemple avec une ip partagée (1:4) et un offset (IPv6 remplacé par le pool d'orange sur le mobile, ce n'est pas mon préfixe) :
rule=type=map-t,ealen=2,prefix4len=32,prefix6len=60,ipv4prefix=192.168.64.1,ipv6prefix=2a01:cb1e:456:9460::,offset=4,psidlen=0,psid=0,dmr=64:ff9b:ce::/64,
RULE_1_FMR=0
RULE_1_EALEN=2
RULE_1_PSIDLEN=2
RULE_1_OFFSET=4
RULE_1_PREFIX4LEN=32
RULE_1_PREFIX6LEN=60
RULE_1_IPV4PREFIX=192.168.64.1
RULE_1_IPV6PREFIX=2a01:cb1e:456:9460::
RULE_1_IPV6PD=2a01:cb1e:456:9464::
RULE_1_PD6LEN=62
RULE_1_PD6IFACE=wan6
RULE_1_IPV6ADDR=2a01:cb1e:456:9464:0:c0a8:4001:1
RULE_BMR=1
RULE_1_IPV4ADDR=192.168.64.1
RULE_1_ADDR4LEN=32
RULE_1_PORTSETS='5120-6143 9216-10239 13312-14335 17408-18431 21504-22527 25600-26623 29696-30719 33792-34815 37888-38911 41984-43007 46080-47103 50176-51199 54272-55295 58368-59391 62464-63487 '
RULE_1_DMR=64:ff9b:ce::/64
RULE_COUNT=1
Sinon je pense qu'on peut utiliser cela pour trouver le range de ports de l'IP partagée :
http://ip.bieringer.net/cgn-test.html
Pas sûr que ça fonctionne, vaut mieux un script fait pour : https://github.com/ejordangottlieb/pyswmap
Si tu veux approfondir, y'a une très bonne doc faite par les développeurs de Jool (c'est pour MAP-T, mais les mêmes règles s'appliquent) :
https://nicmx.github.io/Jool/en/map-t.html
https://nicmx.github.io/Jool/en/intro-xlat.html#map-t
https://nicmx.github.io/Jool/en/run-mapt.html
-
Je me doutais que ce n'était pas aussi simple. Rien que si tu loupes ta plage de ports, ça ne risque pas de fonctionner.
...
Possible que j'ai fait une erreur sur le DNAT. Par contre je pense connaitre ma plage de ports. Quelque chose de spécial à faire sur les règles NAT ? La config NAT m'intéresse.
-
Tu as un exemple de config manuelle dans la doc de Jool : https://nicmx.github.io/Jool/en/run-mapt.html#napt sous Linux avec iptables.
Mais c'est en plus du module qui fait le map-t. Après vu que map-e est plus simple, peut-être que les règles de NAT suffisent en + du tunnel. Honnêtement, c'est trop complexe pour moi, désolé.
Si tu veux assimiler tous les concepts et faire tes propres tests, tu peux aller faire un tour sur le topic que j'ai ouvert dans la section ipv6 : Test du MAP-T et MAP-E en LAB (https://lafibre.info/ipv6/test-du-map-t-en-lab-jy-suis-presque/) Avec une VM routerOS et VPP, tu devrais pouvoir simuler le réseau de Free.
-
Bon j'avais juste oublié de spécifier mes ports de sortie dans les règles Src-nat :) Donc l'adresse IP était bonne. Ainsi que le range de ports que j'avais détecté mais oublié de mettre dans les règles Src-nat.
Donc ça fonctionne. IP partagée et IP full stack en même temps.
A noter : il faut deux règles Src-NAT, une pour le TCP et une pour l'UDP, pour pouvoir spécifier les ports de sortie. Par contre le ping ne passe pas évidement. Est-ce-qu'il passe sur une FreeBOX depuis l'intérieur vers l'extérieur avec une IP partagée ?
-
Par contre le ping ne passe pas évidement. Est-ce-qu'il passe sur une FreeBOX avec une IP partagée ?
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
-
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.
-
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.
-
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
-
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.
-
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.
-
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é.
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.
-
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.
-
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 :
-
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.
-
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/ (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.
-
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
: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
(https://i.ibb.co/3fKfrJc/1.png)
Puis d'ajouter l'adresse comme suit :
(https://i.ibb.co/8zg1G25/2.png)
Du coup, la distrib des ipv6 publiques se fait automatiquement. Juste intéressant si vous publiez des ressources.
-
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.
-
Hello Mikrotik,
Dans mon cas, si le client DHCP ne demande pas d'adresse, mais seulement un préfixe, ça ne fonctionne pas (au redémarrage de l'ONU, d'ailleurs, n'était-ce pas ton soucis?). Pas de flux internet, d'où ma suppression a posteriori parce que je trouve ça très moche. Sans avoir investigué, j'imagine que c'est l'architecture EPON qui le nécessite.
Effectivement, je NAT pour 2 raisons, un bonne et une mauvaise.
La mauvaise, parce que j'en suis encore à préférer esthétiquement une IP pour ma connexion (je ne donne pas mon âge, mais il faut y aller doux sur le passage à l'IP V6)
La bonne, j'utilise un service SaaS qui ne me permet d'autoriser que 3 IPs....pas de plage, enfin si, mais beaucoup plus cher.
Là j'ai une config qui me convient et assez dynamique, je pense que je vais même pousser mon script pour affecter les ip statiques des interfaces et tunnel en fonction du préfixe au cas ou il change un jour (aucune idée de si cela peut arriver.) Du coup, ce sera full dynamique sur la partie IPV6.
A ta connaissance, est-ce que quelqu'un à trouvé comment enter dans l'ONU? J'aimerais monitorer 2-3 métriques.
-
Hello Mikrotik,
Dans mon cas, si le client DHCP ne demande pas d'adresse, mais seulement un préfixe, ça ne fonctionne pas (au redémarrage de l'ONU, d'ailleurs, n'était-ce pas ton soucis?). Pas de flux internet, d'où ma suppression a posteriori parce que je trouve ça très moche. Sans avoir investigué, j'imagine que c'est l'architecture EPON qui le nécessite.
Effectivement, je NAT pour 2 raisons, un bonne et une mauvaise.
La mauvaise, parce que j'en suis encore à préférer esthétiquement une IP pour ma connexion (je ne donne pas mon âge, mais il faut y aller doux sur le passage à l'IP V6)
La bonne, j'utilise un service SaaS qui ne me permet d'autoriser que 3 IPs....pas de plage, enfin si, mais beaucoup plus cher.
Là j'ai une config qui me convient et assez dynamique, je pense que je vais même pousser mon script pour affecter les ip statiques des interfaces et tunnel en fonction du préfixe au cas ou il change un jour (aucune idée de si cela peut arriver.) Du coup, ce sera full dynamique sur la partie IPV6.
A ta connaissance, est-ce que quelqu'un à trouvé comment enter dans l'ONU? J'aimerais monitorer 2-3 métriques.
Il faudrait vérifier la route DHCPv6 par défaut qui monte en dynamique par le client DHCPv6. Il y a un bug dans RouterOS si on demande d'ajouter une route par défaut, selon les circonstances elle peut ne pas contenir l'adresse de passerelle en fe80. Auquel cas, il faut désactiver l'ajout de la route par défaut par le client DHCPv6, et l'ajouter manuellement en statique.
Pour l'ONU non pas à ma connaissance. Je suppose que l'accès est standard en telnet ou SSH comme pour les SFP intelligents, mais avec un login par mot de passe.
-
Il faudrait vérifier la route DHCPv6 par défaut qui monte en dynamique par le client DHCPv6.
pour moi, ça ça n'existe pas. le dhcpv6 ne donne aucune route par défaut. la route par défaut elle est reçu par RA, après avoir réussi une requête dhcp v6
-
...
Du coup, la distrib des ipv6 publiques se fait automatiquement. Juste intéressant si vous publiez des ressources.
Des IPv6 publiques ne sont pas réellement distribuées. C'est la distribution des préfixes qui se fait automatiquement. Ensuite les adresses sont forgées sur les périphériques (par SLAAC : configuration automatique d'adresse sans état) à partir du préfixe distribué sur chaque sous-réseau par NDP (neighbour discovery protocol ou protocole de découverte d'hôtes voisins). RA (Router Advertisement) est un des mécanismes de NDP, utilisant ICMPv6.
Pour distribuer des IPv6 complètes, il faut un serveur DHCPv6. Solution rarement utilisée pour la distribution d'adresses. Mais utilisée par Free pour une des adresses IPv6 globale de la FreeBOX. Le serveur DHCPv6 Free délivre d’ailleurs aussi l'adresse IPv6 source du tunnel MAP-E (IPIPv6) pour l'adresse IPv4 partagée, ainsi que l'adresse du border router destination, à travers les options softwire46.
Pas facile de s'y retrouver en IPv6 entre NDP et DHCPv6. Surtout que les deux protocoles ont des fonctions qui peuvent se chevaucher : leur utilisation simultanée nécessite donc l'ajout de drapeaux sur le serveur ND :
- "Other Configuration" pour indiquer que les voisins peuvent utiliser un serveur DHCPv6 pour obtenir les adresses DNS et nom de domaine
- "Managed Address Configuration" pour indiquer que les voisins doivent récupérer leur adresse IPv6 sur un serveur DHCP, et non pas les forger eux même.
On a bien ces deux drapeaux à 1 sur les RA en provenance de Free, donc ils indiquent qu'il faut récupérer les adresses DNS et une adresse IPv6 globale en DHCPv6.
Le Router Advertisement de Free annonce un préfixe en /80, il est donc différent du /60 attribué à chaque client. Ce /80 englobe l'adresse délivrée par DHCPv6, adresse qui n'est donc pas dans le /60. Elle sert probablement au management de la Freebox. Elle est joignable publiquement.
Le préfixe /60 est lui attribué par DHCPv6. :)
-
Pour info, un site intéressant pour remplacer les ONT :
https://hack-gpon.org/
La première phrase est intéressante :
Most ONTs run customized firmware which implement vendor and ISP-specific integrations and are locked down in functionality to match service requirements. ONTs often perform differently depending on the OLT and the settings applied by the ISP; for convenience it is often desirable to switch from an external ONT to an SFP or vice-versa, but most OLTs perform so many checks on the ONT that a simple replacement is almost impossible.
En français :
La plupart des ONT utilisent des microprogrammes personnalisés qui mettent en œuvre des intégrations spécifiques au fournisseur et au FAI et sont verrouillés au niveau des fonctionnalités pour répondre aux exigences du service. Les ONT fonctionnent souvent différemment selon l'OLT et les paramètres appliqués par le FAI ; pour des raisons de commodité, il est souvent souhaitable de passer d'un ONT externe à un SFP ou vice-versa, mais la plupart des OLT effectuent tellement de contrôles sur l'ONT qu'un simple remplacement est presque impossible.
La mauvaise nouvelle, c'est que l'EPON est peu utilisé, et donc peu documenté. Voir ici :
https://hack-gpon.org/epon/free_iliad/
-
Des IPv6 publiques ne sont pas réellement distribuées. C'est la distribution des préfixes qui se fait automatiquement. Ensuite les adresses sont forgées sur les périphériques (par SLAAC : configuration automatique d'adresse sans état) à partir du préfixe distribué sur chaque sous-réseau par NDP (neighbour discovery protocol ou protocole de découverte d'hôtes voisins). RA (Router Advertisement) est un des mécanismes de NDP, utilisant ICMPv6.
Pas de débat de puriste ou de sémantique, le fait est que de la sorte, chaque équipement se voit pourvu d'une ip v6 routable sur le n'internet qui est, me semble-t-il, un des piliers de l'IP V6, plus de NAT ou de PAT nécessaire, juste du routage et du firewalling, donc un internet vachement plus performant :)
J'ai un peu de mal avec le concept du DHCP v6 sur mikrotik ou IPv6 tout court. Je me suis ajouté la distrib d'IP en fc00::/7 pour le routage entre mes 2 sites. Ca fonctionne, mais pas aussi souple que ce que j'aurais souhaité. Je voulais ditribuer un /122...genre fdd1::/122. Jamais réussi. Du coup à part mes routeurs, je n'ai pas d'IPv6 mémorisable. Je sais, je reste old school.
-
Pas de débat de puriste ou de sémantique, le fait est que de la sorte, chaque équipement se voit pourvu d'une ip v6 routable sur le n'internet qui est, me semble-t-il, un des piliers de l'IP V6, plus de NAT ou de PAT nécessaire, juste du routage et du firewalling, donc un internet vachement plus performant :)
J'ai un peu de mal avec le concept du DHCP v6 sur Mikrotik ou IPv6 tout court. Je me suis ajouté la distrib d'IP en fc00::/7 pour le routage entre mes 2 sites. Ca fonctionne, mais pas aussi souple que ce que j'aurais souhaité. Je voulais ditribuer un /122...genre fdd1::/122. Jamais réussi. Du coup à part mes routeurs, je n'ai pas d'IPv6 mémorisable. Je sais, je reste old school.
Puriste peut être, mais surtout efficace. Faites signe si vous voyez une autre config Mikrotik sans erreur qui fonctionne avec Free.
Pour la vitesse d'Internet, c'est surtout la capacité des équipements, routeurs et commutateurs à traiter les paquets pratiquement en temps réel jusqu'au niveau IP, donc avec une accélération par des FPGA ou des ASIC, que ce soit en IPv4 ou IPv6. Ce qui n'est pas le cas des routeurs entrée de gamme tels que ceux qu'on utilise en tant que particulier, qui même s'ils peuvent souvent traiter en temps réel jusqu'au niveau 2, ne peuvent pas router et filtrer en temps réel au niveau IP.
En général on ne distribue pas de préfixe plus petit que /64 pour rester compatible avec la configuration automatique stateless. Sinon ensuite il faut utiliser DHCPv6 pour distribuer les adresses et tous les équipements ne sont plus compatibles.
Mémoriser des IPv6 n'est pas chose facile, par contre comme en IPv4 on peut utiliser des pointeurs DNS, de type AAAA pour IPv6 :) Rien n'empêche d'en mettre en local sur le routeur qui va relayer les requêtes DNS. Menu /ip/dns/static sur Mikrotik.
Sinon pour les adresses IPv6 unique local, le bloc ULA, (adresses non routables sur Internet), l'équivalent des IP privées en IPv4, le préfixe est FD00::/8 car le bit 8 est toujours à 1 : 11111101. Le préfixe fc00::/8 n'est pas alloué actuellement.
Je ne vois pas trop l'intérêt d'utiliser cela en interne, sauf peut être à vouloir reproduire le schéma IPv4 avec du NAT66, et se retrouver avec tous les problèmes induits par le NAT. Pour certains, ULA = Useless Local Addresses :)
-
Sinon pour les adresses IPv6 unique local, le bloc ULA, (adresses non routables sur Internet), l'équivalent des IP privées en IPv4, le préfixe est FD00::/8 car le bit 8 est toujours à 1 : 11111101. Le préfixe fc00::/8 n'est pas alloué actuellement.
Je ne vois pas trop l'intérêt d'utiliser cela en interne, sauf peut être à vouloir reproduire le schéma IPv4 avec du NAT66, et se retrouver avec tous les problèmes induits par le NAT. Pour certains, ULA = Useless Local Addresses :)
Bon, on sort du sujet, je voulais dire fc00::/7 dont le fd00::/8 que j'utilise.
L'intérêt existe bien pour des réseaux privés, car routable (mais pas sur internet). Dans mon cas je connecte mes deux sites en VPN.
Ensuite il y a la norme...et la norme. En IPV4, la notion de classe a été totalement bypassé sur les réseaux privés et ne pose aucune difficulé à proposer des "petit" network genre des 10.x.x.x/25.
J'aurai imaginé faire la même chose en ipV6 pour mon petit confort personnel.
Mais j'ai bien compris qu'en IPV6 nous étions si riches que pas besoin de compter les centimes, on donne et on donne large.
Un DHCP qui me distribue un /122 voire un /123 me botterait bien.
-
Je ne vois pas trop l'intérêt d'utiliser cela en interne, sauf peut être à vouloir reproduire le schéma IPv4 avec du NAT66, et se retrouver avec tous les problèmes induits par le NAT. Pour certains, ULA = Useless Local Addresses :)
Alors en fait c'est un peu hors sujet, mais il y a des use cases :)
Chez Orange par exemple, le préfixe alloué peut changer. Je fais de l'autohébergement. Si je n'annonce que des GUA et que le préfixe change, mes enregistrements DNS internes sont aux fraises puisqu'ils pointent sur les anciennes GUA. Donc j'annonce en pratique 2 préfixes: Le GUA obtenu chez Orange et un ULA qui ne changera jamais. Mes enregistrements DNS internes pointent sur les ULA. Un problème en moins.
Autre Use case: J'ai un VPN wireguard roadwarrior (et donc les adresses des clients sont hardcodées, pas le choix). Même problème en pire parce que si le GUA change je dois modifier la conf de tous les clients VPN à la mano. Du coup j'utilise de l'ULA uniquement dans wireguard et je fais du mapping de préfixe IPv6 pour mapper le /64 ULA des clients VPN sur un /64 GUA. (Et accessoirement mes clients VPN n'ont pas d'IPv4 du tout, je fais du NAT64/DNS64)
-
Chez Orange par exemple, le préfixe alloué peut changer. Je fais de l'autohébergement. Si je n'annonce que des GUA et que le préfixe change, mes enregistrements DNS internes sont aux fraises puisqu'ils pointent sur les anciennes GUA. Donc j'annonce en pratique 2 préfixes: Le GUA obtenu chez Orange et un ULA qui ne changera jamais. Mes enregistrements DNS internes pointent sur les ULA. Un problème en moins.
Je viens de laisser mon abo orange pour Free et jamais en 5 ans mon préfixe n'a changé. Même l'IPV4 est devenu "fixe" il y a environ 1 an tandis qu'elle changeait à chaque renouvellement du bail avant.
Néanmois, et je continue avec Free, bien que tout laisse penser que nous sommes en "IPs Fixes", je ne considère jamais rien pour acquis d'autant que ce n'est pas contractuel versus les offres pro/entreprise.
Donc, je mets à jour mes entrées DNS en cas de changement via un script depuis le routeur en utilisant l'API de CLoudflare.
J'utilise également Wireguard pour mes 2 sites et 1 roadwarrior que je suis. Je n'ai pas compris ton point d'adresse hardcodé. J'utilise et j'affecte des adresses dans la plage fd00::/8.
Et parce que je suis toujours frileux, je ne permets que mes IPs de se connecter en wireguard avec les listes dans les FW IPv4 et 6 tout ça en dynamique avec des scripts et cloudflare. Pour mon iPhone et mon Mac j'utilise Shortcuts pour mettre à jours les entrées dans la zone DNS qu'utilise le script Mikrotik pour mettre à jour ses listes.
-
...
Donc, je mets à jour mes entrées DNS en cas de changement via un script depuis le routeur en utilisant l'API de CLoudflare.
...
Quelqu'un à t'il essayé le DNS sur HTTPs (DoH) avec Cloudfare ? Problèmes très fréquents de connectivité chez moi, comme si leur serveur était surchargé.
Pour revenir au NAT et aux adresses privées avec IPv6, cela devrait rester d'un usage exceptionnel. IPv6 permet enfin de faire simple, et d'avoir un routage de bout en bout y compris chez l'utilisateur final, sans NAT, pourquoi retourner en arrière ?
-
Quelqu'un à t'il essayé le DNS sur HTTPs (DoH) avec Cloudfare ? Problèmes très fréquents de connectivité chez moi, comme si leur serveur était surchargé.
Nope.
Je ne sais pas si c'est la même infra que pour leur API du CDN, mais celle-ci fonctionne à merveille. De toute façon, jamais rien ne sera aussi rapide qu'une requête DNS.
Je viens d'implémenter la solution de ZTNA de CloudFlare via container de Mikrotik, ça fonctionne très bien pour accéder à mes ressources avec le l'authent SAML de Google, et je vais regarder pour passer les requetes DNS dans ce tunnel plutôt que sur internet mais en restant sur du DNS classique.
Me concernant sur le sujet des adresses privées, je ne fais pas de NAT mais bien que du routage (mon seul usage du NAT est pour la navigation internet). Je ne vois pas bien comment tu imagines faire autrement. pour faire simple 3 types d'IP,
- les FE80 non routable
- toutes celles dites publiques routables sur internet (j'aimerais bien trouver un référentiel à qui sont affactés les préfixes)
- et les FC00::/7 dont le FD00::/8 pour justement router des flux entre réseaux privés
Je ne suis probablement pas un expert mais j'ai quand même tenté de lire les RFC afférentes à l'IPV6 et c'est ce que j'en retiens.
-
Il y a aussi d'autres types d'adresses en IPv6 :
Indéterminée -> ::/128
Toutes les adresses -> ::/0
Loopback -> ::1/128
Multicast -> FF00::/8 (avec 4 bits qui servent à indiquer la portée)
Anycast -> même préfixes que les adresses globales
Et quelques plages réservées à des usages spécifiques.
-
voici un script qui permet de se considérer en full dynamique pour la partie IPv6.
Il faut configurer le client DHCP v6 avec Prefix et Adress cochés et placer le script ci-dessous dans dans l'onglet Advanced.
# modifiez les deux variables suivantes avec le nom des interfaces que vous avez donné
:local interface "vlan836-free"
:local ipipv6 "ipipv6-free"
:local prefix [/ipv6 dhcp-client get [find interface=$interface] value-name=prefix]
:set prefix ([:pick $prefix 0 ([:find $prefix ","]-3)])
:local gw [/ipv6 dhcp-client get [find interface=$interface] value-name=address]
:set gw ([:pick $gw 0 ([:find $gw ","])])
:local addresse0ffff (([:pick $prefix 0 ( [ :len $prefix ] -1 )]) . "0:ffff:ffff:0")
#supprime toutes les adresses fixées précédemment.
/ipv6 address remove [find where address~"2a01"]
delay 3s
#supprime l'IP moche
/ipv6 address remove [find address="$gw/128"]
#ajoute l'ip necessaire au routage du tunnel ipipv6
/ipv6 address add address="$addresse0ffff/128" interface="$interface" advertise=no
#set l'ip sur l'interface ipipv6
/interface ipipv6 set $ipipv6 local-address=$addresse0ffff
#ajoute la première IP du premier préfixe
/ipv6 address add address="$prefix/128" interface="$interface" advertise=no
Maintenant, j'aimerais bien passer en dynamique sur la partie IPv4.
-
Maintenant, j'aimerais bien passer en dynamique sur la partie IPv4.
Pour l'adresse IPv4 partagée :
Le préfixe IPv4 se trouve dans la réponse DHCPv6, dans l'option S46 MAP-E Container. Il est peut être possible de récupérer le contenu de cette option dans RouterOS, pour le traiter dans un script. C'est la variable "options" qui contient un tableau des options reçues. Pour demander cette option, utiliser le code option 6 dans le client DHCPv6 avec une chaine hexa pour demander l'option 94.
La chaîne hexa :
0x005e
J'ai vérifié les données reçues dans la variable $options, elles sont utilisables, mais elles sont en hexa brute. Il faudrait créer un script pour parser et mettre en forme.
Le préfixe Ipv4 reçu dans l'option S46 est un /11. Pour obtenir l'IPv4 partagée, il suffit (!) de concaténer ces 11 bits du préfixe IPv4 avec les bits 38 à 58 du préfixe IPv6 en /60 (soit 21 bits) délivré dans la réponse DHCPv6, puis de convertir ces 32 bits en adresse IPv4 décimale.
On déduit qu'il s'agit des bits 38 à 58 parce que l'option S46 reçue indique un préfixe IPv6 en /37. Ce sont donc les (32 - 11 =) 21 bits suivants qui permettent de forger l'IPv4 du client, les 11 premiers bits de l'IPv4 étant fournis par le préfixe /11.
Après vérification cela fonctionne et cela correspond bien à ce qui est expliqué dans la RFC7597.
Pour obtenir l'adresse IPv6 source du tunnel il suffit (!) de concaténer les 64 bits du préfixe IPv6 /60, suivis de 16 bits à zéro, puis les 32 bits de l'adresse IPv4 partagée, puis les 2 bits du PSID (bits 59 et 60 du préfixe IPv6 /60).
Le PSID, donc de 0 à 3 puisque sur deux bits dans cette configuration de mapping, indique la plage de ports allouée :
PSID = 00 -> ports 0 à 16383
PSID = 01 -> ports 16384 à 32767
PSID = 10 -> ports 32768 à 49151
PSID = 11 -> ports 49152 à 65535
L'adresse destination du tunnel (BR, border router) se trouve également dans la réponse DHCPv6 lorsqu'on demande l'option S46 MAP-E container.
Sinon je n'ai toujours pas d'explication à la présence d'un préfixe IPV6 en /80 présenté par NDP ainsi que l'adresse IPv6 incluse dans ce préfixe, obtenue en DHCPv6. Sert-elle pour la configuration de la Freebox (accès distant Freebox OS) ?
Pour l'adresse IPv4 fullstack, comment l'obtenir en dynamique ? J'avais réalisé une capture entre l'ONT et la freebox, mais en mode bridge. Il faudrait peut être faire une capture en mode routeur pour voir ce qu'il se passe au niveau de l'attribution de cette adresse IPv4.
Des infos sur le sujet, pour MAP-T, qui est proche de MAP-E :
https://github.com/openwrt/openwrt/blob/openwrt-22.03/package/network/ipv6/map/src/mapcalc.c
https://nicmx.github.io/Jool/en/map-t.html
https://github.com/ejordangottlieb/pyswmap
Ici également :
https://www.juniper.net/documentation/us/en/software/junos/interfaces-next-gen-services/topics/topic-map/usf-map-tm.html
https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-9/configuration/guide/b-cgnat-cg-asr9k-79x/cgipv6-without-service-modules.html#id_114607
Rien de plus simple le MAP-E ! :)
Ci-dessous la règle de mapping chez Free pour le MAP-E en IPv4 partagée (adresse IPv6 non réelle) :
-
Vivement la mort d'IPv4. Cette cohabitation ne simplifie pas les choses. Mais bon, on en a pour un paquet d'années encore.
Je suis en full stack, je viens de le dire, je n'aime pas la cohabitation. :)
Mais comment fais-tu pour chopper les trames entre la freebox et l'ONU?
-
Quand tu vois certains acteurs relativement gros qui ne sont encore accessibles qu'en IPv4 on n'est pas prêts...
-
Vivement la mort d'IPv4. Cette cohabitation ne simplifie pas les choses. Mais bon, on en a pour un paquet d'années encore.
Je suis en full stack, je viens de le dire, je n'aime pas la cohabitation. :)
Mais comment fais-tu pour chopper les trames entre la freebox et l'ONU?
Il faut un routeur ou un switch avec deux ports SFP, et deux câbles DAC, tout simplement, puis renvoyer les paquets vers un Wireshark, en mirroring, ou plus simple avec le streaming du packet sniffer Mikrotik, puis filtrage de capture sur UDP 37008 dans Wireshark. On peut aussi utiliser deux switchs ou deux routeurs avec un seul port SFP, et faire un lien cuivre RJ45 entre les deux. Évidemment il ne faut pas filtrer, tout doit pouvoir passer dans le bridge y compris les VLANs. C'est cette dernière solution que j'ai utilisée pour éviter d'acheter un switch ou routeur multi SFP. Attention à la compatibilité SFP, j'ai essayé avec des switchs d'il y a une dizaine d'années, cela ne fonctionne pas. Il faut du matériel récent.
Sinon, il peut être intéressant d'avoir les deux IPv4 pour des expérimentations.
Pour la mort d'IPv4 ce n'est pas encore pour aujourd'hui. Regardez par exemple les sites de certaines des plus grosses sociétés françaises ou institutions qui sont toujours en IPv4 seul.
Exemples :
https://www.edf.fr/
https://particuliers.engie.fr/
https://www.laposte.fr/
https://www.francetravail.fr
https://www.gouvernement.fr/
https://www.service-public.fr/
;)
Pour vérifier cela d'un seul coup d'oeil, un plugin sympa sous Firefox : SixOrNot
Voir ici le baromètre :) de l'ARCEP (Autorité (??) de régulation des communications électroniques, des postes et de la distribution de la presse) :
https://www.arcep.fr/fileadmin/cru-1677573101/reprise/observatoire/ipv6/202303_arcep_barometre_ipv6_2-02_synthese.svg
-
Pour résumer, pour l'adresse IPv4 partagée, voici le mécanisme qui permet de déterminer les paramètres du tunnel IPv4 sur IPv6. Ce mécanisme fait parti de la norme appelée MAP-E (Mapping of Address and Port with Encapsulation). L'établissement du tunnel nécessite seulement trois adresses, mais leur détermination est pour le moins alambiquée, pour deux d'entre elles.
Les adresses nécessaires à l'établissement du tunnel :
1) adresse IPv6 source du tunnel (forgée)
2) adresse IPv6 destination du tunnel (délivrée directement par l'option DHCPv6 S46)
3) adresse IPv4 partagée (forgée)
Les informations qui permettent de déterminer ces adresses :
- le préfixe IPv6 en /60 du client distribué par DHCPv6
Tout le reste est récupéré depuis l'option S46 MAP-E container, incluse dans la réponse DHCPv6. Les valeurs suivantes définissent ensemble la règle de mappage MAP-E :
- nombre du nombre de bits EA (embedded address), cette valeur servira à forger l'IPv4 partagée et définir le mappage de ports. Elle est égale à 23.
- préfixe IPv4 et sa longueur, qui servira aussi à forger l'adresse IPv4 partagée. Le préfixe est égal à 88.160.0.0/11
- longueur de préfixe IPv6 MAP-E, cette valeur servira à forger l'IPV4 partagée. Elle est égale à 37.
- paramètres de mappage de ports, permet de définir la plage de ports utilisée pour l'adresse IPv4 partagée. Dans le cas de Free, le mappage est simple, 2 bits sont utilisés pour définir une plage de ports parmi 4, les deux derniers bits des bits EA. Les 21 premiers bits de EA sont donc le suffixe de l'IPv4 partagée.
- adresse destination du tunnel MAP-E (adresse de border router ou BR)
Voilà comment construire les paramètres. Il faut déjà construire l'adresse IPv4 partagée :
1) prendre les 11 bits du préfixe IPv4. Il servent de préfixe pour le forgeage de l'IPv4.
2) pour le suffixe de l'IPv4 :
- prendre la valeur de longueur EA, et soustraire les deux bits utilisés pour la définition de mappage de ports, soit 23 - 2 = 21
- 11 + 21 = 32, on a bien les 32 bits d'une adresse IPv4.
3) la longueur de préfixe IPv6 MAP-E étant 37, les 21 bits 38 à 58 du préfixe IPv6 /60 vont représenter le suffixe de l'IPv4.
On a donc obtenu l'IPv4 partagée. Les bits 59 et 60 du préfixe IPv6 /60 définissent la plage de port allouée :
00 -> ports 0 à 16383
01 -> ports 16384 à 32767
10 -> ports 32768 à 49151
11 -> ports 49152 à 65535
Reste à définir l'IPv6 source, qui est également forgée :
1) prendre les 60 bits du préfixe IPv6 /60 et y ajouter 4 bits à 0 (pour obtenir le premier sous réseau /64)
2) le suffixe de l'IPv6 source sera égal à :
- 16 bits à zéro
- puis les 32 bits de l'adresse IPv4 partagée
- puis 14 bits à 0
- puis les deux bits du mappage de ports
Voilà on a maintenant l'adresse IPv6 source du tunnel.
Reste à récupérer l'adresse de border router BR, c'est à dire l'adresse IPv6 destination du tunnel. Elle est simplement incluse à la fin de l'option S46 dans la réponse DHCPv6.
L'option S46 MAP-E container, incluse dans la réponse DHCPv6 :
S46 MAP-E Container
Option: S46 MAP-E Container (94)
Length: 45
S46 Rule
Option: S46 Rule (89)
Length: 21
Flags: 0x80, Reserved
1000 000. = Reserved: True
.... ...0 = Forwarding Mapping Rule: False
EA-bit length: 23
IPv4 prefix length: 11
IPv4 prefix: 88.160.0.0
IPv6 prefix length: 37
IPv6 prefix: 2a01:e0a:800::
S46 Port Parameters
Option: S46 Port Parameters (93)
Length: 4
Offset: 0
PSID length: 0
PSID: 0
S46 BR
Option: S46 BR (90)
Length: 16
BR address: 2a01:e00:29:200a::fff9
Pour l'IPv4 Full Stack, c'est également un tunnel MAP-E, mais plus simple parce que utilisant le même suffixe pour l'IPv6 source quelque soit le client, et un mappage de ports 1/1. L'utilisation d'un suffixe d'IPv6 source différent pour chaque client n'est d'ailleurs pas requise par la norme. C'est simplement une aide au diagnostique en cas de problème.
Reste à voir comment cette adresse IPv4 Full Stack est calculée et provisionnée.
Ci-dessous pour mieux visualiser, la règle de mappage MAP-E pour l'adresse IPv4 partagée :
-
Bon, je n'ai pas trouvé comment récupérer via la voie académique l'IP V4, mais voici un contournement.
Il faut au préalable créer l'Entrée DNS personnalisée sur le portail free. Enregistrez votre entrée xxxxxx.hd.free.fr
Ajoutez le commentaire ipv4-free sur l'adresse internet IPv4.
J'ai ajouté à mon script au niveau du client DHCP IPv6, les lignes suivantes :
:local CustomDNSFree "xxxxxx.hd.free.fr"
:global ipv4free [:resolve $CustomDNSFree]
/ip address set [find comment="ipv4-free"] address=$ipv4free network=$ipv4free interface=$ipipv6
Certains trouveront ça inutile, mais je voulais une configuration full dynamique.
-
Bon, je n'ai pas trouvé comment récupérer via la voie académique l'IP V4, mais voici un contournement.
Il faut au préalable créer l'Entrée DNS personnalisée sur le portail free. Enregistrez votre entrée xxxxxx.hd.free.fr
Ajoutez le commentaire ipv4-free sur l'adresse internet IPv4.
J'ai ajouté à mon script au niveau du client DHCP IPv6, les lignes suivantes :
:local CustomDNSFree "xxxxxx.hd.free.fr"
:global ipv4free [:resolve $CustomDNSFree]
/ip address set [find comment="ipv4-free"] address=$ipv4free network=$ipv4free interface=$ipipv6
Certains trouveront ça inutile, mais je voulais une configuration full dynamique.
Bonne idée. Il manque peut être une ligne pour ajouter la route par défaut ?
Egalement que se passe-t-il avec ce script si l'adresse IP change ?
-
logiquement si ip change, l'enregistrement de l'entrée dans la zone de free doit changer puisque tu ne choisis pas l'IP lorsque tu le crées. C'est je pense, du dynamique DNS.
Pour ce qui est du reste, je me suis fait un script unique qui s'exécute au démarrage du routeur. Je pense qu'il fait toute la conf excepté le FW.
#Modify the interface name where you connect your ONU & the name on CustomDNSFree
:local interfacePhysical "sfp1"
:local CustomDNSFree "xxxxx.hd.free.fr"
:local MACFree "FF:CC:EA:4A:2B:39"
:local interfaceInternet "vlan836-free"
#optional
:local interfaceGuest "vlan-guest"
:local ipipv6 "ipipv6-free"
:local ipv4Free "ipv4-free"
delay 10s
#add interface list WAN
:if ([/interface list print count-only where name="WAN"]=0) do={
/interface list add name=WAN
}
#Cleanup list member orphans
/interface list member remove [find where interface~"^\\*[0-9a-fA-F]{1,8}\$"]
#add vlan 836
:if ([/interface print count-only where name=$interfaceInternet]=0) do={
/interface ethernet set $interfacePhysical l2mtu=1796 mtu=1704 mac-address=$MACFree
/interface vlan add name=$interfaceInternet vlan-id=836 mtu=1700 interface=sfp1
/interface list member add interface=$interfaceInternet list=WAN
}
#add ipv6 address for ipipv6 tunnel
:if ([/ipv6 address print count-only where comment="interfaceInternet2"]=0) do={
/ipv6 address add address="fd99::0ffff/128" interface="$interfaceInternet" advertise=no comment="interfaceInternet2"
}
#add ipv6 address for nat (if used)
:if ([/ipv6 address print count-only where comment="interfaceInternet"]=0) do={
/ipv6 address add address="2000::1111/128" interface="$interfaceInternet" advertise=no comment="interfaceInternet"
}
#add ipv6 prefix for Guest (optional)
:if ([/ipv6 address print count-only where comment="interfaceGuest"]=0) do={
/ipv6 address add address="fd99::/64" interface="$interfaceGuest" advertise=yes comment="interfaceGuest"
}
#add FW rule
#:if ([/ipv6 firewall filter print count-only where comment="Allow IPIPv6 tunnel on WAN"]=0) do={
# /ipv6 firewall filter add action=accept chain=input comment="Allow IPIPv6 tunnel on WAN" in-interface-list=WAN protocol=ipencap place-before=0
#}
#:if ([/ipv6 firewall filter print count-only where comment="Allow dhcpv6 replies on WAN"]=0) do={
# /ipv6 firewall filter add action=accept chain=input comment="Allow dhcpv6 replies on WAN" dst-port=546 \
# in-interface-list=WAN log=yes log-prefix="fw, a: allow6, r: aid, " protocol=udp \
# src-address=fe80::/10 place-before=0
#}
#add ipv6 DHCP Client
:if ([/ipv6 dhcp-client print count-only where comment="fibre-free"]=0) do={
/ipv6 dhcp-client
add comment="fibre-free" interface=$interfaceInternet pool-name="pool-freeV6" pool-prefix-length=60 request=address,prefix script="#Modify the \
CustomDNSFree\r\
\n:local CustomDNSFree \"$CustomDNSFree\"\r\
\n\r\
\n:local interfaceInternet \"$interfaceInternet\"\r\
\n:local interfaceGuest \"$interfaceGuest\"\r\
\n:local ipipv6 \"$ipipv6\"\r\
\n\r\
\n:local prefix [/ipv6 dhcp-client get [find interface=\$interfaceInternet] value-name=prefix]\r\
\n:set prefix ([:pick \$prefix 0 ([:find \$prefix \",\"]-3)])\r\
\n:local gw [/ipv6 dhcp-client get [find interface=\$interfaceInternet] value-name=address]\r\
\n:set gw ([:pick \$gw 0 ([:find \$gw \",\"])])\r\
\n:local addresse0ffff (([:pick \$prefix 0 ( [ :len \$prefix ] -1 )]) . \"0:ffff:ffff:0\")\r\
\n:local prefix2 (([:pick \$prefix 0 ( [ :len \$prefix ] -3 )]) . \"2::\")\r\
\n\r\
\n#remove the uggly IP\r\
\n/ipv6 address remove [find address=\"\$gw/128\"]\r\
\n#set ipv6 for forwarding ipipv6 tunnel\r\
\n/ipv6 address set [find comment=\"interfaceInternet2\"] address=\"\$addresse0ffff/128\" interface=\"\$interfaceInternet\" adver\
tise=no\r\
\n#set ip to the ipipv6 tunnel\r\
\n/interface ipipv6 set \$ipipv6 local-address=\$addresse0ffff\r\
\n#set 1st IP from prefix (if NAT used)\r\
\n/ipv6 address set [find comment=\"interfaceInternet\"] address=\"\$prefix/128\" interface=\"\$interfaceInternet\" advertise=no\
\r\
\n#set 2nd prefix on Guest VLAN (if used)\r\
\n /ipv6 address set [find comment=\"interfaceGuest\"] address=\"\$prefix2/64\" interface=\"\$interfaceGuest\" advertise=yes\r\
\n#set IPV4 Free\r\
\n:global ipv4free [:resolve \$CustomDNSFree]\r\
\n/ip address set [find comment=\"ipv4-free\"] address=\$ipv4free network=\$ipv4free interface=\$ipipv6\r\
\n" use-interface-duid=yes use-peer-dns=no
} else {
/ipv6 dhcp-client set [find comment="fibre-free"] interface=$interfaceInternet
}
#add ipipV6 tunnel
:if ([/interface print count-only where name=$ipipv6]=0) do={
/interface ipipv6 add name=$ipipv6 remote-address=2a01:e00:29:200a::fffd local-address=fe80::1234 mtu=1500
/interface list member add interface=$ipipv6 list=WAN
}
#add ipv4 on ipipv6 interface
:if ([/ip address print count-only where comment=$ipv4Free]=0) do={
/ip address add address=1.2.3.4 network=1.2.3.4 comment=$ipv4Free interface=$ipipv6
}
#add route ipv4 on ipipv6 interface
:if ([/ip route print count-only where comment=$ipipv6]=0) do={
/ip route add dst-address=0.0.0.0/0 gateway=$ipipv6 comment=$ipipv6
} else {
/ip route set [find comment=$ipipv6] gateway=$ipipv6
}
#
/ipv6 dhcp-client release [find comment="fibre-free"]
-
logiquement si ip change, l'enregistrement de l'entrée dans la zone de free doit changer puisque tu ne choisis pas l'IP lorsque tu le crées. C'est je pense, du dynamique DNS.
Oui bien sur, mais si l'IP change, l'ancienne adresse IPv4 précédemment mise en place par ce script reste en place ? Pour que ce soit réellement dynamique, l'ancienne adresse devrait être remplacée par une nouvelle, et non pas seulement ajouter une nouvelle adresse ?
-
Le script que j'ai partagé fait la conf et crée un script au niveau du client DHCP IPv6. La réactualisation de l'ipV4 se fera donc au renouvellement du bail de l'ipv6 ou du redémarrage du routeur. Rien n'empêche de le faire plus souvent via le scheduler.
Perso je ne le ferais pas, je pars du principe non vérifier que chez free nous sommes en IP fixe et que les changements ont plutôt été dû à des modifications techniques.
Si tu regardes le script il réactualise bien et ne recrée pas. La création n'a lieu qu'au démarrage du routeur et uniquement si l'enregistrement n'existe pas.
Il n'y a que les règles de FW que je n'ai pas pu créer de la sorte en vérifiant auparavant leur existence. Je n'ai pas trouvé encore comment faire.
-
voici pour ceux que ça intéresserait le script qui fait la config de bout en bout
Il est à lancer avec le scheduler au boot.
3 variables à modifier, le nom de l'interface physique du mikrotik utilisé pour connecter l'ONU, l'enregistrement de l'entrée DNS personnalisée sur le portail de Free et l'adresse MAC de votre Freebox. Ca fonctionne pour moi, je suis curieux de vérifier la portabilité.
#Modify the interface name where you connect your ONU & the name on CustomDNSFree
:local interfacePhysical "sfp1"
:local CustomDNSFree "xxxxx.hd.free.fr"
:local MACFree "FF:CC:EE:4B:2B:3A"
:local interfaceInternet "vlan836-free"
:local ipipv6 "ipipv6-free"
:local ipv4Free "ipv4-free"
delay 10s
#add interface list WAN
:if ([/interface list print count-only where name="WAN"]=0) do={
/interface list add name=WAN
}
#Cleanup list member orphans
/interface list member remove [find where interface~"^\\*[0-9a-fA-F]{1,8}\$"]
#add vlan 836
:if ([/interface print count-only where name=$interfaceInternet]=0) do={
/interface ethernet set $interfacePhysical l2mtu=1796 mtu=1704 mac-address=$MACFree
/interface vlan add name=$interfaceInternet vlan-id=836 mtu=1700 interface=$interfacePhysical
/interface list member add interface=$interfaceInternet list=WAN
}
#add ipv6 address for ipipv6 tunnel
:if ([/ipv6 address print count-only where comment="interfaceInternet2"]=0) do={
/ipv6 address add address="fd99::0ffff/128" interface="$interfaceInternet" advertise=no comment="interfaceInternet2"
}
#add FW rule
:if ([ :len [/ipv6/firewall/filter/find where comment="Allow IPIPv6 tunnel on WAN" ]] = 0) do={
/ipv6 firewall filter add action=accept chain=input comment="Allow IPIPv6 tunnel on WAN" in-interface-list=WAN \
protocol=ipencap place-before=*0
}
:if ([ :len [/ipv6/firewall/filter/find where comment="Allow dhcpv6 replies on WAN" ]] = 0) do={
/ipv6 firewall filter add action=accept chain=input comment="Allow dhcpv6 replies on WAN" dst-port=546 \
in-interface-list=WAN log=yes log-prefix="fw, a: allow6, r: aid, " protocol=udp src-address=fe80::/10 place-before=*0
}
#add ipv6 DHCP Client
:if ([/ipv6 dhcp-client print count-only where comment="fibre-free"]=0) do={
/ipv6 dhcp-client
add add-default-route=yes comment="fibre-free" interface=$interfaceInternet pool-name="pool-freeV6" pool-prefix-length=60 request=address,prefix script="#Modify the \
CustomDNSFree\r\
\n:local CustomDNSFree \"$CustomDNSFree\"\r\
\n\r\
\n:local interfaceInternet \"$interfaceInternet\"\r\
\n:local ipipv6 \"$ipipv6\"\r\
\n\r\
\n:local prefix [/ipv6 dhcp-client get [find interface=\$interfaceInternet] value-name=prefix]\r\
\n:set prefix ([:pick \$prefix 0 ([:find \$prefix \",\"]-3)])\r\
\n:local gw [/ipv6 dhcp-client get [find interface=\$interfaceInternet] value-name=address]\r\
\n:set gw ([:pick \$gw 0 ([:find \$gw \",\"])])\r\
\n:local addresse0ffff (([:pick \$prefix 0 ( [ :len \$prefix ] -1 )]) . \"0:ffff:ffff:0\")\r\
\n:local prefix2 (([:pick \$prefix 0 ( [ :len \$prefix ] -3 )]) . \"2::\")\r\
\n\r\
\n#remove the uggly IP\r\
\n/ipv6 address remove [find address=\"\$gw/128\"]\r\
\n#set ipv6 for forwarding ipipv6 tunnel\r\
\n/ipv6 address set [find comment=\"interfaceInternet2\"] address=\"\$addresse0ffff/128\" interface=\"\$interfaceInternet\" adver\
tise=no\r\
\n#set ip to the ipipv6 tunnel\r\
\n/interface ipipv6 set \$ipipv6 local-address=\$addresse0ffff\r\
\n#set IPV4 Free\r\
\n:local ipv4free [:resolve \$CustomDNSFree]\r\
\n/ip address set [find comment=\"ipv4-free\"] address=\$ipv4free network=\$ipv4free interface=\$ipipv6\r\
\n" use-interface-duid=yes use-peer-dns=no
} else {
/ipv6 dhcp-client set [find comment="fibre-free"] interface=$interfaceInternet
}
#add ipipV6 tunnel
:if ([/interface print count-only where name=$ipipv6]=0) do={
/interface ipipv6 add name=$ipipv6 remote-address=2a01:e00:29:200a::fffd local-address=fe80::1234 mtu=1500
/interface list member add interface=$ipipv6 list=WAN
}
#add ipv4 on ipipv6 interface
:if ([/ip address print count-only where comment=$ipv4Free]=0) do={
/ip address add address=1.2.3.4 network=1.2.3.4 comment=$ipv4Free interface=$ipipv6
}
#add route ipv4 on ipipv6 interface
:if ([/ip route print count-only where comment=$ipipv6]=0) do={
/ip route add dst-address=0.0.0.0/0 gateway=$ipipv6 comment=$ipipv6
} else {
/ip route set [find comment=$ipipv6] gateway=$ipipv6
}
#
/ipv6 dhcp-client release [find comment="fibre-free"]
-
Salut hsd;
Je te confirme ton script fonctionne à merveille, testé et approuvé !
Merci pour ta contribution !