Auteur Sujet: Orange DHCP conformité protocolaire 2023 - lire depuis le début du sujet  (Lu 176540 fois)

0 Membres et 6 Invités sur ce sujet

ochbob

  • Abonné Orange Fibre
  • *
  • Messages: 231
  • Beauzelle (31)
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #240 le: 29 décembre 2022 à 11:18:58 »
Vous confirmez que Toulouse (ceux qui y sont) et ses environs n'ont pas encore migré par rapport à l'option 17 (ipv6) et 125 (ipv4) en retour ?
J'ai un truc étrange (je crois  ???, je ne suis pas expert réseau :( ), le canal retour c'est bien dans le 'ACK' en DHCPv4 et 'Reply' en DHCPv6 ?

Car j'ai l'impression que je ne reçois pas l'option 17 en retour en DHCPv6



Je devrais avoir une ligne Vendor-specific Information si je suis dans une zone migré, on est d'accord ?

Alors qu'en DHCPv4 ça me semble OK, j'ai bien le retour 125 avec une valeur identique à celle indiqué par LeVieux.



Vos avis ?

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 474
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #241 le: 29 décembre 2022 à 13:59:35 »
D'après ce que dit levieux en FP, l'option 125 est déjà présente sur le système actuel :

Citer
Attention, l'ancien système donne déjà certain code d'erreur, donc ce n'est pas un marqueur absolu
- en DHCPv6, si vous recevez une option 17, c'est que vous avez migré (même si le code retour (voir plus bas) est OK). Cette option 17 n'est PAS présente dans l'ancien système

Pour savoir si on a migré il faut donc se fier uniquement à l'option 17.


ochbob

  • Abonné Orange Fibre
  • *
  • Messages: 231
  • Beauzelle (31)
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #242 le: 29 décembre 2022 à 15:18:32 »
En effet, passé trop vite sur la FP, merci renaud ;D
Comportement normal du coup pour l'instant, on n'a pas encore migré par ici alors, j'imagine début 2023.

(Je ne suis pas le seul à avoir ce comportement)

obinou

  • AS197422 Tetaneutral.net
  • Expert
  • *
  • Messages: 1 670
  • Montgesty (46150)
    • Tetaneutral.net
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #243 le: 29 décembre 2022 à 17:01:01 »
@levieuxatorange

Merci beaucoup de ces explications cruciales et pérennes .

A titre personnel je ne partage pas ton engouement pour la Livebox, c'est un point tellement crucial qu'à titre personnel j'ai quitté orange en grande partie à cause d'elle (et c'est valable pour toute les versions).
Par contre il m'arrive de gérer des lignes pro livrés en FTTH par orange (je crois que l'offre est appelée "Just fibre") et du coup les techniciens orange installe ce matériel grand public - c'est précisément dans ce cas que les infos que tu donnes sont précieuses , pour pouvoir installer en frontal un routeur avec plus de fonctionnalités qu'une box grand public.

je garde sous le coude, même si l'implémentation sur des microtik (par exemple) promet d'être complexe, et même avec des implémentations opensource il faudra sans doute patcher. 

