Auteur Sujet: [Résolu] Renouvellement DHCP  (Lu 20751 fois)

0 Membres et 1 Invité sur ce sujet

xavierg

  • Abonné Orange Fibre
  • *
  • Messages: 96
[Résolu] Renouvellement DHCP
« le: 23 février 2017 à 17:47:35 »
Bonjour,

Tout d'abord, merci à tous les membres qui ont partagé les résultats de leurs expériences techniques avec le réseau Orange -- cela m'a beaucoup facilité la tâche. Particulièrement, je savais à quoi m'attendre avant même de mettre un wireshark en face de la LiveBox, laquelle a dû rester moins de 24h hors de son carton :')

Au cours de mes lectures, j'ai noté que la plupart des problématiques relatives à DHCP tournaient autour du VLAN 832, de la priorité 6 (avec sa digression sur le traitement des raw sockets par le kernel), des options DHCP (60, 61, 77, 90) et de leurs valeurs. Grâce à toutes ces discussions, je n'ai pas eu de mal à faire fonctionner un client DHCPv4 sur ma passerelle et à obtenir un bail DHCPv4 avec tout ce qu'il faut (adresse, subnet, route, etc.).

Toutefois, et à moins que je n'aie loupé les posts qui en parlent, toutes les discussions se concentrent sur l'obtention initiale du bail : DISCOVER, OFFER, REQUEST, ACK.

Mais quid du renouvellement de ce bail DHCPv4 ? Est-ce que le renewal et le rebinding se passent bien chez vous ? Chez moi, ça ne se passe hélas pas très bien. Explications :

J'utilise l'ISC DHCP Client 4.3.1 tel qu'on le trouve sur Debian Jessie et je contrôle ce qu'il fait en sniffant le réseau ; tous les paquets dont je parle sortent donc taggés avec le VLAN 832, la priorité 6 et les mêmes options DHCP.

Comme déjà indiqué, l'acquisition initiale du bail se déroule bien :
Feb 22 03:12:34 dhclient: DHCPDISCOVER on <nic> to 255.255.255.255 port 67 interval 8
Feb 22 03:12:34 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 03:12:34 dhclient: DHCPOFFER from <gateway IPv4 Orange>
Feb 22 03:12:34 dhclient: DHCPACK from <gateway IPv4 Orange>
Feb 22 03:12:34 dhclient: bound to <IPv4> -- renewal in 39060 seconds.

À noter toutefois que le bail ainsi obtenu comporte une bizarrerie : les paquets DHCPOFFER et DHCPACK venaient de la gateway Orange (rien de surprenant) mais le bail stipule :
  option dhcp-server-identifier 80.10.247.48;
C-à-d une IP en dehors du subnet attribué et qui ne répond pas aux pings. Bon, pourquoi pas...
Edit : après vérification, cette IP ne s'annonce pas non plus en ARP... ça promet...

Tout se passe bien jusqu'au moment du renewal, quand dhclient essaye, pour renouveler son bail, de contacter ce fameux serveur DHCP : aucune réponse en vue, que ce soit aux yeux de tcpdump ou aux yeux de dhclient :
Feb 22 14:03:34 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:03:39 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:03:46 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:04:04 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:04:22 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:04:43 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:04:51 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:05:03 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:05:18 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:05:29 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:05:38 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:05:51 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67

Et ça continue comme ça pendant des heures, jusqu'au "rebinding time", où dhclient cesse de chercher à contacter le serveur DHCP via son IPv4 et se met à broadcaster sa DHCPREQUEST :
Feb 22 22:26:02 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:26:18 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:26:30 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:26:44 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:27:00 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:27:09 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:27:18 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:27:33 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:27:50 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:28:04 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:28:25 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:28:44 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67

Et ça continue comme ça jusqu'à l'expiration du bail, qui pousse dhclient à èmettre un DHCPDISCOVER, lequel reçoit immédiatement une réponse de la gateway Orange, et la boucle peut ainsi recommencer.
Concrètement, ça n'est pas gênant : le bail est acquis aussitôt après son expiration, ce qui limite fortement les chances que l'IPv4 se voit attribuée à quelqu'un d'autre. Mais bon, èmettre une DHCPREQUEST dans le vide toutes les ~15 secondes pour rien, ça pollue les logs et c'est un peu gênant sur le concept...

