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

0 Membres et 1 Invité sur ce sujet

Covenant31

  • Abonné Orange Fibre
  • *
  • Messages: 16
  • Launaguet (31)
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #324 le: 24 janvier 2023 à 20:27:38 »
Il y a 2 fois "pedit pedit" sur TA ligne 2, c'est normal ?

Je suis parti d'un exemple de la manpage de pedit: https://man7.org/linux/man-pages/man8/tc-pedit.8.html
Mais ça fonctionne aussi avec un seul, c'est pareil.



Pour résumer:

Nos lignes 1 sont identiques.

Nos lignes 2 match les paquets DHCPv4, mais la mienne est plus drastique dans la sélection.
Justement il faut lire "ET" entre chaque critère. Je vérifie bien que le paquet n'a pas d'option (en-tête de 20 octets donc) ET n'est pas fragmenté (ou du moins est le 1er fragment).
Si tu ne vérifie pas ça, à l'offset 20 ("ip sport" et "ip dport") il y aura bien quelque chose, mais potentiellement pas des numéros de port.
Normalement avec des paquets DHCPv4 ça n'arrivera jamais, mais je préfère être strict.
D'ailleurs tu as oublié de vérifier le port source aussi.
Puis ma ligne 1 modifie en plus le DSCP et finalement corrige le checksum IPv4 rendu invalide par la modification du DSCP.

Ta ligne 3 match les paquets DHCPv6 et ne change que la priority, pas le DSCP.
Pour être plus rigoureux il faudrait ajouter le check du port source.
Par contre attention en IPv6, "ip6 protocol" ignore les cas où tu as un header intermédiaire, tel qu'un fragmentation header par exemple.
Bon ok pour du DHCPv6 ça ne devrait pas arriver, mais c'est bon à savoir.

Ta ligne 4 match les paquets ICMPv6 et ne change que la priority, pas le DSCP.
Attention tu match tous les paquets ICMPv6, pas que les NS/NA/RS et aussi ceux qui partent vers Internet au delà du BNG.
Même remarque aussi pour "ip6 procotol".

Mon script tc ne s'occupe pas du tout de IPv6, puisque normalement aucun programme ne devrait utiliser de raw socket pour ce protocole.
Je passe par des règles nftables exclusivement:

NET = eth1.832

table inet firewall {
chain prio_orange {
meta nfproto ipv4 \
meta priority set 0:0 \
ip dscp set cs0

meta nfproto ipv6 \
meta priority set 0:0 \
ip6 dscp set cs0
ip6 daddr { fe80::/10, ff02::/16 } \
icmpv6 type {
nd-router-solicit,
nd-neighbor-solicit,
nd-neighbor-advert
} \
meta priority set 0:6 \
ip6 dscp set cs6
ip6 daddr { fe80::/10, ff02::/16 } \
udp sport 546 \
udp dport 547 \
meta priority set 0:6 \
ip6 dscp set cs6
}

chain mangle_postrouting {
type filter hook postrouting priority mangle
policy accept

oifname $NET \
rt ipsec missing \
jump prio_orange
}
}

Enfin ceci dit busybox udhcpc6 utilise des raw socket pour DHCPv6, mais c'est du n'importe quoi, ça fait partie des aspects que je corrige avec mes patchs.

cyayon

  • Abonné Orange Fibre
  • *
  • Messages: 648
  • Cordon 74 - Orange Fibre Pro
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #325 le: 24 janvier 2023 à 20:36:31 »
Merci pour tes explications !

levieuxatorange

  • Expert Orange
  • Expert
  • *
  • Messages: 173
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #326 le: 25 janvier 2023 à 09:08:19 »
Question peut-être un peu bête : est-ce que par cohérence DHCPv4/v6 vous entendez également une cohérence des adresses MAC ? Je précise...

Mon switch n'est pas capable de marquer en CoS 6 en IPv4 et IPv6 sur le même port, c'est l'un ou l'autre...

Aie !

Dans un BNG, le contexte client est unique. On essaie de le lier plutôt à un indicateur indépendant des MAC.
Mais là on est dépendant de l'implémentation fournisseur et honnêtement, je le sens pas trop la MAC différente en IPv4 et en IPv6 dans un même contexte de ligne.
Cela peut marcher, ou pas, ou changer sans prévenir n'importe quand ...

LeVieux
« Modifié: 25 janvier 2023 à 15:24:08 par levieuxatorange »

simon

  • Abonné Orange Fibre
  • *
  • Messages: 935
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #327 le: 25 janvier 2023 à 10:09:46 »
LeVieux, sais-tu par hasard si on peut conserver le même préfixe IPv6 si on déménage à l'intérieur d'une zone couverte par le même BNG ? Si un abonné déménage dans la même ville, par exemple ?