renaud07

  • Abonné Orange adsl
  • *
  • Messages: 3 474
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #244 le: 29 décembre 2022 à 18:29:45 »
A titre personnel je ne partage pas ton engouement pour la Livebox, c'est un point tellement crucial qu'à titre personnel j'ai quitté orange en grande partie à cause d'elle (et c'est valable pour toute les versions).

Idem. Perso, la livebox je penserais à m'en resservir quand elle aura :

-la possibilité de mettre des routes statiques
-une vraie délégation de préfixe
-le DHCP/DNS entièrement paramétrable
-la possibilité d'ajouter un préfixe ULA
-un firewall personnalisable en long en large et en travers

Oui je sais, je rêve.



Covenant31

  • Abonné Orange Fibre
  • *
  • Messages: 16
  • Launaguet (31)
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #245 le: 30 décembre 2022 à 01:19:54 »
Vous confirmez que Toulouse (ceux qui y sont) et ses environs n'ont pas encore migré par rapport à l'option 17 (ipv6) et 125 (ipv4) en retour ?

Je m'occupe de deux sites dans les environs de Toulouse, tous les deux en contrat Sosh et je confirme qu'aucun des deux n'a été migré (pas d'option 17 en retour en DHCPv6, la chaîne d'auth sans le mot de passe fonctionne encore, etc...)


Je profite justement des vacances pour mettre les choses "au carré" et éviter de perdre la connexion.

Conformément aux recommandations de LeVieux, en plus des options adéquates dans les clients DHCPv4/DHCPv6, j'ai implémenté un mécanisme de vérification de lien montant en utilisant les outils arping pour IPv4 et ndisc6 pour IPv6.

Cependant, j'ai pu constater qu'en cas de saturation de débit, certaines vérifications IPv4 échouaient mais pas celles en IPv6.
J'avais bien pensé à tagger les paquets ARP et NS émis en COS6, via netfilter.
Cependant, arping utilise des raw sockets, donc même problème qu'avec dhclient en IPv4, pas de netfilter possible.

J'ai donc changé de méthode pour passer par une solution basée sur un script tc qui tagge tous les paquets ARP, qu'ils soient émis par le kernel ou arping.
Depuis, tous les tests IPv4 et IPv6 passent sans problème, quelque soit l'état de saturation de la ligne.

Tout ça pour confirmer que, même si vous êtes dans une zone où "ça marche sans", il vaut mieux vraiment appliquer la COS6.


Par ailleurs, pour le DHCPv4, j'ai trouvé un moyen de modifier aussi le DSCP via tc.
Je sais que ce qui importe le plus, c'est la COS6, mais d'après LeVieux c'est mieux si le DSCP est en phase avec la COS.
De plus, la LB le fait, donc moi aussi.

Je ne crois pas avoir vu cette astuce ailleurs, donc je la poste ici, si ça peut servir...

tc -b - <<EOF
qdisc replace dev ${iface} \
root \
handle 1: \
prio
filter del dev ${iface}

# ARP packets emitted by kernel can be modified by netfilter but not those
# emitted by arping as it uses raw socket
filter add dev ${iface} \
parent 1: \
prio 1 \
protocol arp \
u32 \
match u8 0 0 \
action skbedit priority 0:6

# dhclient uses raw socket for DISCOVER/REQUEST
filter add dev ${iface} \
parent 1: \
prio 2 \
protocol ip \
u32 \
match ip ihl 5 0xf \
match u16 0x0000 0x1fff at 6 \
match ip protocol 17 0xff \
match ip sport 68 0xffff \
match ip dport 67 0xffff \
action skbedit priority 0:6 pipe \
action pedit pedit munge ip tos set 0xc0 retain 0xfc pipe \
action csum ip4h
EOF

(Attention, si vous êtes sur un kernel < 5.1, il faut enlever le "protocol ip" du 2ème filter)

Avec cette astuce, il est possible de modifier non seulement la priorité COS6, mais aussi la priorité IP DSCP de n'importe quel paquet, même ceux issus d'une raw socket, sans aucun patch, sans LD_PRELOAD, ni rien compiler.

Gnubyte

  • Abonné Orange Fibre
  • *
  • Messages: 1 070
  • Toulon (83)
    • HSGMII intégriste
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #246 le: 01 janvier 2023 à 21:33:32 »
Bon, tout fonctionne enfin chez moi.

Conformément aux précisions de @JcDenis confirmées par @Proap ici, il convient de reset la configuration et de surcharger l'adresse MAC du bridge WAN avant de s'en servir. Après, ça ne passe plus, et c'est en fait vraisemblablement prévu comme ça dans le RFC.

Sur Mikrotik RouterOS:
Citer
/interface bridge add name=bridge-WAN-ou-quel-que-soit-le-nom-du-votre admin-mac=XX:XX:XX:XX:XX:XX auto-mac=no

Remplacer, bien sûr par l'adresse MAC de la LB généreusement notée sur l'étiquette.

simon

  • Abonné Orange Fibre
  • *
  • Messages: 935
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #247 le: 02 janvier 2023 à 05:31:11 »
Bon, tout fonctionne enfin chez moi.
Nice! C'était juste un souci de DUID finalement ? À tout hasard, aurais tu une capture de ce qui était envoyé par le routeur lorsque tu n'arrivais pas à obtenir de préfixe ? Juste au cas où, pour vérifier que c'est bien la différence entre MAC et DUID qui empêchait l'obtention du bail.

Gnubyte

  • Abonné Orange Fibre
  • *
  • Messages: 1 070
  • Toulon (83)
    • HSGMII intégriste
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #248 le: 02 janvier 2023 à 08:24:28 »
Vaste question.
J'ai tellement scruté les logs qu'à un moment je n'arrivais même plus qu'à voir le seul trafic marqué "LOG" dans le journal...
Mes essais recoupent les conclusions de @propap stipulant la façon légitime de forger le DUID sur RouterOS.
Et il faut bien repartir d'une configuration vierge, sinon on en sort pas.

levieuxatorange

  • Expert Orange
  • Expert
  • *
  • Messages: 175
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #249 le: 02 janvier 2023 à 09:41:28 »
Oui je sais, je rêve.
Hello (et bonne année)

En fait on a cela chez Orange, cela s'appelle des offres Entreprises, y'a même des GTR 4h et tout ce qui va bien avec et même des débits garantis. Par contre c'est pas le même prix ...

Mais là on est sur un segment grand public et petit pro.
Et un petit pro (la cible c'est "maPetiteBoutiqueDesFleursDeLaPlage", pas le réseau d'agence d'une banque (et encore, je connais mal le segment cible des petits pro) ...) comme un GP n'a pas besoin de ce que tu mets là :)

Même si en tant que Geek, je comprends ton désir.

Moi, mon TAF (TeenAge Acceptance Factor) m'a clairement poussé à remettre une LB "qui marche dans tous les cas" plutot qu'un montage fait par moi même ...

LeVieux.

« Modifié: 02 janvier 2023 à 10:29:58 par levieuxatorange »

gecko

  • Abonné Orange Fibre
  • *
  • Messages: 79
  • St Sebastien sur Loire 44
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #250 le: 02 janvier 2023 à 14:27:45 »
Du coup merci beaucoup pour les infos @levieux et @gnubyte encore pour le support Mikrotik :)