Mes hypothèses pour le moment :
  Hypothèse 1 : le PEBKAC : j'ai loupé un épisode dans mes routes, mes règles de firewall, mes captures réseau, whatever... :)
  Hypothèse 2 : le dhcp-server-identifier est complètement faux et le problème se résoudrait avec un hook dhclient pour remplacer le dhcp-server-identifier par la gateway IPv4. Problème : ça n'expliquerait pas pourquoi les DHCPREQUESTs broadcastées après le rebinding time ne donnent rien.
  Hypothèse 3 : le serveur DHCP refuse les DHCPREQUESTs parce que, lorsqu'on a tous forcé notre option 90 (auth RFC 3118 donc) à une petite rafale de 0x00 suivie de notre login fti/xxxxxxx, on a en fait écrit ça :
# Option (90) Authentication:
    # First, we have to define that option:
    option authentication code 90 = string;
    # Next, we set it to our login (the password remains unused), i.e. "fti/1234567",
    # with 11 null bytes beforehand:
    #   - 1 for the authentication protocol: 0 means "configuration token"
    #   - 1 for the algorithm: 0 means "none"
    #   - 1 for RDM (Replay Detection method) type: 0 means "monotonically-increasing counter"
    #   - 8 for RDM (Replay Detection method) value (here, 0, simply)
    send authentication 00:00:00:00:00:00:00:00:00:00:00:66:74:69:2f:31:32:33:34:35:36:37;
    # Note: authentication IS necessary to get a proper DHCP offer.