Zeda

  • Abonné OVH
  • *
  • Messages: 150
  • Toulouse (31)
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #328 le: 25 janvier 2023 à 10:38:06 »
Aie !

Dans un BNG, le contexte client est unique. On essaie de le lié plutôt à un indicateur indépendant des MAC.
Mais là on est dépendant de l'implémentation fournisseur et honnêtement, je le sens pas trop la MAC différente en IPv4 et en IPv6 dans un même contexte de ligne.
Cela peut marcher, ou pas, ou changer sans prévenir n'importe quand ...

LeVieux

Merci bien pour la réponse !  :)

levieuxatorange

  • Expert Orange
  • Expert
  • *
  • Messages: 173
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #329 le: 25 janvier 2023 à 11:17:05 »
LeVieux, sais-tu par hasard si on peut conserver le même préfixe IPv6 si on déménage à l'intérieur d'une zone couverte par le même BNG ? Si un abonné déménage dans la même ville, par exemple ?
Hello

Non, celui là c'est un des cas ou on change de préfix (et d'IPv4). Comme tout changement réseau en fait.

LeVieux

cyayon

  • Abonné Orange Fibre
  • *
  • Messages: 648
  • Cordon 74 - Orange Fibre Pro
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #330 le: 25 janvier 2023 à 11:35:29 »
Je suis parti d'un exemple de la manpage de pedit: https://man7.org/linux/man-pages/man8/tc-pedit.8.html
Mais ça fonctionne aussi avec un seul, c'est pareil.



Pour résumer:

Nos lignes 1 sont identiques.

Nos lignes 2 match les paquets DHCPv4, mais la mienne est plus drastique dans la sélection.
Justement il faut lire "ET" entre chaque critère. Je vérifie bien que le paquet n'a pas d'option (en-tête de 20 octets donc) ET n'est pas fragmenté (ou du moins est le 1er fragment).
Si tu ne vérifie pas ça, à l'offset 20 ("ip sport" et "ip dport") il y aura bien quelque chose, mais potentiellement pas des numéros de port.
Normalement avec des paquets DHCPv4 ça n'arrivera jamais, mais je préfère être strict.
D'ailleurs tu as oublié de vérifier le port source aussi.
Puis ma ligne 1 modifie en plus le DSCP et finalement corrige le checksum IPv4 rendu invalide par la modification du DSCP.

Ta ligne 3 match les paquets DHCPv6 et ne change que la priority, pas le DSCP.
Pour être plus rigoureux il faudrait ajouter le check du port source.
Par contre attention en IPv6, "ip6 protocol" ignore les cas où tu as un header intermédiaire, tel qu'un fragmentation header par exemple.
Bon ok pour du DHCPv6 ça ne devrait pas arriver, mais c'est bon à savoir.

Ta ligne 4 match les paquets ICMPv6 et ne change que la priority, pas le DSCP.
Attention tu match tous les paquets ICMPv6, pas que les NS/NA/RS et aussi ceux qui partent vers Internet au delà du BNG.
Même remarque aussi pour "ip6 procotol".

Mon script tc ne s'occupe pas du tout de IPv6, puisque normalement aucun programme ne devrait utiliser de raw socket pour ce protocole.
Je passe par des règles nftables exclusivement:

NET = eth1.832

table inet firewall {
chain prio_orange {
meta nfproto ipv4 \
meta priority set 0:0 \
ip dscp set cs0

meta nfproto ipv6 \
meta priority set 0:0 \
ip6 dscp set cs0
ip6 daddr { fe80::/10, ff02::/16 } \
icmpv6 type {
nd-router-solicit,
nd-neighbor-solicit,
nd-neighbor-advert
} \
meta priority set 0:6 \
ip6 dscp set cs6
ip6 daddr { fe80::/10, ff02::/16 } \
udp sport 546 \
udp dport 547 \
meta priority set 0:6 \
ip6 dscp set cs6
}

chain mangle_postrouting {
type filter hook postrouting priority mangle
policy accept

oifname $NET \
rt ipsec missing \
jump prio_orange
}
}

Enfin ceci dit busybox udhcpc6 utilise des raw socket pour DHCPv6, mais c'est du n'importe quoi, ça fait partie des aspects que je corrige avec mes patchs.

Re,

Je cherche à me passer de passer par nftables pour utiliser uniquement tc.
Que penses-tu de ces rêlges :