Concernant la partie IPv6 qu'avez vous mis du coup comme option sur le dhcp-client.
J'ai lu ici il me semble qu'il fallait virer le rapid-commit et j'utilise duid interface (apres avoir forcé la MAC)

du coup j'ai ça sur mon dhcp-client en IPv6
/ipv6 dhcp-client
add add-default-route=yes dhcp-options=authsend,userclass,class-identifier dhcp-options=authsend,userclass,class-identifier interface=br-wan pool-name=pool_FT_6 rapid-commit=no \
    request=prefix use-interface-duid=yes

EDIT: j'obtiens bien mes IPv4 et IPv6
(J'ai changé d'IPv4 2 fois aujourd'hui du coup avec les release DHCP)

levieuxatorange

  • Expert Orange
  • Expert
  • *
  • Messages: 175
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #251 le: 02 janvier 2023 à 15:35:50 »
(J'ai changé d'IPv4 2 fois aujourd'hui du coup avec les release DHCP)
C'est que tu es encore sur l'ancien système qui change d'IP sur Release IPv4
Dans le nouveau, tu changes d'IPv4 en le demandant spécifiquement sur l'interface client (où si le réseau en a besoin c'est une affectation préférentielle)
On a découvert tout un monde de clients qui VEULENT changer d'IPv4 ...
Entre ceux qui font du download, ceux qui avec un mec simule 20 profils différents de femme sur des forums de rencontre et ceux qui voulaient éviter les problèmes de billets qui changeaient de prix (vers le haut) quand tu revenais trop vite, on a découvert un pan complet que l'on ne soupçonnait pas ...

LeVieux