En clair : je soupçonne les DHCPREQUESTs de ne pas fonctionner parce que leur valeur de Replay Detection reste à 0 (idéalement, il faudrait envoyer un timestamp Unix si je ne m'abuse). Ça impliquerait toutefois qu'Orange ait implèmenté de façon très scrupuleuse la RFC3118, c'est-à-dire que leurs serveurs DHCP vérifient aussi bien la valeur du token que le champ RDM.

Bref, première question pour le moment, adressée à tous ceux qui ont remplacé leur LiveBox par un équipement personnel : est-ce que ça se passe bien votre renouvellement DHCP ? Un grand merci d'avance pour vos retours.
« Modifié: 29 septembre 2018 à 16:14:38 par xavierg »

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Renouvellement DHCP
« Réponse #1 le: 23 février 2017 à 18:07:46 »
Si tu n'utilises pas le VLAN 838 , il faut que tu ignores l' "option dhcp-server-identifier" recu et ca devrait marcher en broadcast.

Dans la pratique, une livebox monte 2 connexions en DHCP, une sur le VLAN 838 et une sur le VLAN 832.

Le bail en 838 se fait en 1er et installe des nouvelles routes grâce a l'option 121 (Classless Static Route).
chez moi par exemple je recois cela:
    Option: (121) Classless Static Route
        Length: 93
         172.23.12.0/22-10.85.247.254
         172.20.224.167/32-10.85.247.254
         172.19.20.0/23-10.85.247.254
         193.253.67.88/29-10.85.247.254
         80.10.117.120/31-10.85.247.254
         81.253.206.0/24-10.85.247.254
         81.253.210.0/23-10.85.247.254
         193.253.153.228/32-10.85.247.254
         193.253.153.227/32-10.85.247.254
         81.253.214.0/23-10.85.247.254
         80.10.204.0/22-10.85.247.254

ca établi donc une route correcte pour le serveur DHCP pour le VLAN 832 (80.10.247.176 mon serveur DHCP pour 832) (ca part dans le réseau privé étendu d'Orange).

edit: en fait non c'est faux l'ip pour le serveur n'est pas des les routes recues.
« Modifié: 23 février 2017 à 23:24:03 par kgersen »

xavierg

  • Abonné Orange Fibre
  • *
  • Messages: 96
Renouvellement DHCP
« Réponse #2 le: 23 février 2017 à 18:13:00 »
Ah, excellente remarque, merci beaucoup ! J'avais oublié de préciser que, n'étant nullement intéressé par la TV et la téléphonie (encore que les bidouilles IGMP ont l'air très sympa), je n'ai mis en place que le VLAN 832 ; et l'absence du VLAN 838 explique à merveille cette IP fantôme ; je vais expérimenter dans ce sens et je rapporterai les résultats ici :)
« Modifié: 25 février 2017 à 12:53:32 par xavierg »

zoc

  • Abonné Orange Fibre
  • *
  • Messages: 4 258
  • Antibes (06) / Mercury (73)
Renouvellement DHCP
« Réponse #3 le: 23 février 2017 à 19:44:10 »
Et quand tu auras mis en place un client DHCP sur le VLAN 838, tu verras que là aussi le dhcp-server-identifier c'est n'importe quoi, et surtout, contrairement à celui du 832, il n'y a aucune route pour le joindre. Chez moi:

new_dhcp_server_identifier='192.168.3.254'

Par contre, je ne suis pas d'accord avec @kgersen, les routes mises en places sur le VLAN 838 ne font pas sortir les requêtes DHCP sur ce VLAN, en tout cas pas chez moi. Mon serveur DHCP est actuellement 80.10.247.176, et si je fais un traceroute (malgrés les routes en place), je sors bien sur le VLAN 832:

root@gateway:/run# show ip route 80.10.247.176
% Network not in table
root@gateway:/run# traceroute 80.10.247.176
traceroute to 80.10.247.176 (80.10.247.176), 30 hops max, 38 byte packets
 1  80.10.235.253 (80.10.235.253)  0.943 ms  0.751 ms  0.834 ms
 2  ae118-0.ncnic101.Nice.francetelecom.net (193.249.215.106)  3.507 ms  3.591 ms  3.570 ms
 3  ae45-0.nrmar101.Marseille.francetelecom.net (193.252.101.30)  6.465 ms  6.211 ms  6.249 ms
 4  ae51-0.nridf301.Paris.francetelecom.net (193.252.161.6)  15.616 ms  15.686 ms  15.718 ms
 5  ae40-0.ncidf303.Aubervilliers.francetelecom.net (81.253.180.25)  17.310 ms  15.942 ms  15.914 ms
 6  lag-1.nmidf301.Aubervilliers.francetelecom.net (193.253.82.17)  16.430 ms  16.176 ms  17.515 ms
 7  *  *  *

Sinon, chez moi j'ai résolu ces problèmes de DHCPREQUEST en ajoutant une règle iptables autorisant les paquets DHCP entrants sur le VLAN 832 (le renouvellement ne se fait pas avec une socket RAW, car c'est de l'unicast, donc ça passe par iptables, contrairement à la requête initiale en broadcast)...

Du coup, actuellement, il ne me reste que des DHCPREQUEST vers 192.168.3.254 en boucle toutes les 15 secondes, et qui sortent par la route par défaut... Moche, mais je ne m'en préoccupe pas trop pour l'instant. Il faudra que j'essaye de modifier ma conf. pour ignorer le dhcp-server-identifier sur le VLAN 838...

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Renouvellement DHCP
« Réponse #4 le: 23 février 2017 à 22:41:07 »
je n'ai pas dit que ca sortait par le VLAN 838 mais juste que la connexion sur 838 permettait d'avoir les routes pour joindre le serveur DHCP annoncé sur 832.

zoc

  • Abonné Orange Fibre
  • *
  • Messages: 4 258
  • Antibes (06) / Mercury (73)
Renouvellement DHCP
« Réponse #5 le: 23 février 2017 à 22:49:12 »
je n'ai pas dit que ca sortait par le VLAN 838 mais juste que la connexion sur 838 permettait d'avoir les routes pour joindre le serveur DHCP annoncé sur 832.
Bah non, chez moi le serveur DHCP annoncé sur 832 est joint par la route par défaut, et pas par une route mise en place à partir de la réponse DHCP sur le 838... Toutes les routes retournées par la réponse DHCP sont "via eth1.838" sur mon ERL...

admin@gateway:~$ show ip route
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
       O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       > - selected route, * - FIB route, p - stale info
IP Route Table for VRF "default"
S    *> 0.0.0.0/0 [210/0] via 90.116.160.1, eth1.832
C    *> 10.138.104.0/21 is directly connected, eth1.838
K    *> 80.10.117.120/31 [0/0] via 10.138.111.254, eth1.838
K    *> 80.10.204.0/22 [0/0] via 10.138.111.254, eth1.838
K    *> 81.253.206.0/24 [0/0] via 10.138.111.254, eth1.838
K    *> 81.253.210.0/23 [0/0] via 10.138.111.254, eth1.838
K    *> 81.253.214.0/23 [0/0] via 10.138.111.254, eth1.838
C    *> 90.116.160.0/21 is directly connected, eth1.832
C    *> 127.0.0.0/8 is directly connected, lo
K    *> 172.19.20.0/23 [0/0] via 10.138.111.254, eth1.838
K    *> 172.20.224.167/32 [0/0] via 10.138.111.254, eth1.838
K    *> 172.23.12.0/22 [0/0] via 10.138.111.254, eth1.838
C    *> 192.168.66.0/24 is directly connected, eth0.66
C    *> 192.168.67.0/24 is directly connected, eth0.67
C    *> 192.168.68.0/24 is directly connected, eth0.68
C    *> 192.168.69.0/24 is directly connected, eth0.69
C    *> 192.168.70.0/24 is directly connected, eth0.70
C    *> 192.168.255.254/32 is directly connected, eth1.840
K    *> 193.253.67.88/29 [0/0] via 10.138.111.254, eth1.838
K    *> 193.253.153.227/32 [0/0] via 10.138.111.254, eth1.838
K    *> 193.253.153.228/32 [0/0] via 10.138.111.254, eth1.838

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Renouvellement DHCP
« Réponse #6 le: 23 février 2017 à 22:52:07 »
chez moi c'est le cas. si on regarde les routes recus par l'option 121 sur 838 elles ont toutes la meme gateway: 10.85.247.254.

et cette IP est dans le subnet de l'IP reçu sur eth838 (10.85.247.141/23 -> range = 10.85.246.0 - 10.85.247.255).

donc effectivement ca devrait sortir par le vlan 838... curieux que chez toi ca ne le fait pas. C'est peut-etre un truc variable d'un endroit a l'autre chez Orange suivant les NRO et les emplacements.

zoc

  • Abonné Orange Fibre
  • *
  • Messages: 4 258
  • Antibes (06) / Mercury (73)
Renouvellement DHCP
« Réponse #7 le: 23 février 2017 à 22:58:37 »
chez moi c'est le cas. si on regarde les routes recus par l'option 121 sur 838 elles ont toutes la meme gateway: 10.85.247.254.

et cette IP est dans le subnet de l'IP reçu sur eth838 (10.85.247.141/23 -> range = 10.85.246.0 - 10.85.247.255).
Sur ce point on est d'accord....

Mais l'adresse du serveur DHCP est 80.10.247.176, et il n'y a aucune route passant par 10.138.111.254 (10.85.247.254 pour toi) pour cette adresse.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Renouvellement DHCP
« Réponse #8 le: 23 février 2017 à 23:12:11 »
oula oui tu as raison je me suis embrouillé les pinceaux dans les IP   :D

de tete je mettais l'ip du dhcp (80.10.247.176) dans le range 80.10.204.0/22 alors que ce range s'arrete a 80.10.207.255

c'est plus logique, my bad car c'était curieux que 832 dépendent a ce point de 838 :p

donc scratch tout ce que j'ai dit c'est completement faux  :P

xavierg

  • Abonné Orange Fibre
  • *
  • Messages: 96
Renouvellement DHCP
« Réponse #9 le: 24 février 2017 à 01:18:54 »
Alors, alors...

Tout d'abord, j'ai résolu mon problème. Il s'agissait d'une petite combinaison de PEBKACs (Aaah, le PEBKAC, cette chère hypothèse #1 !). Du coup, bonnes nouvelles :
  - le dhcp-server-identifier utilisé pour le VLAN 832 est parfaitement valide (modulo qu'il ne ping pas, ce qui est toujours chiant pour les diagnostics) ; pas besoin de supersede quoi que ce soit dans le fichier de configuration du client DHCP, pas besoin de gratter un hook supplèmentaire...
  - pas besoin de payer notre patch à l'ISC pour la RFC 3118 ;
  - je n'ai pas eu à triturer le VLAN 838.

Mes PEBKACS, maintenant :
  - comme j'utilise un tunnel par-dessus ma connexion Orange, j'ai un dhclient-exit-hook qui ajoute les routes vers les composants d'Orange que j'utilise (points d'entrée du VPN, serveurs smtp.orange.fr et bien sûr serveur DHCP) => j'avais oublié le "via ${new_routers}" dans ma route... ça ne pardonne pas.
  - une fois la route corrigée, je me suis aperçu que malgré ce que me laissaient croire mes précédents sniffs réseau, il était encore possible que des paquets partent avec la mauvaise priorité. Notamment : tous les paquets à destination de 255.255.255.255 avaient la bonne priorité mais dès que la destination était une adresse Unicast, ils étaient émis avec la priorité 0. Je me suis donc penché sur les fameuses règles mangle qui ont déjà posé tant de questions ici :
iptables -A POSTROUTING -o "${IFACE}" -p igmp                  -j CLASSIFY --set-class 0000:0006
iptables -A POSTROUTING -o "${IFACE}" -p icmp                  -j CLASSIFY --set-class 0000:0006
iptables -A POSTROUTING -o "${IFACE}" -p udp -m udp --dport 67 -j CLASSIFY --set-class 0000:0006
iptables -A POSTROUTING -o "${IFACE}"                          -j CLASSIFY --set-class 0000:0001
Et il m'est apparu que chaque fois qu'un paquet ICMP ou DHCP était classifié vers la skb 6 (mappée sur la priorité 6 via vconfig)... il était ensuite immédiatement reclassifié vers la skb 1 (mappée sur la priorité 0 via vconfig).
Concrètement, chaque fois que le compteur de la deuxième ligne s'incrèmentait, le compteur de la 4ème ligne s'incrèmentait aussi. J'ai alors supposé que la cible CLASSIFY impliquait un ersatz de RETURN implicite... que j'ai pris en compte comme suit :
iptables -A POSTROUTING -o "${IFACE}" -p igmp                  -j CLASSIFY --set-class 0000:0006
iptables -A POSTROUTING -o "${IFACE}" -p igmp                  -j ACCEPT
iptables -A POSTROUTING -o "${IFACE}" -p icmp                  -j CLASSIFY --set-class 0000:0006
iptables -A POSTROUTING -o "${IFACE}" -p icmp                  -j ACCEPT
iptables -A POSTROUTING -o "${IFACE}" -p udp -m udp --dport 67 -j CLASSIFY --set-class 0000:0006
iptables -A POSTROUTING -o "${IFACE}" -p udp -m udp --dport 67 -j ACCEPT
iptables -A POSTROUTING -o "${IFACE}"                          -j CLASSIFY --set-class 0000:0001
(-j RETURN serait peut-être plus élégant)

Et depuis :
Feb 24 01:11:11 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 24 01:11:11 dhclient: DHCPACK from 80.10.247.48
Feb 24 01:11:11 dhclient: bound to <IPv4> -- renewal in <osef> seconds.

Merci beaucoup à vous deux pour votre aide :)

Citer
Du coup, actuellement, il ne me reste que des DHCPREQUEST vers 192.168.3.254 en boucle toutes les 15 secondes, et qui sortent par la route par défaut... Moche, mais je ne m'en préoccupe pas trop pour l'instant. Il faudra que j'essaye de modifier ma conf. pour ignorer le dhcp-server-identifier sur le VLAN 838...
Je dis ça un peu au pif mais... avec une adresse pareille, ça n'est pas supposé être un serveur DHCP embarqué sur la LiveBox ? Et donc à remplacer par sa propre instance ? Remarque, ça pourrait être derrière un tunnel aussi...
« Modifié: 29 septembre 2018 à 16:17:40 par xavierg »

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
Renouvellement DHCP
« Réponse #10 le: 24 février 2017 à 09:56:10 »
tes règles n’étant pas exclusives l'une de l'autre il faut effectivement soit sortir explicitement (return ou accept), soit si c'est possible, les ordonner par ordre d'inclusion (la plus générale en 1er puis les plus spécifiques).

sur tes 4 regles, seule la derniere match aussi les 3 premières donc tu la met en 1er et ca devrait simplifier ta table. les paquets icmp et udp seront marqués 2 fois mais vu leur faible occurrence ca ira.

iptables -A POSTROUTING -o "${IFACE}"                          -j CLASSIFY --set-class 0000:0001
iptables -A POSTROUTING -o "${IFACE}" -p igmp                  -j CLASSIFY --set-class 0000:0006
iptables -A POSTROUTING -o "${IFACE}" -p icmp                  -j CLASSIFY --set-class 0000:0006
iptables -A POSTROUTING -o "${IFACE}" -p udp -m udp --dport 67 -j CLASSIFY --set-class 0000:0006

xavierg

  • Abonné Orange Fibre
  • *
  • Messages: 96
Renouvellement DHCP
« Réponse #11 le: 24 février 2017 à 16:25:37 »
Tout à fait, c'est mieux performance-wise :)