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

xavierg · « **Réponse #36 le:** 27 septembre 2020 à 23:34:23 »

Citation de: cyayon le 27 septembre 2020 à 09:41:25

le 1. ne fonctionne pas

Ça me titillait donc j'ai fini par stracer un dhclient -v -d dhcptest sur un setup de test. L'essentiel des syscalls obtenus (abrégés et retouchés pour la lisibilité) ci-dessous :

Citer

# Le blabla habituel au lancement de dhclient
[pid 533349] sendto(3<UNIX:[27659095->13527]>, "<30>Sep 27 13:27:26 dhclient[533349]: Internet Systems Consortium DHCP Client 4.4.1", 83, MSG_NOSIGNAL, NULL, 0) = 83
[pid 533349] sendto(3<UNIX:[27659095->13527]>, "<30>Sep 27 13:27:26 dhclient[533349]: Copyright 2004-2018 Internet Systems Consortium.", 86, MSG_NOSIGNAL, NULL, 0) = 86
[pid 533349] sendto(3<UNIX:[27659095->13527]>, "<30>Sep 27 13:27:26 dhclient[533349]: All rights reserved.", 58, MSG_NOSIGNAL, NULL, 0) = 58
[pid 533349] sendto(3<UNIX:[27659095->13527]>, "<30>Sep 27 13:27:26 dhclient[533349]: For info, please visit https://www.isc.org/software/dhcp/", 95, MSG_NOSIGNAL, NULL, 0) = 95
[pid 533349] sendto(3<UNIX:[27659095->13527]>, "<30>Sep 27 13:27:26 dhclient[533349]: ", 38, MSG_NOSIGNAL, NULL, 0) = 38

# Création d'un socket raw associé à l'interface réseau (ici file descriptor 8) :
[pid 533349] socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)) = 8<socket:[27659211]>
[pid 533349] bind(8<socket:[27659211]>, {sa_family=AF_PACKET, sll_protocol=htons(0 /* ETH_P_??? */), sll_ifindex=if_nametoindex("dhcptest"), sll_hatype=ARPHRD_NETROM, sll_pkttype=PACKET_HOST, sll_halen=0}, 20) = 0
[pid 533349] setsockopt(8<socket:[27659211]>, SOL_PACKET, PACKET_AUXDATA, [1], 4) = 0
[pid 533349] setsockopt(8<socket:[27659211]>, SOL_SOCKET, SO_ATTACH_FILTER, {len=11, filter=0x558664953960}, 16) = 0
[pid 533349] sendto(3<UNIX:[27659095->13527]>, "<30>Sep 27 13:27:26 dhclient[533349]: Listening on LPF/dhcptest/d6:fe:3a:05:72:db", 81, MSG_NOSIGNAL, NULL, 0) = 81
[pid 533349] sendto(3<UNIX:[27659095->13527]>, "<30>Sep 27 13:27:26 dhclient[533349]: Sending on LPF/dhcptest/d6:fe:3a:05:72:db", 81, MSG_NOSIGNAL, NULL, 0) = 81