1: tc filter add dev ${iface} parent 1: prio 1  protocol arp u32 match u8 0 0 action skbedit priority 0:6
2: tc 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
3a: tc filter add dev $iface parent 1: prio 3 protocol ipv6 u32 match ip6 protocol 17 0xff match ip6 sport 546 0xffff match ip6 dport 547 0xffff action skbedit priority 0:6 # dhcpv6 no DSCP
3b: tc filter add dev $iface parent 1: prio 3 protocol ipv6 u32 match ip6 protocol 17 0xff match ip6 sport 546 0xffff match ip6 dport 547 0xffff action skbedit priority 0:6 pipe action pedit pedit munge ip6 tos set 0xc0 retain 0xfc # dhcpv6 DSCP

la ligne 3a est plus précise que la mienne (je checl le sport et dport).
la ligne 3b, j'essaie de changer le DSCP en plus, mais je ne suis vraiment pas certain...
bien sûr c'est la ligne 3a OU 3b (pas les 2).

Enfin, pour la dernière ligne, je souhaitrais modifier les paquets icmpv6 NS/NA/RS, mais je ne sais pas si c'est possible avec tc. Une idée ?

merci

Covenant31

  • Abonné Orange Fibre
  • *
  • Messages: 16
  • Launaguet (31)
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #331 le: 25 janvier 2023 à 18:14:22 »
En IPv6 l'action pour patcher le DSCP est un peu différente.

Tu devrais pouvoir t'en tirer avec le script suivant:

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

# ARP
filter add dev ${iface} \
parent 1: \
prio 1 \
protocol arp \
u32 \
match u8 0 0 \
action skbedit priority 0:6

# DHCPv4
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 munge ip tos set 0xc0 retain 0xfc pipe \
action csum ip4h

# DHCPv6
filter add dev ${iface} \
parent 1: \
prio 3 \
protocol ipv6 \
u32 \
match ip6 dst fe00::/7 \
match ip6 protocol 17 0xff \
match ip6 sport 546 0xffff \
match ip6 dport 547 0xffff \
action skbedit priority 0:6 pipe \
action pedit ex munge ip6 traffic_class set 0xc0 retain 0xfc

# ICMPv6
filter add dev ${iface} \
parent 1: \
prio 4 \
protocol ipv6 \
u32 \
match ip6 dst fe00::/7 \
match ip6 protocol 58 0xff \
action skbedit priority 0:6 pipe \
action pedit ex munge ip6 traffic_class set 0xc0 retain 0xfc
EOF

À noter que j'ai triché un peu pour la destination IPv6 avec fe00::/7 qui regroupe à la fois fe80::/10 et ff02::/16.

Par contre un soucis pour l'ICMPv6 avec les types: https://en.wikipedia.org/wiki/ICMPv6#Types
Ceux qui nous intéressent ont les codes 133, 135 et 136. On ne peut pas matcher ça avec un seul masque...
Mais vu qu'on limite déjà la sélection uniquement aux paquets ICMPv6 à destination du lien local, ça ne devrait pas poser de problème.
Enfin si tu veux être vraiment précis tu peux modifier la dernière règle en ajoutant "match ip6 icmp_type 133 0xff" puis la dupliquer avec 135 et 136.

cyayon

  • Abonné Orange Fibre
  • *
  • Messages: 648
  • Cordon 74 - Orange Fibre Pro
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #332 le: 25 janvier 2023 à 21:40:29 »
Merci ! Je vais tester.
Pour l’icmpv6 si la destination qui est en fe00::/7, la source c’est bien fe80::/10 ? On pourrait rajouter ce critère non ?

Covenant31

  • Abonné Orange Fibre
  • *
  • Messages: 16
  • Launaguet (31)
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #333 le: 25 janvier 2023 à 22:07:35 »
Pas besoin et en plus tu exclus le cas de l'adresse source nulle :: utilisée pour le DAD (Duplicate Address Detection).

cyayon

  • Abonné Orange Fibre
  • *
  • Messages: 648
  • Cordon 74 - Orange Fibre Pro
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #334 le: 25 janvier 2023 à 22:32:26 »
Ok donc uniquement la destination. Merci !

lekr

  • Abonné MilkyWan
  • *
  • Messages: 59
Durcissement du contrôle de l’option 90/11 et de la conformité protocolaire
« Réponse #335 le: 26 janvier 2023 à 08:14:56 »
Hello LeVieux

est il possible de savoir si la zone d'Annemasse (74100) a été migrée ou pas encore ?
j'en ai l'impression, quand je regarde les options que recevait la livebox (avec livebox info) mais je voudrais en être sûr ;-)

merci d'avance