# Création d'un socket UDP sur le port source 68 (ici file descriptor 9) :
[pid 533349] socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) = 9<UDP:[27659216]>
[pid 533349] setsockopt(9<UDP:[27659216]>, SOL_SOCKET, SO_REUSEADDR, [1], 4 <unfinished ...>
[pid 533349] bind(9<UDP:[27659216]>, {sa_family=AF_INET, sin_port=htons(68), sin_addr=inet_addr("0.0.0.0")}, 16 <unfinished ...>

# Utilisation du socket raw pour tout le trafic broadcast :
[pid 533349] sendto(3<UNIX:[27659095->13527]>, "<30>Sep 27 13:27:26 dhclient[533349]: Sending on Socket/fallback", 66, MSG_NOSIGNAL, NULL, 0 <unfinished ...>
[pid 533349] sendto(3<UNIX:[27659095->13527]>, "<30>Sep 27 13:27:26 dhclient[533349]: DHCPDISCOVER on dhcptest to 255.255.255.255 port 67 interval 4", 100, MSG_NOSIGNAL, NULL, 0 <unfinished ...>
[pid 533349] write(8<socket:[27659211]>, "\377\377\377\377\377\377\326\376:\5r\333\10\0E\20\1H\0\0\0\0\200\219\226\0\0\0\0\377\377\377\377\0D\0C\0014?\342\1\1\6\0005...", 342 <unfinished ...>
[pid 533352] sendto(3<UNIX:[27659095->13527]>, "<30>Sep 27 13:27:30 dhclient[533349]: DHCPDISCOVER on dhcptest to 255.255.255.255 port 67 interval 5", 100, MSG_NOSIGNAL, NULL, 0) = 100
[pid 533352] write(8<socket:[27659211]>, "\377\377\377\377\377\377\326\376:\5r\333\10\0E\20\1H\0\0\0\0\200\219\226\0\0\0\0\377\377\377\377\0D\0C\0014?\336\1\1\6\0005...", 342) = 342
[pid 533352] sendto(3<UNIX:[27659095->13527]>, "<30>Sep 27 13:27:30 dhclient[533349]: DHCPOFFER of 1.2.3.41 from 1.2.3.4", 72, MSG_NOSIGNAL, NULL, 0) = 72
[pid 533352] sendto(3<UNIX:[27659095->13527]>, "<30>Sep 27 13:27:30 dhclient[533349]: DHCPREQUEST for 1.2.3.41 on dhcptest to 255.255.255.255 port 67", 101, MSG_NOSIGNAL, NULL, 0) = 101
[pid 533352] write(8<socket:[27659211]>, "\377\377\377\377\377\377\326\376:\5r\333\10\0E\20\1H\0\0\0\0\200\219\226\0\0\0\0\377\377\377\377\0D\0C\0014\4n\1\1\6\0005\212\0\0...", 342) = 342
[pid 533352] sendto(3<UNIX:[27659095->13527]>, "<30>Sep 27 13:27:30 dhclient[533349]: DHCPACK of 1.2.3.41 from 1.2.3.4", 70, MSG_NOSIGNAL, NULL, 0) = 70
[pid 533352] sendto(3<UNIX:[27659095->13527]>, "<30>Sep 27 13:27:30 dhclient[533349]: bound to 1.2.3.41 -- renewal in 56 seconds.", 81, MSG_NOSIGNAL, NULL, 0) = 81

# Utilisation du socket UDP pour tout le trafic unicast vers le port 67 du serveur DHCP :
[pid 533352] sendto(3<UNIX:[27659095->13527]>, "<30>Sep 27 13:28:26 dhclient[533349]: DHCPREQUEST for 1.2.3.41 on dhcptest to 1.2.3.4 port 67", 93, MSG_NOSIGNAL, NULL, 0) = 93
[pid 533352] sendto(9<UDP:[0.0.0.0:68]>, "\1\1\6\0005\212\310G\0\0\0\0\1\2\3)\0\0\0\0\0\0\0\0\0\0\0\0\326\376:\5r\333\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...", 300, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("1.2.3.4")}, 16) = 300

Conclusion : par défaut, isc-dhcp-client n'associe nullement le socket utilisé pour son trafic unicast avec une interface particulière, ce qui explique que ip rule oif ne fonctionne pas.
Par contre, on voit qu'il utilise un socket UDP tout ce qu'il y a de plus standard : le trafic unicast d'isc-dhcp-client doit donc être repérable et marquable via NetFilter, puis reroutable via ip rule fwmark.

cyayon · « **Réponse #37 le:** 28 septembre 2020 à 17:29:15 »

Salut,

Merci bcp pour ton analyse.

Du coup j'utilise la table mangle de netfilter (modulo la syntaxe car j'utilise nftables) : ip source <mon_ip_orange1> ip dest <ip_server_dhcp_orange1> proto udp dport 67 ct mark set 0x<orange1>

Et la regle : ip rule add fwmark 0x<orange1> lookup 0x<orange1>

c'est bien cela ? je ne connais pas fwmark en fait ...

xavierg · « **Réponse #38 le:** 28 septembre 2020 à 18:11:19 »

Citation de: cyayon le 28 septembre 2020 à 17:29:15

Du coup j'utilise la table mangle de netfilter

Toujours en se référant à https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg, tu peux utiliser les tables raw, mangle, nat ou même filter du moment que tu fais ton marquage dans leur chaîne output -- cf schéma ci-dessous.

Citation de: cyayon le 28 septembre 2020 à 17:29:15

(modulo la syntaxe car j'utilise nftables) : ip source <mon_ip_orange1> ip dest <ip_server_dhcp_orange1> proto udp dport 67 ct mark set 0x<orange1>

Trois choses à ajuster :

Enlève la condition sur l'IP source ; au stade où tu marques les paquets avec iptables, l'étape de routing decision a déjà été appliquée en utilisant les tables de routage par défaut, et du coup l'IP source choisie n'est pas forcément celle que tu attends.
Remplace-la par une condition sur le gid du processus (skgid)
Utilise meta mark au lieu de ct mark -- Netfilter distingue mark / meta mark (une marque générique portée par les paquets au sein du kernel) et connmark / ct mark (la même chose mais spécifique au conntracking) ; ip rule fwmark matche sur le premier, pas sur le second.

Citation de: cyayon le 28 septembre 2020 à 17:29:15

Et la regle : ip rule add fwmark 0x<orange1> lookup 0x<orange1>

Oui, je confirme.

cyayon · « **Réponse #39 le:** 29 septembre 2020 à 09:37:39 »

Hello,

ok du coup voici la chain complete mangle OUTPUT avec surtout mes 2 meta mark :

chain OUTPUT {
type route hook output priority mangle; policy accept;
oifname $iface_wan1 udp dport 67 counter meta mark set 0x100 comment "mwan1_dhcp_orange1"
oifname $iface_wan2 udp dport 67 counter meta mark set 0x200 comment "mwan2_dhcp_orange2"

oifname $iface_wan1 ct state new counter jump MWAN1 comment "mwan1_orange1"
oifname $iface_wan2 ct state new counter jump MWAN2 comment "mwan2_orange2"
oifname $iface_wan3 ct state new counter jump MWAN3 comment "mwan3_lte"
oifname $iface_beta ct state new counter jump MWAN5 comment "mwan5_beta"
oifname $iface_vanisher1 ct state new counter jump MWAN6 comment "mwan6_vanisher_orange1"
oifname $iface_vanisher2 ct state new counter jump MWAN7 comment "mwan7_vanisher_orange2"
oifname $iface_vanisher3 ct state new counter jump MWAN9 comment "mwan1_vanisher_lte"
ct state new counter jump MWAN
ct mark != 0x0 meta mark set ct mark
}

a ceci j'ajoute les regles :
ip rule add fwmark 0x100 lookup 0x100
ip rule add fwmark 0x200 lookup 0x200

mais ne devrais-je pas être plus précis dans mes regles ip rules ?
ip rule add ipproto udp dport 67 fwmark 0x100 lookup 0x100
ip rule add ipproto udp dport 67 fwmark 0x200 lookup 0x200

t'en penses quoi ?

Merci

xavierg · « **Réponse #40 le:** 29 septembre 2020 à 13:58:48 »

Citation de: cyayon le 29 septembre 2020 à 09:37:39

oifname $iface_wan1 udp dport 67 counter meta mark set 0x100 comment "mwan1_dhcp_orange1"
oifname $iface_wan2 udp dport 67 counter meta mark set 0x200 comment "mwan2_dhcp_orange2"

Enlève les oifname : tout comme l'IP source, l'interface de sortie choisie n'est pas fiable (sinon on n'aurait pas à faire tout ça).
Tu peux ajouter sport 68 et l'adresse du serveur DHCP orange si tu veux.
Ajoute une condition sur skgid comme discuté précédemment.

Citation de: cyayon le 29 septembre 2020 à 09:37:39

ct mark != 0x0 meta mark set ct mark

Cette ligne écrase la meta mark avec une éventuelle ct mark (si non nulle). Là tout de suite, ça ne devrait pas impacter vu que tu ne positionnes pas de ct mark dans mangle/output, mais à l'avenir ça pourrait te jouer des tours.

Citation de: cyayon le 29 septembre 2020 à 09:37:39

a ceci j'ajoute les regles :
ip rule add fwmark 0x100 lookup 0x100
ip rule add fwmark 0x200 lookup 0x200

Oui, c'est correct.

Citation de: cyayon le 29 septembre 2020 à 09:37:39

mais ne devrais-je pas être plus précis dans mes regles ip rules ?
ip rule add ipproto udp dport 67 fwmark 0x100 lookup 0x100
ip rule add ipproto udp dport 67 fwmark 0x200 lookup 0x200

t'en penses quoi ?

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself : laisse les conditions exactes côté Netfilter, et contente-toi de la marque Netfilter côté routage.

cyayon · « **Réponse #41 le:** 29 septembre 2020 à 14:32:55 »

Hello,

bon ben ca ne fonctionne pas. Le paquet est bien marqué 0x200, ce qui montre que ma regle nft mangle fonctionne, mais curieusement l'interface de sortie reste wan1 (au lieu de wan2 ou orange2).

Sep 29 14:30:02 cerber netfilter_MWANSL2 IN= OUT=wan1 MAC= SRC=192.168.3.254 DST=80.10.247.48 LEN=411 TOS=00 PREC=0x00 TTL=64 ID=13429 PROTO=UDP SPT=68 DPT=67 LEN=391 UID=0 GID=0 MARK=200

# ip rule show table 200
200: from <mon_ip_orange> lookup 200
201: from all fwmark 0x200 lookup 200

je ne parviens pas forcer l'interface de sortie...

xavierg · « **Réponse #42 le:** 29 septembre 2020 à 16:19:40 »

Citation de: cyayon le 29 septembre 2020 à 14:32:55

Sep 29 14:30:02 cerber netfilter_MWANSL2 IN= OUT=wan1 MAC= SRC=192.168.3.254 DST=80.10.247.48 LEN=411 TOS=00 PREC=0x00 TTL=64 ID=13429 PROTO=UDP SPT=68 DPT=67 LEN=391 UID=0 GID=0 MARK=200

GID=0 ? Tu n'aurais pas oublié d'exécuter dhclient avec un gid différent ?

cyayon · « **Réponse #43 le:** 29 septembre 2020 à 16:21:16 »

Je ne l'ai pas encore modifié.

Mais dés l'instant où le paquet est bien marqué 0x200, je dirais peu importe non ?

cyayon · « **Réponse #44 le:** 29 septembre 2020 à 17:53:21 »

je teste pour l'instant avec un seul client DHCP pour valider le fonctionnement, donc je pense que je peux me passer de skgid/gid.

c'est comme si la table de regles ip n'était pas respectée.
Ne serait-ce pas un pb de priorité ou d'ordre ?

# ip rule show
0: from all lookup local
100: from 192.168.3.254 lookup 100
101: from all fwmark 0x100 lookup 100
200: from <mon_ip_orange2> lookup 200
201: from all fwmark 0x200 lookup 200
300: from 192.168.4.254 lookup 300
301: from all fwmark 0x300 lookup 300
500: from 192.168.251.2 lookup 500
501: from all fwmark 0x500 lookup 500
600: from 10.1.194.244 lookup 600
601: from all fwmark 0x600 lookup 600
700: from 10.2.1.242 lookup 700
701: from all fwmark 0x700 lookup 700
900: from 10.3.6.17 lookup 900
901: from all fwmark 0x900 lookup 900
32766: from all lookup main
32767: from all lookup default

# ip route show table 200
default via 82.127.187.1 dev orange2
10.1.194.0/24 dev tun4 proto kernel scope link src 10.1.194.244
10.2.1.0/24 dev tun5 proto kernel scope link src 10.2.1.242
10.3.6.0/24 dev tun3 proto kernel scope link src 10.3.6.17
82.127.187.0/25 dev orange2 proto kernel scope link src <mon_ip_orange2>
192.168.2.0/24 dev wan2 proto kernel scope link src 192.168.2.254
192.168.3.0/24 dev wan1 proto kernel scope link src 192.168.3.254
192.168.4.0/24 dev wan3 proto kernel scope link src 192.168.4.254
192.168.42.0/24 dev lan proto kernel scope link src 192.168.42.254
192.168.43.0/24 dev tun0 proto kernel scope link src 192.168.43.1
192.168.46.0/24 dev tun2 proto kernel scope link src 192.168.46.2
192.168.48.0/24 dev tun1 proto kernel scope link src 192.168.48.1
192.168.251.0/30 dev beta0 scope link src 192.168.251.2

xavierg · « **Réponse #45 le:** 29 septembre 2020 à 19:01:34 »

Ok, pas de souci pour tester sans discrimination sur le gid pour le moment.

Citation de: cyayon le 29 septembre 2020 à 17:53:21

c'est comme si la table de regles ip n'était pas respectée.
Ne serait-ce pas un pb de priorité ou d'ordre ?

Ou un problème de... base ?
Quand le kernel logge MARK=200, c'est 200 en base 10.
Mais quand ip rule affiche 0x200, c'est de la base 16, donc ça correspond à la marque 512.
Suggestion : ip rule add fwmark 200 lookup 200

cyayon · « **Réponse #46 le:** 29 septembre 2020 à 19:03:16 »

Bien vu, mais j’avais déjà corrigé cette coquille

Mon ip rule show montre bien :
201: from all fwmark 0x200 lookup 200

xavierg · « **Réponse #47 le:** 29 septembre 2020 à 19:06:41 »

Tu peux me rappeler la version de ton kernel ? Ce "MARK=200" me titille...