La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la LiveBox par un routeur => Discussion démarrée par: xavierg 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.
-
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.
-
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 :)
-
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...
-
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.
-
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
-
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.
-
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.
-
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
-
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 :)
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...
-
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
-
Tout à fait, c'est mieux performance-wise :)
-
Bon sinon, changer les priorités d'IGMP et d'ICMP c'est bien pour simuler au mieux ce que fait la box, mais en pratique ce n'est pas nécessaire, même dans les zones où il faut la CoS à 6 pour DHCP...
-
tout a fais. d'ailleurs si on regarde la livebox, pour igmp c'est prio 4 et pas 6.
j'avais rassemblé toutes les CoS emises par une Livebox ici: https://docs.google.com/spreadsheets/d/1Toh7a3wyXfH2NscAvhgxOJk1JEEBd6PwfmO003xRDo0/edit?usp=sharing
(hors icmp v4)
pour le vlan 832, en pratique, il semblerai que seuls DHCP et DHCPv6 soit nécessaires.
-
Hmm, dans ce cas, je vais alléger mes règles mangle. Mon but est d'avoir une connexion fonctionnelle, pas d'avoir un succédané de LiveBox :') Et puis, bon, mon trafic, ce doit être 99.9% d'UDP, 0.05% de SMTP et 0.05% de DHCP, le tout over IPv4 uniquement... IGMP ne me sert clairement à rien. ICMP est utile pour du troubleshooting de temps en temps, mais sa priorité ne semble en effet pas impacter. Encore merci pour vos conseils, je vais marquer ce post en "résolu".
-
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...
Bonjour,
désolé de déterrer le topic, mais j'ai le même souci sur mon Draytek ici:
https://lafibre.info/remplacer-livebox/tv-orange-vdls2-avec-modem-routeur-draytek-vigor-2860/msg455950/#msg455950
Donc on ne doit pas tenir compte de ces requetes DHCP ?
-
En pratique on s'en moque, elles sortent sur le WAN à destination d'une IP privée et aucune machine n'y répondra jamais...
Par ailleurs je ne sais pas ce que j'ai modifié chez moi, mais en fait je ne les vois même plus...
-
Bonjour à tous,
Moi aussi je suis dans le même cas avec des DHCPREQUEST a répétition.
Je suis dans un cas un peu particulier car je fais du multiwan VDSL. J'ai 1 ligne Free et 1 ligne Orange Pro avec IP fixe.
Je n'utilise pas la TV et donc je n'ai pas défini le VLAN 838, uniquement 832.
Mon serveur DHCP est également 80.10.247.48. Pour solutionner les DHCPREQUEST sans fin, il a été nécessaire d'ajouter une route 80.10.247.48 via <ma_gw_orange> dev <mon_iface_orange>.
Dés que j'ai cela, les DHCPREQUEST semble s'être arrêter immediatement. Si je retire la route, les DHCPREQUEST s'arrêtent.
Pour tester et éviter d'attendre l'expiration du bail j'ai supersede dhcp-renewal-time dhcp-rebinding-time et dhcp-lease-time avec des petites valeurs (30, 60 et 90 respectivement) pour pouvoir débugger.
Je n'ai pas eu besoin d'utiliser les rêgles iptables mangle, d'ailleurs quand je les ajoute, ca ne solutionne rien, seule la route vers 80.10.247.48 résout le problème.
Ma problématique est dans le fait que j'ai résiliser ma ligne Free et la remplacer par une ligne Orange Pro avec IP fixe également (donc une seconde).
Le problème c'est que du coup, je ne vais pouvoir ajouter une seconde route vers 80.10.247.48 et une autre interface. Le serveur DHCP 80.10.247.48 semble être le même pour tout le monde.
Comment faire pour éviter les DHCPREQUEST sur cette seconde ligne d'après vous ?
J'ai pensé contourner le problème avec des supersede dhcp-renewal-time dhcp-rebinding-time et dhcp-lease-time en infinite (quelle valeur ? 0 ?), car étant en IP fixe, je ne devrais pas avoir besoin de renouveler l'IP non ? Mais c'est pas forcément une bonne idée...
Merci pour vos lumières ... :)
-
bonjour,
J'ai pensé contourner le problème avec des supersede dhcp-renewal-time dhcp-rebinding-time et dhcp-lease-time en infinite (quelle valeur ? 0 ?),
ça, ça ne fonctionnera jamais sur la durée. même si ton ip est fixe, pour ouvrir l'accès, orange a besoin que tu dise qui tu es périodiquement, afin de ne pas fermer la route vers toi. (je simplifie volontairement)
-
Ok, je m'en doutais, merci pour la confirmation. Du coup, pas d'autre idée ?
-
hello,
je pense qu'il y aurait moyen avec iptables mais là comme ça j'ai pas de solution toute prète :(
Jerem
-
Hello,
Tu n'as pas précisé tes contraintes de déploiement (c'est quoi ton routeur, hardware, kernel, distribution, ce que tu peux configurer, ce que tu es prêt à configurer, etc.) du coup c'est un peu difficile de te répondre.
Comme ça parle de supersede (=isc-dhcp-client) à droite et d'iptables à gauche, je vais imaginer que tu as un isc-dhcp-client sur un Linux quelconque, sur lequel tu peux facilement ajouter de nouveaux outils en userland mais pas forcément passer sur un nouveau kernel.
Petit enfonçage de porte ouverte : la route <dhcp_server_ip> via <ma_gw_orange> dev <mon_iface_orange> est idéalement à ajouter dynamiquement via un hook DHCP.
Si tu as deux connexions séparées sur deux interfaces séparées avec un dhclient chacune, je vois deux grandes approches.
Approche 1 : séparation par utilisateur Unix :
1 tu t'arranges pour que le dhclient pour ton interface orange0 tourne avec un utilisateur différent du dhclient pour ton interface orange1
2a si ton kernel est un peu vieux :
2a.1 tu joues avec iptables -m owner --uid-owner pour mark-er les paquets qui t'intéressent
2a.2 tu joues avec ip rule et fwmark pour que chaque client DHCP ait sa propre table de routage. Note : c'est généralement assez chiant car il faut parfois prendre en compte les subtilités du genre "est-ce que au sein du kernel, le socket est toujours associé à un pid et donc à un couple uid/gid ou est-ce que le processus a close() et est mort depuis longtemps ?" ainsi que "fwmark, connmark, ou les deux ?"
2b si ton kernel est assez récent : tu joues avec ip rule et uidrange, c'est normalement beaucoup, beaucoup moins chiant.
Approche 2 : séparation par network namespace :
L'idée serait de faire tourner tes dhclients dans des network namespaces à part, dans lesquels tu déplacerais tes interfaces physiques, un peu comme si tu décidais d'avoir deux containers router0 et router1 mais avec juste le strict minimum. C'est élégant mais ça peut devenir compliqué parce que :
- une interface ne peut appartenir qu'à un seul network namespace
- un processus ne peut appartenir qu'à un seul network namespace (attention au monitoring)
Au final, cette technique implique de construire, au boot de ton routeur, un ou deux network namespaces, d'y assigner, activer et configurer toutes les interfaces réseau qui vont bien (tes interfaces physiques mais aussi la boucle locale et probablement des interfaces virtuelles), d'y ajouter les routes et iptables adéquates et enfin d'y lancer tes dhclients.
C'est fatigant. Mais c'est une solution.
-
Salut,
Merci bcp pour ta réponse très complète !
Effectivement, mon routeur/firewall est un Linux standard (Archlinux) très récent (rolling release).
J'utilise en effet dhclient (ISC) pour mes interfaces orange, j'ai 2 daemons (ipv4 et ipv6) par interface (orange1 et orange2).
En, fait j'ai 3 liaisons internet (2 orange VDSL et 1 Bouygues 4GBox). Sur chaque interfaces physiques, j'ai également un VPN, ce qui fait au total 6 interfaces WAN. Ce qui me permet du faire du load balancing, soit sur des liaisons WAN physiques (mes ISPs), soit sur des liaisons VPN, en fonction de différents critères. En ipv4 et ipv6.
Pour faire tout cela, j'utilise nftables (+mangle, je viens juste de migrer d'iptables), ip rule (+fwmark), et ip route table (une table par interface).
J'ai développé un petit daemon qui monitor tout ça et qui modifie dynamiquement les rêgles netfilter mangle, les rule et tables de routage en fonction du status des interfaces.
Tes propositions 2a.2 et 2b semblent être les plus naturelles dans mon cas. J'ai une préférence pour la 2b, mais je ne comprends pas bien comment faire.
Voici mes rules, les tables 100/101 et 200/201 correspondent à mes 2 interfaces orange (orange1 100/101 et orange2 200/201) :
# ip rule show
0: from all lookup local
100: from 83.xx.xx.xx lookup 100
101: from all fwmark 0x100 lookup 100
200: from 82.xx.xx.xx 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.4.115.241 lookup 600
601: from all fwmark 0x600 lookup 600
700: from 10.2.22.240 lookup 700
701: from all fwmark 0x700 lookup 700
900: from 10.0.49.21 lookup 900
901: from all fwmark 0x900 lookup 900
32766: from all lookup main
32767: from all lookup default
# ip route show table 100
default via 83.xx.xx.xx dev orange1
10.0.49.0/24 dev tun3 scope link src 10.0.49.21
10.2.22.0/24 dev tun5 scope link src 10.2.22.240
83.xx.xx.0/25 dev orange1 proto kernel scope link src 83.xx.xx.xx
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
# ip route show table 200
default via 82.xx.xx.xx dev orange2
10.0.49.0/24 dev tun3 scope link src 10.0.49.21
10.2.22.0/24 dev tun5 scope link src 10.2.22.240
82.xx.xx.0/25 dev orange2 proto kernel scope link src 82.xx.xx.xx
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
Si je retire la route vers le serveur DHCP orange 80.10.247.48 de ma table de routage principale, aujourd'hui j'ai : 80.10.247.48 via 82.127.187.1 dev orange2.
Ne puis-je pas simplement ajouter cette route pour les tables de routage 100 et 200 ? ip route add 80.10.247.48 via 82.127.187.1 dev orange1 ; ip route add 80.10.247.48 via 82.127.187.1 dev orange2 ?
Sinon, Admettons que dhclient1 (orange1) tourne sous le user orange1 (uid 100) et dhclient2 (uid 200) tourne sous le user orange2.
1. j'ajoute ces routes que je disais juste avant :
ip route add 80.10.247.48 via 83.xx.xx.1 dev orange1
ip route add 80.10.247.48 via 82.xx.xx.1 dev orange2
2. J'ajoute ces rules :
ip rule add uidrange 100 lookup 100
ip rule add uidrange 200 lookup 200
Ou bien dois-je faire autre chose du coté de nftables/iptables en PRE/POSTROUTING ?
Merci bcp.
-
Ah ben c'est nickel, tu joues DÉJÀ avec ip rule et des tables de routage séparées.
Ne puis-je pas simplement ajouter cette route pour les tables de routage 100 et 200 ?
Oui, bien sûr, c'est bien l'idée.
2. J'ajoute ces rules :
ip rule add uidrange 100 lookup 100
ip rule add uidrange 200 lookup 200
Oui, c'est bien ce que j'avais en tête dans la variante b de mon approche 1.
Ou bien dois-je faire autre chose du coté de nftables/iptables en PRE/POSTROUTING ?
Normalement non. Si on reprend le packet flow de Netfilter :
https://upload.wikimedia.org/wikipedia/commons/thumb/3/37/Netfilter-packet-flow.svg/2560px-Netfilter-packet-flow.svg.png
... uidrange a justement pour vocation de choisir la bonne route en fonction de l'uid dès l'étape de "routing decision" plutôt que de s'emmerder à changer de route (au risque d'embarquer une IP source incohérente) à l'étape "reroute check", ce qui élimine normalement tout besoin d'intervenir au niveau "postrouting".
Cela dit, de par la variété possible des configurations réseau...Your Mileage May Vary ©
-
Merci Xavier pour ta réponse.
Du coup, pour résumer et être certain d'avoir bien compris, je NE PEUX PAS me contenter de :
ip route add 80.10.247.48 via 83.xx.xx.1 dev orange1
ip route add 80.10.247.48 via 82.xx.xx.1 dev orange2
Je dois absolument faire ces 3 étapes :
1. dhclient1 (orange1) tourne sous le user orange1 (uid 100) et dhclient2 (uid 200) tourne sous le user orange2.
2. j'ajoute ces routes que je disais juste avant :
ip route add 80.10.247.48 via 83.xx.xx.1 dev orange1
ip route add 80.10.247.48 via 82.xx.xx.1 dev orange2
3. J'ajoute ces rules :
ip rule add uidrange 100 lookup 100
ip rule add uidrange 200 lookup 200
J'ai bien compris ? ::)
-
Tu as bien compris.
Il manque juste table 100 et table 200 à la fin de tes commandes ip route.
À mon sens, ces trois étapes devraient suffire dans la mesure où les paquets que tu essayes de router correctement sont des paquets UDP (donc pas de subtilités avec les TCP FIN en vue).
-
ok, merci encore pour ton aide !
Je test cela jeudi ou vendredi et je te dis :)
-
bon ben c'est plus compliqué que prévu.
Le problème c'est dhclient ne peut pas tourner sous un autre user que root.
J'ai essayé plusieurs choses, sudo, setcap, etc... pas moyen d'avoir le process dhclient qui tourne correctement sous un autre user que root.
Donc ip rule add uidrange ne semble pas être la bonne solution...
-
Ah oui, bien vu, il y a la problématique où pour obtenir un dhclient non-root, il faut au moins :
- les capabilities pour les raw sockets sur des ports privilégiés
- un mécanisme pour effectuer la configuration réseau sans être root
- s'assurer qu'il n'y ait aucun check sur l'uid dans le code de isc-dhcp-client lui-même
Du coup, le changement d'uid est bien une fausse piste. On pourrait se rabattre sur un changement de gid mais ip rule n'offre qu'uidrange, pas gidrange (frustrant). Netfilter offre la possibilité de matcher sur le groupe (--gid-owner) voire même sur ses groupes complémentaires (--suppl-groups), donc il doit être possible de :
- lancer dhclient avec un gid particulier
- fwmark les paquets adéquats avec -m owner --gid-owner
- ajouter une ip rule fwmark
- bidouiller un peu en POSTROUTING pour corriger l'IP source qui sera vraisemblablement foireuse (SNAT/MASQUERADE)
Mais pour être honnête, oui, ça commence à sentir le plan foireux. À ce stade-là, quitte à devoir jouer du fwmark, autant repérer ton login Orange avec iptables -m string ou tenter de jouer avec -m cgroup...
Par contre, l'approche #2 (séparation par network namespace) reste pertinente.
-
J'ai vu qu'il est possible d'utiliser ip rule iif ou oif pour matcher une interface. Je me demande si c'est possible d'utiliser cela plutot que l'uid ?
Ensuite pour les namespace, j'avoue ne pas trop connaitre, mais cela n'a pas l'air simple au premier abord.
-
J'ai vu qu'il est possible d'utiliser ip rule iif ou oif pour matcher une interface. Je me demande si c'est possible d'utiliser cela plutot que l'uid ?
Excellente question. Sur le principe, ça paraît un peu bizarre de matcher une interface de sortie dans le cadre d'un processus visant justement à déterminer une interface de sortie (ainsi qu'une IP source et d'éventuels gateways/next-hops).
oif NAME
select the outgoing device to match. The outgoing
interface is only available for packets originating
from local sockets that are bound to a device.
Par rapport à la condition en gras : si j'en crois le contenu de common/socket.c, isc-dhcp-client utilise bien SO_BINDTODEVICE, donc ça pourrait fonctionner ; j'ignore s'il l'utilise pour émettre ses paquets unicast (flemme de stracer un échange...) donc le plus simple c'est encore de tester.
Dans un premier temps, tu peux tester avec oif tout court :
ip rule oif orange2 lookup 200
Mais si tu as ou penses avoir un jour d'autres daemons bind-és à orange2, alors il vaut peut-être mieux affiner les conditions :
ip rule ipproto udp sport 68 dport 67 oif orange2 lookup 200
Ensuite pour les namespace, j'avoue ne pas trop connaitre, mais cela n'a pas l'air simple au premier abord.
C'est vraiment une question d'architecture pour le coup. Il y a un peu de complexité sur la mise en place, qui donne ensuite lieu à plus de simplicité sur la gestion des rules et des routes.
-
J'ai imaginé d'autres solutions au cas où :
1. utiliser nft skgid (j'ai migré de iptables à nftables il y a qques mois).
sachant que je mangle mark dejà les packets fonction de leur route/source/destination etc..., je pensais simplement essayer d'ajouter les regles nft à ma table de mangle multiwan :
meta skgid dhcp-orange1 ct mark set 0x100 counter
meta skgid dhcp-orange2 ct mark set 0x200 counter
100 et 200 étant mes tables de routage respectives pour les interfaces orange1 et orange2. Je ferais bien entendu tourner mes dhclient sous les GID dhcp-orange1 et dhcp-orange2. Simplement, je ne sais pas s'il faut ajouter des ip rule à cela ? Je ne pense pas...
2. ajouter une route globale avec des nexthop
80.10.247.48 nexthop via 82.xxxx dev orange2 nexthop via 83.xxxx dev orange1 onlink
mais ca me semble un peu hazardeux...
3. ta solution décrite dans ton dernier message
ip rule add ipproto udp sport 68 dport 67 oif orange1 lookup 100
ip rule add ipproto udp sport 68 dport 67 oif orange2 lookup 200
Je pense que la dernière (la tienne) semble la plus élégante, à voir si c'est suffisant.
ce serait tellement simple si les serveurs DHCP orange avaient des IP différentes :)
-
bon, ip rule add ipproto udp sport 68 dport 67 oif <iface> lookup <table>, ca ne fonctionne pas.
par contre la route avec les nexthop semble fonctionner, au moins avec une des 2 interfaces. J'attends de tester avec les 2 en simultané.
après il faudra tester avec nft skgid.
-
1. utiliser nft skgid (j'ai migré de iptables à nftables il y a qques mois).
sachant que je mangle mark dejà les packets fonction de leur route/source/destination etc..., je pensais simplement essayer d'ajouter les regles nft à ma table de mangle multiwan :
meta skgid dhcp-orange1 ct mark set 0x100 counter
meta skgid dhcp-orange2 ct mark set 0x200 counter
100 et 200 étant mes tables de routage respectives pour les interfaces orange1 et orange2. Je ferais bien entendu tourner mes dhclient sous les GID dhcp-orange1 et dhcp-orange2. Simplement, je ne sais pas s'il faut ajouter des ip rule à cela ? Je ne pense pas...
Sauf erreur d'interprétation de ma part, nft skgid n'est que l'équivalent nftables de iptables -m owner --gid-owner donc on retombe sur ma proposition de 2020-09-24 23:21:53, qui implique bien une ip rule fwmark (attention à ctmark vs fwmark par contre). À ma connaissance, nft vs iptables ne sont que deux interfaces différentes pour configurer NetFilter et le choix de l'un ou de l'autre ne change pas le mécanisme "routing decision" vs "reroute check" : ces deux étapes font toutes deux appel aux tables de routages (ip rule + ip route) pour définir/modifier l'interface de sortie. La correction de l'IP source que j'avais mentionnée précédemment reste théoriquement d'actualité mais en pratique est probablement DÉJÀ effectuée chez toi par un petit "oif orangeX masquerade" dans nat/postrouting.
2. ajouter une route globale avec des nexthop
80.10.247.48 nexthop via 82.xxxx dev orange2 nexthop via 83.xxxx dev orange1 onlink
mais ca me semble un peu hazardeux...
par contre la route avec les nexthop semble fonctionner, au moins avec une des 2 interfaces. J'attends de tester avec les 2 en simultané.
Je doute fortement que ça fasse automagiquement ce que tu souhaites ; je m'attends plutôt à ce que ça load-balance les paquets sortants tantôt sur une gateway tantôt sur l'autre... ce qui pourrait tomber en marche dans la mesure où dhclient émet son paquet plusieurs fois d'affilée en l'absence de réponse... mais ouais, ça reste hasardeux.
bon, ip rule add ipproto udp sport 68 dport 67 oif <iface> lookup <table>, ca ne fonctionne pas.
Tu as testé sans les conditions sur ipproto, sport et dport ?
ce serait tellement simple si les serveurs DHCP orange avaient des IP différentes :)
C'est un beau corner case que tu nous as trouvé là, en effet... même destination, même protocole, même port source, même port de destination, même uid.
Pistes restantes :
- ip rule oif
- nft skgid (implique ip rule fwmark)
- iptables string -- je ne trouve pas l'équivalent nft, je loupe un épisode ? (implique ip rule fwmark)
- nft cgroup (implique ip rule fwmark)
-
1. je vais essayer de tester sans ipproto, sport et dport, uniquement avec oif.
2. effectivement iptables -m strings n'a pas encore d'équivalent coté nft. On peut jouer avec les payload, mais c'est galère...
3. enfin, je finirais avec nft skgid / ip rule fwmark
-
1. je vais essayer de tester sans ipproto, sport et dport, uniquement avec oif.
2. effectivement iptables -m strings n'a pas encore d'équivalent coté nft. On peut jouer avec les payload, mais c'est galère...
3. enfin, je finirais avec nft skgid / ip rule fwmark
le 1. ne fonctionne pas, il ne reste donc plus que le 3. nft skgid et ip rule fwmark... je testerais semaine prochaine.
-
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 :
# 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.
-
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 ...
-
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.
(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.
Et la regle : ip rule add fwmark 0x<orange1> lookup 0x<orange1>
Oui, je confirme.
-
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 :)
-
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.
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.
a ceci j'ajoute les regles :
ip rule add fwmark 0x100 lookup 0x100
ip rule add fwmark 0x200 lookup 0x200
Oui, c'est correct.
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.
-
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...
-
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 ?
-
Je ne l'ai pas encore modifié.
Mais dés l'instant où le paquet est bien marqué 0x200, je dirais peu importe non ?
-
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
-
Ok, pas de souci pour tester sans discrimination sur le gid pour le moment.
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
-
Bien vu, mais j’avais déjà corrigé cette coquille ;)
Mon ip rule show montre bien :
201: from all fwmark 0x200 lookup 200
-
Tu peux me rappeler la version de ton kernel ? Ce "MARK=200" me titille...
-
# uname -a
Linux cerber.nbux.org 5.8.8-arch1-1 #1 SMP PREEMPT Wed, 09 Sep 2020 18:59:45 +0000 x86_64 GNU/Linux
-
Je m'avoue confus.
D'un côté, tu as obtenu MARK=200:
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
De l'autre tu devrais avoir MARK=0xquelquechose, quelle que soit la valeur utilisée :
$ grep -Irn MARK= linux-5.8.8/net/
net/ipv6/netfilter/nf_log_ipv6.c:280: /* Max length: 16 "MARK=0xFFFFFFFF " */
net/ipv6/netfilter/nf_log_ipv6.c:282: nf_log_buf_add(m, "MARK=0x%x ", skb->mark);
net/ipv4/netfilter/nf_log_ipv4.c:253: /* Max length: 16 "MARK=0xFFFFFFFF " */
net/ipv4/netfilter/nf_log_ipv4.c:255: nf_log_buf_add(m, "MARK=0x%x ", skb->mark);
-
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 <= coupable
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
Mais sinon, OUI, c'est un problème de priorité : c'est ta règle "from 192.168.3.254 lookup 100" qui matche tout de suite vu que 192.168.3.254 est l'adresse source erronnée dont a hérité ton paquet :)
-
Ah ! Dis comme ça c’est plus clair. Du coup, je fais quoi docteur ? Parce qu’il faut que mes autres paquets passent pas la bonne interface quand même...
quand tu fais : ip rule add fwmark 0x200 lookup 200, elle est ajoutee prio 99, mais ça ne donne rien.
La règle en prio 100 semble l’emporter ...
-
Tu peux remonter ta règle "from all fwmark 0x200 lookup 200" tout en haut. fwmark avec une valeur unique (par opposition à un masque), c'est déjà un marquage très, très spécifique, ça ne matchera rien d'autre que tes paquets DHCP marqués via Netfilter.
-
quand tu fais : ip rule add fwmark 0x200 lookup 200, elle est ajoutee prio 99, mais ça ne donne rien.
La règle en prio 100 semble l’emporter ...
Ah, ça c'est problématique par contre, parce que ip rule, c'est strictement linéaire (enfin, sauf quand on invoque certains mots-clés particuliers).
-
voici mes nouvelles regles :
# ip rule show
0: from all lookup local
99: from all fwmark 0x200 lookup 200
100: from 192.168.3.254 lookup 100
101: from all fwmark 0x100 lookup 100
200: from 82.127.187.99 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
et ca n'a pas l'air de changer quoique ce soit
-
Tu testes comment au fait ? Tu regardes juste la sortie de dhclient ou tu logges dans mangle/output ET dans nat/postrouting ?
-
je regarde la sortie de dhclient qui retry ses requests indéfiniment
Sep 29 20:07:05 cerber.nbux.org dhclient[244426]: DHCPREQUEST for <mon_ip_orange2> on orange2 to 80.10.247.48 port 67
et les logs netfilter qui continuent a monter des MARK 200 via wan1 :
Sep 29 20:08:27 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=31407 PROTO=UDP SPT=68 DPT=67 LEN=391 UID=0 GID=0 MARK=200
-
Justement, tes logs netfilter, ils sont générés dans quelle table ? Comme dit précédemment, je te conseille mangle/output et nat/postrouting (avec un préfixe pour les distinguer bien sûr), soit avant et après l'étape de "reroute check".
-
ils sont bien générés dans la chain mangle/OUTPUT
J'ai essayé mangle/POSTROUTING, pas mieux.
-
Ok, garde les deux, et colle-moi :
- tes règles nft pertinentes (mangle/output et nat/postrouting donc)
- ip rule
- ip route show table 200
- tes logs kernel mangle/output et nat/postrouting
On doit louper un épisode, reste à trouver lequel...
-
alors :
table ip nat {
chain PREROUTING {
type nat hook prerouting priority dstnat; policy accept;
iifname "lan" ip daddr 192.168.42.253 tcp dport 53 counter packets 0 bytes 0 dnat to 192.168.42.253:54 comment "PREROUTE_kids_dns_tcp"
iifname "lan" ip daddr 192.168.42.253 udp dport 53 counter packets 0 bytes 0 dnat to 192.168.42.253:54 comment "PREROUTE_kids_dns_udp"
iifname "lan" ip saddr { 192.168.42.26, 192.168.42.27, 192.168.42.29, 192.168.42.30, 192.168.42.31, 192.168.42.36 } tcp dport 53 counter packets 0 bytes 0 dnat to 192.168.42.251:53 comment "PREROUTE_cast_dns_tcp"
iifname "lan" ip saddr { 192.168.42.26, 192.168.42.27, 192.168.42.29, 192.168.42.30, 192.168.42.31, 192.168.42.36 } udp dport 53 counter packets 1 bytes 60 dnat to 192.168.42.251:53 comment "PREROUTE_cast_dns_udp"
iifname { "wan1", "wan3", "orange2" } ip saddr != 192.168.0.0/16 tcp dport { 53, 1194 } counter packets 0 bytes 0 dnat to 192.168.42.254:1194 comment "PREROUTE_vpn_endpoint_tcp"
iifname { "wan1", "wan3", "orange2" } ip saddr != 192.168.0.0/16 udp dport { 53, 1194 } counter packets 0 bytes 0 dnat to 192.168.42.254:1194 comment "PREROUTE_vpn_endpoint_udp"
iifname { "tun3" } tcp dport { 10542, 20542, 30542 } counter packets 0 bytes 0 dnat to 192.168.42.53 comment "PREROUTE_vanisher_forward_tcp"
iifname { "tun3" } udp dport { 10542, 20542, 30542 } counter packets 0 bytes 0 dnat to 192.168.42.53 comment "PREROUTE_vanisher_forward_udp"
iifname { "wan1", "wan3", "orange2" } ip saddr != 192.168.0.0/16 tcp dport { 22, 80, 443 } counter packets 1 bytes 60 dnat to 192.168.42.51 comment "PREROUTE_wan_forward_tcp"
}
chain POSTROUTING {
type nat hook postrouting priority srcnat; policy accept;
ip daddr 80.10.247.48 udp dport 67 counter packets 0 bytes 0 meta mark set 0x00000200
oifname "wan1" ip saddr 192.168.0.0/16 counter packets 19 bytes 1540 masquerade comment "NAT_via_WAN1"
oifname "orange2" ip saddr 192.168.0.0/16 counter packets 1 bytes 84 masquerade comment "NAT_via_WAN2"
oifname { "tun0", "tun1", "tun2", "beta0" } ip saddr 192.168.0.0/16 counter packets 5 bytes 1877 masquerade comment "NAT_via_VPN"
oifname "beta0" ip saddr 192.168.0.0/16 counter packets 0 bytes 0 masquerade comment "NAT_via_BETA"
oifname { "tun3", "tun4", "tun5" } ip saddr 192.168.0.0/16 counter packets 1 bytes 108 masquerade comment "NAT_via_VANISHER"
}
}
table ip mangle {
chain PREROUTING {
type filter hook prerouting priority mangle; policy accept;
iifname "wan1" ct state new counter packets 1 bytes 44 jump MWAN1 comment "mwan1_orange1"
iifname "orange2" ct state new counter packets 3 bytes 180 jump MWAN2 comment "mwan1_orange2"
iifname "wan3" ct state new counter packets 25 bytes 1220 jump MWAN3 comment "mwan3_lte"
iifname "beta0" ct state new counter packets 0 bytes 0 jump MWAN5 comment "mwan5_beta"
iifname { "tun4" } ct state new counter packets 0 bytes 0 jump MWAN6 comment "mwan1_vanisher_orange1"
iifname { "tun5" } ct state new counter packets 0 bytes 0 jump MWAN7 comment "mwan1_vanisher_orange2"
iifname { "tun3" } ct state new counter packets 0 bytes 0 jump MWAN9 comment "mwan9_vanisher_lte"
ct state new counter packets 61 bytes 6578 jump MWAN
ct mark != 0x00000000 meta mark set ct mark
}
chain INPUT {
type filter hook input priority mangle; policy accept;
}
chain FORWARD {
type filter hook forward priority mangle; policy accept;
}
chain OUTPUT {
type route hook output priority mangle; policy accept;
ip daddr 80.10.247.48 udp dport 67 counter packets 0 bytes 0 jump MWANSL2 comment "mwan2_dhcp_orange2"
oifname "wan1" ct state new counter packets 19 bytes 1532 jump MWAN1 comment "mwan1_orange1"
oifname "orange2" ct state new counter packets 8 bytes 636 jump MWAN2 comment "mwan2_orange2"
oifname "wan3" ct state new counter packets 1 bytes 114 jump MWAN3 comment "mwan3_lte"
oifname "beta0" ct state new counter packets 0 bytes 0 jump MWAN5 comment "mwan5_beta"
oifname { "tun4" } ct state new counter packets 5 bytes 406 jump MWAN6 comment "mwan6_vanisher_orange1"
oifname { "tun5" } ct state new counter packets 0 bytes 0 jump MWAN7 comment "mwan7_vanisher_orange2"
oifname { "tun3" } ct state new counter packets 0 bytes 0 jump MWAN9 comment "mwan1_vanisher_lte"
ct state new counter packets 244 bytes 39811 jump MWAN
ct mark != 0x00000000 meta mark set ct mark
}
...
chain MWANSL1 {
meta mark set 0x00000100
counter packets 0 bytes 0 log prefix "netfilter_MWANSL1" group 0
}
chain MWANSL2 {
meta mark set 0x00000200
counter packets 0 bytes 0 log prefix "netfilter_MWANSL2" group 0
}
}
}
# ip rule add from all fwmark 0x200 lookup 200 pri 1
[20:31:47]root@cerber:/etc/nft.d # ip rule show
0: from all lookup local
1: from all fwmark 0x200 lookup 200
100: from 192.168.3.254 lookup 100
101: from all fwmark 0x100 lookup 100
200: from <moniporange> ookup 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.228.244 lookup 600
601: from all fwmark 0x600 lookup 600
700: from 10.2.19.249 lookup 700
701: from all fwmark 0x700 lookup 700
900: from 10.4.65.19 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.228.0/24 dev tun4 scope link src 10.1.228.244
10.2.19.0/24 dev tun5 scope link src 10.2.19.249
10.4.65.0/24 dev tun3 scope link src 10.4.65.19
82.127.187.0/25 dev orange2 proto kernel scope link src <moniporange>
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
logs netfilter :
Sep 29 20:34:47 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=8844 PROTO=UDP SPT=68 DPT=67 LEN=391 UID=0 GID=0 MARK=200
-
Je me permets d'insister sur l'importance du double-logging : dans nat/POSTROUTING, enlève :
ip daddr 80.10.247.48 udp dport 67 counter packets 0 bytes 0 meta mark set 0x00000200(ça ne sert à rien de marquer ou re-marquer dans nat/POSTROUTING)
Mets plutôt :
meta mark 0x00000200 log prefix "nat/POSTROUTING"(soit dans nat/POSTROUTING soit dans mangle/POSTROUTING, du moment que c'est après le reroute check)
L'idée est que chaque paquet DHCP sortant DOIT te fournir DEUX lignes de log (même si elles sont identiques à part le préfixe).
À partir de là, on pourra émettre des hypothèses. Je verrais bien une subtilité sur le masquerade conditionnel.
-
ok, voici quelques logs :
Sep 29 21:02:12 cerber.nbux.org kernel: nat/POSTROUTINGIN=orange2 OUT=lan MAC=d8:a7:56:ac:ed:ea:0c:a4:02:2c:a1:74:08:00 SRC=129.226.67.92 DST=192.168.42.51 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=48524 DF PROTO=TCP SPT=54916 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=0 MARK=0x200
Sep 29 21:02:13 cerber.nbux.org dhclient[244426]: DHCPREQUEST for 82.127.187.99 on orange2 to 80.10.247.48 port 67
Sep 29 21:02:14 cerber.nbux.org ulogd[396]: 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=60828 PROTO=UDP SPT=68 DPT=67 LEN=391 UID=0 GID=0 MARK=200
Sep 29 21:02:18 cerber.nbux.org kernel: nat/POSTROUTINGIN=lan OUT=orange2 MAC=d0:50:99:d4:c9:a9:52:34:44:2f:b7:04:08:00 SRC=192.168.42.133 DST=92.123.113.15 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=59730 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x200
Sep 29 21:02:18 cerber.nbux.org kernel: nat/POSTROUTINGIN=lan OUT=orange2 MAC=d0:50:99:d4:c9:a9:00:04:4b:4c:1c:e6:08:00 SRC=192.168.42.36 DST=185.99.151.235 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=30612 DF PROTO=TCP SPT=37822 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x200
Sep 29 21:02:18 cerber.nbux.org kernel: nat/POSTROUTINGIN=lan OUT=orange2 MAC=d0:50:99:d4:c9:a9:00:04:4b:4c:1c:e6:08:00 SRC=192.168.42.36 DST=178.162.146.164 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=12654 DF PROTO=TCP SPT=47188 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x200
Sep 29 21:02:18 cerber.nbux.org kernel: nat/POSTROUTINGIN=lan OUT=orange2 MAC=d0:50:99:d4:c9:a9:00:04:4b:4c:1c:e6:08:00 SRC=192.168.42.36 DST=178.162.146.164 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=59459 DF PROTO=TCP SPT=47190 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x200
Sep 29 21:02:18 cerber.nbux.org kernel: nat/POSTROUTINGIN=lan OUT=orange2 MAC=d0:50:99:d4:c9:a9:00:04:4b:4c:1c:e6:08:00 SRC=192.168.42.36 DST=185.99.151.225 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=17722 DF PROTO=TCP SPT=58880 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x200
Sep 29 21:02:20 cerber.nbux.org kernel: nat/POSTROUTINGIN=lan OUT=orange2 MAC=d0:50:99:d4:c9:a9:ba:32:53:da:82:44:08:00 SRC=192.168.42.58 DST=1.1.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=254 ID=13610 DF PROTO=ICMP TYPE=8 CODE=0 ID=49189 SEQ=1 MARK=0x200
Sep 29 21:02:22 cerber.nbux.org kernel: nat/POSTROUTINGIN=lan OUT=orange2 MAC=d0:50:99:d4:c9:a9:7c:2a:31:10:2f:c0:08:00 SRC=192.168.42.82 DST=52.40.132.66 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=12077 DF PROTO=TCP SPT=52312 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0 MARK=0x200
Sep 29 21:02:22 cerber.nbux.org kernel: nat/POSTROUTINGIN=lan OUT=orange2 MAC=d0:50:99:d4:c9:a9:00:04:4b:4c:1c:e6:08:00 SRC=192.168.42.36 DST=185.99.151.225 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=10676 DF PROTO=TCP SPT=58884 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x200
Sep 29 21:02:23 cerber.nbux.org kernel: nat/POSTROUTINGIN=orange2 OUT=lan MAC=d8:a7:56:ac:ed:ea:0c:a4:02:2c:a1:74:08:00 SRC=54.37.156.188 DST=192.168.42.51 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=61442 DF PROTO=TCP SPT=45763 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0 MARK=0x200
-
Euh... je me suis trompé dans ma syntaxe ? Pourquoi on a tous les paquets possibles et imaginables marqués 0x200 ?
-
Non c’est juste mon grep qui ne montre que ces paquets...
-
Ok, j'en déduis que tu as d'autres règles qui positionnent la marque 0x200, my bad.
On va ajuster le logging en conséquence :
1. enlève le logging dans nat/POSTROUTING
2. ajoute ça dans mangle/POSTROUTING (moins de subtilités relatives au conntrack) :
udp dport 67 meta mark 0x00000200 log prefix "mangle/POSTROUTING"
-
En tout cas, j'ai la réponse à ma question de tout à l'heure : pourquoi ton log affiche MARK=200 et non MARK=0x200 : parce que pour une raison qui m'échappe encore, certains logs sont générés par ulogd, et d'autres par le kernel.
-
Et du coup, après lecture de https://home.regit.org/2014/02/nftables-and-netfilter-logging-framework/, est-ce que tu peux me fournir la sortie de cat /proc/net/netfilter/nf_log ?
-
salut,
# cat /proc/net/netfilter/nf_log
0 NONE (nfnetlink_log)
1 NONE (nfnetlink_log)
2 nfnetlink_log (nf_log_ipv4,nfnetlink_log)
3 NONE (nfnetlink_log)
4 NONE (nfnetlink_log)
5 NONE (nfnetlink_log)
6 NONE (nfnetlink_log)
7 nfnetlink_log (nfnetlink_log)
8 NONE (nfnetlink_log)
9 NONE (nfnetlink_log)
10 nfnetlink_log (nfnetlink_log)
11 NONE (nfnetlink_log)
12 NONE (nfnetlink_log)
curieusement les modifs dans nftables ne logguent rien de plus (tu as les log netfilter et dhclient) :
# journalctl -f | grep 80.10.247.4
Sep 30 07:38:35 cerber.nbux.org dhclient[244426]: DHCPREQUEST for 82.127.187.99 on orange2 to 80.10.247.48 port 67
Sep 30 07:38:36 cerber.nbux.org ulogd[396]: 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=43376 PROTO=UDP SPT=68 DPT=67 LEN=391 UID=0 GID=0 MARK=200
Sep 30 07:38:43 cerber.nbux.org dhclient[244426]: DHCPREQUEST for 82.127.187.99 on orange2 to 80.10.247.48 port 67
Sep 30 07:38:44 cerber.nbux.org ulogd[396]: 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=44892 PROTO=UDP SPT=68 DPT=67 LEN=391 UID=0 GID=0 MARK=200
Sep 30 07:38:54 cerber.nbux.org dhclient[244426]: DHCPREQUEST for 82.127.187.99 on orange2 to 80.10.247.48 port 67
Sep 30 07:38:55 cerber.nbux.org ulogd[396]: 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=45516 PROTO=UDP SPT=68 DPT=67 LEN=391 UID=0 GID=0 MARK=200
Sep 30 07:39:09 cerber.nbux.org dhclient[244426]: DHCPREQUEST for 82.127.187.99 on orange2 to 80.10.247.48 port 67
Sep 30 07:39:10 cerber.nbux.org ulogd[396]: 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=49498 PROTO=UDP SPT=68 DPT=67 LEN=391 UID=0 GID=0 MARK=200
Sep 30 07:39:25 cerber.nbux.org dhclient[244426]: DHCPREQUEST for 82.127.187.99 on orange2 to 80.10.247.48 port 67
Sep 30 07:39:26 cerber.nbux.org ulogd[396]: 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=50861 PROTO=UDP SPT=68 DPT=67 LEN=391 UID=0 GID=0 MARK=200
du coup j'ai AJOUTE un set meta mark dans mangle POSTROUTING (en plus de celui dans OUTPUT) :
# journalctl -f | grep 80.10.247.48
Sep 30 07:40:42 cerber.nbux.org dhclient[244426]: DHCPREQUEST for 82.127.187.99 on orange2 to 80.10.247.48 port 67
Sep 30 07:40:42 cerber.nbux.org kernel: mangle/POSTROUTING IN= OUT=wan1 SRC=192.168.3.254 DST=80.10.247.48 LEN=411 TOS=0x00 PREC=0x00 TTL=64 ID=63895 PROTO=UDP SPT=68 DPT=67 LEN=391 MARK=0x200
Sep 30 07:40:43 cerber.nbux.org ulogd[396]: 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=63895 PROTO=UDP SPT=68 DPT=67 LEN=391 UID=0 GID=0 MARK=200
Sep 30 07:40:43 cerber.nbux.org ulogd[396]: 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=63895 PROTO=UDP SPT=68 DPT=67 LEN=391 UID=0 GID=0 MARK=200
Sep 30 07:40:54 cerber.nbux.org dhclient[244426]: DHCPREQUEST for 82.127.187.99 on orange2 to 80.10.247.48 port 67
Sep 30 07:40:54 cerber.nbux.org kernel: mangle/POSTROUTING IN= OUT=wan1 SRC=192.168.3.254 DST=80.10.247.48 LEN=411 TOS=0x00 PREC=0x00 TTL=64 ID=1697 PROTO=UDP SPT=68 DPT=67 LEN=391 MARK=0x200
Sep 30 07:40:55 cerber.nbux.org ulogd[396]: 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=1697 PROTO=UDP SPT=68 DPT=67 LEN=391 UID=0 GID=0 MARK=200
Sep 30 07:40:55 cerber.nbux.org ulogd[396]: 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=1697 PROTO=UDP SPT=68 DPT=67 LEN=391 UID=0 GID=0 MARK=200
mais ca sort toujours par wan1...
-
Ça n'est pas le centre du sujet, mais je ne pense pas qu'on va s'en sortir sans un logging sain. Là, on a un même paquet IPv4 qui se fait logger soit par le kernel soit par ulogd (a priori avec un certain lag qui fait que tes entrées mangle/OUTPUT arrivent après mangle/POSTROUTING).
Personnellement, dans ce contexte, tout l'enculage de mouche apporté par ulogd me laisse complètement froid (le kernel est un bout de code assez compliqué sans qu'on y rajoute les caprices d'une cochonnerie en userland). Je propose donc de :
echo nf_log_ipv4 > /proc/sys/net/netfilter/nf_log/2Avec un peu de chance, ça devrait suffire à revenir à une situation saine à ce niveau-là.
Le centre du sujet, c'est : pourquoi est-ce que marquer le paquet dans mangle/OUTPUT ne déclenche pas le reroute check ?
Déjà, ce qu'il faut savoir sur le déclenchement du reroute check :
avec iptables, c'est déclenché dans la fonction ipt_mangle_out() dans net/ipv4/netfilter/iptable_mangle.c
avec nftables, c'est déclenché dans la fonction nf_route_table_hook4() dans net/netfilter/nft_chain_route.c
Cette dernière fonction correspond à la chaîne "route" de type NFT_CHAIN_T_ROUTE (on est bien sur "type route" donc) pour la famille NFPROTO_IPV4 ("table ip" donc) pour le hook NF_INET_LOCAL_OUT (on est bien sur "hook output" donc).
Les deux fonctions ont à peu près le même comportement : elles exécutent les rules (ipt_do_table(skb, state, state->net->ipv4.iptable_mangle); vs nft_do_chain(&pkt, priv);) et si le paquet est accepté ET qu'une des quatre propriétés suivantes a été modifiée par les rules :
- adresse source
- adresse destination
- mark
- tos
... alors elles font appel à ip_route_me_harder() pour réévaluer le paquet par rapport aux tables de routages (ip rule + ip route).
Deux hypothèses non-exclusives :
- on ne marque pas au bon endroit : la base chain qu'on utilise en guise de mangle/OUTPUT ne serait pas correctement configurée, peut-être en termes de priority
- le paquet était déjà marqué 0x200 à cause d'une règle précédente ; comme son passage dans mangle/OUTPUT n'aura pas changé la valeur de la marque, le reroute check n'aura pas été déclenché
-
Merci encore pour ton temps et ces infos très interessantes.
Je crois que tu vas peut-être m'en vouloir ... :-X
je viens de configurer ma ligne orange1 (seule orange2 était en mode bridge jusqu'a maintenant). Le serveur DHCP pour orange1 semble être différent de celui pour orange2 :
[14:26:56]root@cerber:/etc/dnsmasq.d # journalctl -u dhclient@orange1.service -n 1000 | grep from
Sep 30 10:39:11 cerber.nbux.org dhclient[3473803]: DHCPACK of <ip_orange1> from 193.251.41.1
Sep 30 10:39:16 cerber.nbux.org dhclient[3473851]: RCV: Reply message on orange1 from fe80::ba0:bab.
[14:27:12]root@cerber:/etc/dnsmasq.d # journalctl -u dhclient@orange2.service -n 1000 | grep from
Sep 30 07:30:36 cerber.nbux.org dhclient[244468]: RCV: Reply message on orange2 from fe80::ba0:bab.
Sep 30 09:22:56 cerber.nbux.org dhclient[244426]: DHCPACK of <ip_orange2> from 80.10.247.48
dans le premier cas c'est 193.251.41.1 et dans l'autre 80.10.247.48.
du coup c'est bcp bcp plus simple , une route statique et hop ...
Il semble qu'il y ait plusieurs infra DHCP chez Orange et que selon le range de ton IP fixe, on adresse un serveur DHCP différent. Ma chance est d'avoir 2 IPs fixes dans 2 ranges différents et du coup, 2 serveurs DHCP bien distincts.
Après cela ne résout pas le pourquoi du comment c'est certain.
-
Ah je me disais bien que c'était un cas vraiment très, très particulier que tu nous avais trouvé là.
De fait, fonce pour une simple route statique, le reroute check, c'est jamais une technique qu'on utilise pour le plaisir.
C'est juste un peu dommage parce qu'on ne saura jamais ce qui clochait dans le setup.
Pour le coup, la plongée forcée dans nftables était intéressante, d'autant plus que c'est un sujet clairement procrastiné de mon côté. Je reste un peu perplexe sur le sujet cela dit : autant il semble y avoir un potentiel de fou pour que chaque application/service/daemon/outil déclare ses propres règles dans ses propres tables (qui ne sont plus que des namespaces pour des hooks Netfilter) autant tous les exemples glanés sur le net ne font que répéter le mantra de base avec des tables nftables reprenant les noms des tables iptables.
-
C'est quand un coup de bol d'avoir 2 ips fixes Orange dans 2 range bien distincts. J'ai repéré sur le forum des users qui avaient le même serveur DHCP que moi.
Du coup, je m'étais dis que tout le monde avait le même serveur DHCP chez Orange...
Quand je vois la complexité de nftables vs PF (packet filter) d'openbsd, je me dis que y a des mecs qui doivent pas bien dormir ... :)
Mais bon, faut vivre avec son temps, pas vrai ?
J'ai quand même bcp appris sur ce post, certaines choses sont plus claires dans ma tete, c'est grace à toi ;) merci !
-
C'est juste un peu dommage parce qu'on ne saura jamais ce qui clochait dans le setup.
+1 vous ne voulez pas continuer ? Pour la beauté du geste ?
-
+1 vous ne voulez pas continuer ? Pour la beauté du geste ?
comme un air de moquerie ? ;D
-
Oh non, pas du tout. La curiosité et le challenge avant tout.
J'ai appris pleins de choses, lu assidûment et suis un peu déçu de ne pas voir au bout la solution malgré votre investissement.
-
Oh non, pas du tout. La curiosité et le challenge avant tout.
J'ai appris pleins de choses, lu assidûment et suis un peu déçu de ne pas voir au bout la solution malgré votre investissement.
moi aussi, surtout que je dois avoir un bidule mal configuré qque part, c'est stressant ::)
-
Et ben voila, ce qui devait arriver, arriva...
Le serveur DHCP orange est bien commun à tout le monde : 80.10.247.48
Oct 02 09:05:00 cerber.nbux.org dhclient[97498]: DHCPREQUEST for <iporange1> on orange1 to 80.10.247.48 port 67
Du coup mon dhclient orange1 ne parvient pas à faire son RENEW, car j'ai une route statique vers 80.10.247.48 sur orange2.
Donc on a bien un problème.
-
Du coup, en pièce jointe, j'ai posté l'ensemble de mes rêgles NFT, rule et routes.
J'ai anonymsé certaines IP.
J'ai retiré les modifs que nous avions faites pour tenter de solutionner le problème de re-routecheck histoire de repartir from scratch.
-
Que de rebondissements...
... et que d'entrées dans cette table de routage principale... ça laisse vraiment penser que des namespaces pourraient segmenter tout ça.
Ça se comporte comme voulu le double-nexthop en guise de route par défaut ? Ça fait pas chier sur tout ce qui touche à TCP ?
Bref, pour reprendre les travaux sur le déclenchement d'un reroute check basé sur une fwmark (meta mark), je te propose dans un premier temps de modifier ta chaîne mangle/OUTPUT (qui me semble correctement déclarée) comme suit :
chain OUTPUT {
type route hook output priority mangle; policy accept;
# une ligne ajoutée au début :
udp sport 68 dport 67 log prefix "mangle/OUTPUT: entering"
# contenu initial, laissé intact :
oifname "orange1" ct state new counter packets 991 bytes 84041 jump MWAN1 comment "mwan1_orange1"
oifname "orange2" ct state new counter packets 574 bytes 48670 jump MWAN2 comment "mwan2_orange2"
oifname "wan3" ct state new counter packets 3 bytes 276 jump MWAN3 comment "mwan3_lte"
oifname "beta0" ct state new counter packets 2 bytes 184 jump MWAN5 comment "mwan5_beta"
oifname { "tun4" } ct state new counter packets 0 bytes 0 jump MWAN6 comment "mwan6_vanisher_orange1"
oifname { "tun5" } ct state new counter packets 0 bytes 0 jump MWAN7 comment "mwan7_vanisher_orange2"
oifname { "tun3" } ct state new counter packets 0 bytes 0 jump MWAN9 comment "mwan1_vanisher_lte"
ct state new counter packets 1866 bytes 169599 jump MWAN
ct mark != 0x00000000 meta mark set ct mark
# trois lignes ajoutées à la fin :
udp sport 68 dport 67 log prefix "mangle/OUTPUT: about to mark"
udp sport 68 dport 67 meta mark set 0xcafecafe
udp sport 68 dport 67 log prefix "mangle/OUTPUT: freshly marked"
}
Le but c'est de marquer tous les paquets DHCP unicast sortants et d'avoir des traces qui certifient que la fwmark n'était pas présente lors de l'entrée du paquet dans la chaîne de type route hook output mais qu'elle est bien présente en sortie.
Tu noteras que je meta mark après le "meta mark set ct mark" qui me semble être un appeau à subtilités.
Si ça fonctionne, on doit obtenir 3 entrées de log pour chaque paquet intéressant.
-
Perso si je devais faire ce que tu essayes de faire, j’utiliserais cgroups, et en particulier le network classifier group, ce qui permet d’une part d’avoir une table de routage spécifique pour chaque process, et d’autre part si besoin d’appliquer la CoS sans devoir patcher dhclient en utilisant le groupe network priority, comme certains l’ont déjà expliqué ici ( https://lafibre.info/remplacer-livebox/isc-dhcp-client-raw-socket-solution )
J’avoue que j’ai très peu joué avec cgroups (d’autant plus que le kernel de mon ER4 ne supporte pas le network priority group), mais il y a quelques pistes ici https://www.evolware.org/?p=369 par exemple).
En pratique il s’agirait de mettre en place 2 groupes, un process dhclient dans chaque groupe avec la table de routage qui va bien.
-
Premièrement la route dans la table main avec nexthop ne fonctionne pas, c'est soit l'un soit l'autre.
Suite aux modifs proposées par Xavier, j'ai effectivement 3 logs par DHCPREQUEST. Actuellement, c'est mon orange2 qui ne parvient pas à faire son RENEW. Pourtant, dans les logs, cela provient de l'IP orange1, alors que c'est le dhclient de l'interface orange2...
Oct 03 08:31:10 cerber.nbux.org kernel: mangle/OUTPUT: entering IN= OUT=orange1 SRC=<iporange1> DST=80.10.247.48 LEN=411 TOS=0x00 PREC=0x00 TTL=64 ID=34374 PROTO=UDP SPT=68 DPT=67 LEN=391
Oct 03 08:31:10 cerber.nbux.org kernel: mangle/OUTPUT: about to mark IN= OUT=orange1 SRC=<iporange1> DST=80.10.247.48 LEN=411 TOS=0x00 PREC=0x00 TTL=64 ID=34374 PROTO=UDP SPT=68 DPT=67 LEN=391 MARK=0x100
Oct 03 08:31:10 cerber.nbux.org kernel: mangle/OUTPUT: freshly marked IN= OUT=orange1 SRC=<iporange1> DST=80.10.247.48 LEN=411 TOS=0x00 PREC=0x00 TTL=64 ID=34374 PROTO=UDP SPT=68 DPT=67 LEN=391 MARK=0xcafecafe
Oct 03 08:31:27 cerber.nbux.org kernel: mangle/OUTPUT: entering IN= OUT=orange1 SRC=<iporange1> DST=80.10.247.48 LEN=411 TOS=0x00 PREC=0x00 TTL=64 ID=35298 PROTO=UDP SPT=68 DPT=67 LEN=391
Oct 03 08:31:27 cerber.nbux.org kernel: mangle/OUTPUT: about to mark IN= OUT=orange1 SRC=<iporange1> DST=80.10.247.48 LEN=411 TOS=0x00 PREC=0x00 TTL=64 ID=35298 PROTO=UDP SPT=68 DPT=67 LEN=391 MARK=0x100
Oct 03 08:31:27 cerber.nbux.org kernel: mangle/OUTPUT: freshly marked IN= OUT=orange1 SRC=<iporange1> DST=80.10.247.48 LEN=411 TOS=0x00 PREC=0x00 TTL=64 ID=35298 PROTO=UDP SPT=68 DPT=67 LEN=391 MARK=0xcafecafe
Compte-tenu de mes ip rules, c'est logique je crois ?
0: from all lookup local
100: from <iporange1> lookup 100
101: from all fwmark 0x100 lookup 100
200: from <iporange2> 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.4.113.251 lookup 600
601: from all fwmark 0x600 lookup 600
700: from 10.2.0.244 lookup 700
701: from all fwmark 0x700 lookup 700
900: from 10.0.49.26 lookup 900
901: from all fwmark 0x900 lookup 900
32766: from all lookup main
32767: from all lookup default
Ensuite, merci ZOC pour ta suggestion.
En réfléchissant (si si ça m'arrive :)), je ne vois pas comment marker mes paquets dans ces conditions sachant que l'interface ET l'IP source ne sont pas bons. Du coup, effectivement, il reste de le process (ou le skgid comme l'avait suggéré Xavier avant d'ailleurs).
J'ai modifié ma table mangle/OUTPUT en ajoutant un markage sur meta cgroup.
chain OUTPUT {
type route hook output priority mangle; policy accept;
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
# to force DHCP RENEW cgroup process via its own iface
udp sport 68 udp dport 67 meta cgroup $cgroup_wan1 counter jump MWAN1_CGROUP comment "mwan1_dhcpc_cgroup"
udp sport 68 udp dport 67 meta cgroup $cgroup_wan2 counter jump MWAN2_CGROUP comment "mwan2_dhcpc_cgroup"
}
chain MWAN1_CGROUP {
counter meta mark set 0x100
log prefix "netfilter_MWAN1_CGROUP" group 0
}
chain MWAN2_CGROUP {
counter meta mark set 0x200
log prefix "netfilter_MWAN2_CGROUP" group 0
}
chain MWAN3_CGROUP {
counter meta mark set 0x300
log prefix "netfilter_MWAN3_CGROUP" group 0
}
j'ai modifié mes rules :
0: from all lookup local
1: from all fwmark 0x100 ipproto udp sport 68 dport 67 lookup 100
2: from all fwmark 0x200 ipproto udp sport 68 dport 67 lookup 200
100: from <iporange1> lookup 100
101: from all fwmark 0x100 lookup 100
200: from <iporange2> 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.4.102.16 lookup 600
601: from all fwmark 0x600 lookup 600
700: from 10.2.23.241 lookup 700
701: from all fwmark 0x700 lookup 700
900: from 10.3.5.248 lookup 900
901: from all fwmark 0x900 lookup 900
32766: from all lookup main
32767: from all lookup default
ensuite, j'ai ajouté les PID des process dhclient dans /sys/fs/cgroup/net_cls/dhcp-orange1|2/tasks et chacun avec son $cgroup_wanX dans /sys/fs/cgroup/net_cls/dhcp-orange1|2/net_cls.classid
Résultat, ca a marché de suite, le RENEW de l'interface orange2 est passé direct !
Par contre, ne sachant pas trop, dois-je ajouter les lignes de markage cgroup dans la chain OUTPUT AVANT le "meta mark set ct mark" final ?
Est-ce une bonne idée, je ne sais pas ... qu'en pensez-vous ? d'un point de vue perf, c'est surement mieux non ?
Ca ressemblerait à cela :
chain OUTPUT {
type route hook output priority mangle; policy accept;
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"
# to force DHCP RENEW cgroup process via its own iface
udp sport 68 udp dport 67 meta cgroup $cgroup_wan1 counter jump MWAN1_CGROUP comment "mwan1_dhcpc_cgroup"
udp sport 68 udp dport 67 meta cgroup $cgroup_wan2 counter jump MWAN2_CGROUP comment "mwan2_dhcpc_cgroup"
ct state new counter jump MWAN
ct mark != 0x0 meta mark set ct mark
}
Enfin, c'est vrai que ce serait plus simple sans utiliser les cgroup et d'arriver à marker les paquets avec une regle mangle/OUTPUT, mais compte-tenu des caractéristiques des paquets, avec l'ip source et l'interface qui correspondent bien (alors que c'est faux), j'avoue que je ne vois pas trop comment faire.
Ou alors le gid du process dhclient et une regle nftables du genre :
chain OUTPUT {
type route hook output priority mangle; policy accept;
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"
# to force DHCP RENEW cgroup process via its own iface
udp sport 68 udp dport 67 meta skgid $skgid_wan1 counter jump MWAN1_CGROUP comment "mwan1_dhcpc_skgid"
udp sport 68 udp dport 67 meta skgid $skgid_wan2 counter jump MWAN2_CGROUP comment "mwan2_dhcpc_skgid"
ct state new counter jump MWAN
ct mark != 0x0 meta mark set ct mark
}
C'est peut-être plus simple et plus flexible, il suffirait de faire tourner les process dans leur groupe...
La question qui persiste, est de savoir s'il faut mettre les regles nft avant ou apres le 'meta mark set ct mark' final de la chain OUTPUT ?
Et dois-je marké les paquets dans les chains mangle/OUTPUT, mangle/PRETROUTING et mangle/POSTROUTING comme je le fais, ou bien mangle/OUTPUT et mangle/PREROUTING ne suffirait-il pas ?
-
Premièrement la route dans la table main avec nexthop ne fonctionne pas, c'est soit l'un soit l'autre.
Ah, c'est bien ce qu'il me semblait :)
Suite aux modifs proposées par Xavier, j'ai effectivement 3 logs par DHCPREQUEST.
Excellent.
Oct 03 08:31:10 cerber.nbux.org kernel: mangle/OUTPUT: entering IN= OUT=orange1 SRC=<iporange1> DST=80.10.247.48 LEN=411 TOS=0x00 PREC=0x00 TTL=64 ID=34374 PROTO=UDP SPT=68 DPT=67 LEN=391
Oct 03 08:31:10 cerber.nbux.org kernel: mangle/OUTPUT: about to mark IN= OUT=orange1 SRC=<iporange1> DST=80.10.247.48 LEN=411 TOS=0x00 PREC=0x00 TTL=64 ID=34374 PROTO=UDP SPT=68 DPT=67 LEN=391 MARK=0x100
Oct 03 08:31:10 cerber.nbux.org kernel: mangle/OUTPUT: freshly marked IN= OUT=orange1 SRC=<iporange1> DST=80.10.247.48 LEN=411 TOS=0x00 PREC=0x00 TTL=64 ID=34374 PROTO=UDP SPT=68 DPT=67 LEN=391 MARK=0xcafecafe
Tu remarqueras que le paquet se fait d'abord marquer en 0x100 avant de se faire marquer en 0xcafecafe (ou 0x200 comme initialement voulu). C'est peut-être dans cette zone que se situe le bloquage rencontré jusqu'à maintenant.
Ensuite, merci ZOC pour ta suggestion.
En réfléchissant (si si ça m'arrive :)), je ne vois pas comment marker mes paquets dans ces conditions sachant que l'interface ET l'IP source ne sont pas bons. Du coup, effectivement, il reste de le process (ou le skgid comme l'avait suggéré Xavier avant d'ailleurs).
J'ai modifié ma table mangle/OUTPUT en ajoutant un markage sur meta cgroup.
Oui, très clairement, comme déjà mentionné, tu ne PEUX PAS te baser sur les informations que tu veux corriger (ici : celles choisies lors du routage initial : IP source et interface de sortie) pour repérer les paquets qui t'intéressent, tu DOIS te baser sur une discrimination relative au processus ayant émis les paquets (uid ça a foiré, skgid c'est toujours sympa parce que c'est simple et réutilisable, cgroup je l'avais mentionné mais selon ton setup ça peut être un peu plus chiant à gérer) ou une discrimination relative au payload UDP (comme repérer ton login Orange dans le payload).
j'ai modifié mes rules :
Ça me semble un peu redondant. Je proposerais :
0: from all lookup local
1: from all fwmark 0x100 lookup 100
2: from all fwmark 0x200 lookup 200
100: from <iporange1> lookup 100
200: from <iporange2> 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.4.102.16 lookup 600
601: from all fwmark 0x600 lookup 600
700: from 10.2.23.241 lookup 700
701: from all fwmark 0x700 lookup 700
900: from 10.3.5.248 lookup 900
901: from all fwmark 0x900 lookup 900
32766: from all lookup main
32767: from all lookup default
À mon sens tu pourrais même grouper toutes tes rules fwmark au début et ensuite seulement te baser sur l'IP source. Mais c'est du chipotage à ce stade.
ensuite, j'ai ajouté les PID des process dhclient dans /sys/fs/cgroup/net_cls/dhcp-orange1|2/tasks et chacun avec son $cgroup_wanX dans /sys/fs/cgroup/net_cls/dhcp-orange1|2/net_cls.classid
Ça c'est à mon sens la partie "un peu plus chiant que changer le gid"... mais si par hasard c'est systemd qui lance tes dhclients, ça peut se simplifier. Dans tous les cas, cgroups ou skgid, ça reste ton choix, le principe restant le même : un reroute-check basé sur une fwmark elle-même basée sur une propriété du processus possédant le file descriptor du socket utilisé pour émettre les paquets.
Résultat, ca a marché de suite, le RENEW de l'interface orange2 est passé direct !
\o/
Par contre, ne sachant pas trop, dois-je ajouter les lignes de markage cgroup dans la chain OUTPUT AVANT le "meta mark set ct mark" final ?
Moi je vote non. Tu es sur un cas de marquage très simple (UDP, sortant, pas d'état, pas de tracking, pas de paquets liés, rien), ne gâche pas ça en prenant le risque de l'écraser à cause d'un marquage conntrack présent ou futur.
Est-ce une bonne idée, je ne sais pas ... qu'en pensez-vous ? d'un point de vue perf, c'est surement mieux non ?
Les performances c'est bien mais la maintenabilité et la stabilité sont à prendre en compte aussi. Ne risque pas des heures de prises de tête dans le futur pour épargner 10 microsecondes ici et là.
Enfin, c'est vrai que ce serait plus simple sans utiliser les cgroup et d'arriver à marker les paquets avec une regle mangle/OUTPUT
Mais c'est ce que tu fais. Tu marques tes paquets dans mangle/OUTPUT. Et cette fois ça fonctionne.
mais compte-tenu des caractéristiques des paquets, avec l'ip source et l'interface qui correspondent bien (alors que c'est faux), j'avoue que je ne vois pas trop comment faire.
Je te sens encore très très confus sur le sujet, mais je ne peux que réitérer l'explication :
1 - la route choisie lors de l'émission du paquet par le processus est fausse parce qu'à ce stade le système n'a pas connaissance de la discrimination que tu souhaites implémenter. Cela lui assigne une IP source erronée et une interface de sortie erronée, ce qui ruine effectivement tes chances de filtrer sur ces éléments.
2 - marquer tes paquets dans mangle/OUTPUT t'offre la possibilité de réévaluer leur route, ce qui, combiné à une ip rule fwmark corrige leur interface de sortie (yay !)
3 - l'IP source est corrigée par le masquerading
4 - profit!
C'est peut-être plus simple et plus flexible, il suffirait de faire tourner les process dans leur groupe...
avec leur groupe :)
La question qui persiste, est de savoir s'il faut mettre les regles nft avant ou apres le 'meta mark set ct mark' final de la chain OUTPUT ?
Je confirme mon vote : skgid, après le "meta mark set ct mark".
Et dois-je marké les paquets dans les chains mangle/OUTPUT, mangle/PRETROUTING et mangle/POSTROUTING comme je le fais, ou bien mangle/OUTPUT et mangle/PREROUTING ne suffirait-il pas ?
Je ne suis pas sûr de te suivre pour cette dernière question ; je n'ai pas analysé l'intégralité de tes nftables mais je peux te confirmer que dans le cadre de cette histoire de discrimination sur les paquets DHCP sortants, il est nécessaire et suffisant de marquer ces paquets dans mangle/OUTPUT (ou devrais-je dire dans "type route hook output priority mangle").
-
À noter qu'utiliser skgid pour ton setup double-DHCP n'empêche nullement d'utiliser les cgroups pour la CoS (et les namespaces pour segmenter tout ça). À ce stade, tu as l'embarras du choix sur les techniques à employer pour avoir un setup fonctionnel et maintenable.
-
Salut,
À noter qu'utiliser skgid pour ton setup double-DHCP n'empêche nullement d'utiliser les cgroups pour la CoS (et les namespaces pour segmenter tout ça). À ce stade, tu as l'embarras du choix sur les techniques à employer pour avoir un setup fonctionnel et maintenable.
Effectivement, c'est ce que je fais pour la COS, c'est plus simple je trouve...
Je ne suis pas encore prêt pour les namespace, que je ne maîtrise pas...
Par contre, pour le RENEW DHCP, je trouve assez fastidieux de devoir mettre à jour le PID dans le fichier tasks. Si pour une raison ou une autre, la mise à jour du pid ne fonctionne pas, c'est un coup a chercher pendant des heures. le skgid, me semble plus simple pour cela.
Sinon, j'utilise effectivement systemd pour lancer les dhclient, quand tu dis qu'il y a des facilités cgroup, tu penses à quoi comme variable ? j'ai regardé vite fait et je n'est rien trouvé de spécial sur la partie cgroup/ip/routage.
Ensuite, quand je trouvais dommage de ne pas pouvoir utiliser uniquement une regles mangle/OUTPUT, je suggérais de se passer de tout autre mécanisme comme le skgid. Et donc en analysant uniquement les caractéristiques 'standards' des paquets RENEW.
De plus, visiblement les rules :
1: from all fwmark 0x100 ipproto udp sport 68 dport 67 lookup 100
2: from all fwmark 0x200 ipproto udp sport 68 dport 67 lookup 200
sont trop restrictives pour être évaluées, dès que je les remplace par :
1: from all fwmark 0x100 lookup 100
2: from all fwmark 0x200 lookup 200
ca fonctionne immédiatement. Pourquoi, je ne sais pas... Je vais essayer :
1: from all fwmark 0x100 ipproto udp dport 67 lookup 100
2: from all fwmark 0x200 ipproto udp dport 67 lookup 200
Mais je pense que je vais modifier mon script de config pour avoir ces rules :
0: from all lookup local
10: from all fwmark 0x100 lookup 100
20: from all fwmark 0x200 lookup 200
30: from all fwmark 0x300 lookup 300
50: from all fwmark 0x500 lookup 500
60: from all fwmark 0x600 lookup 600
70: from all fwmark 0x700 lookup 700
90: from all fwmark 0x900 lookup 900
100: from <iporange1> lookup 100
200: from <iporange2> lookup 200
300: from 192.168.4.254 lookup 300
500: from 192.168.251.2 lookup 500
600: from 10.4.117.244 lookup 600
700: from 10.2.0.244 lookup 700
900: from 10.3.2.244 lookup 900
32766: from all lookup main
32767: from all lookup default
ce sera bcp plus simple. En esperant que cela n'ai pas d'effet de bord particulier...
Qu'en penses-tu ?
-
Je ne suis pas encore prêt pour les namespace, que je ne maîtrise pas...
En fait, pour la petite histoire, j'ai utilisé ça au boulot pour simplifier un setup qui était devenu relativement complexe : marquage par uid, conntrack TCP, copie conntrack->fwmark, remplissage des tables de routage, reroute-check, masquerading uniquement pour corriger l'IP source, rp_filter=2 pour ne pas refuser les réponses, chacun de ces petits détails étant requis pour que la connexion TCP fonctionne correctement.
Là où ça a vraiment apporté un double gain de maintenabilité, c'est que le netns principal ne sert que pour une interface d'administration et une table de routage triviale. Le netns spécifique peut être détruit, modifié, cassé, manipulé par des outils d'automatisation (think: Puppet/SaltStack/Chef/Ansible) sans jamais risquer de perdre la connexion à la machine.
Et depuis je ne rêve que de segmenter toutes les manips réseaux qui constituent ma gateway en de petits netns (network namespaces) tout propres avec des tables de routage simples. Au détriment d'une perte de performances (théorique ? sensible ?) à mesure que le kernel s'amuse à faire circuler le trafic d'un namespace à un autre. Comme souvent en I.T., on ne peut pas tout avoir (performances maximales, maintenabilité, sécurité, pérennité).
À noter que les cgroups sont un pas vers les namespaces dans la mesure où ces deux technologies sont les principales fondations des containers sous Linux.
Par contre, pour le RENEW DHCP, je trouve assez fastidieux de devoir mettre à jour le PID dans le fichier tasks. Si pour une raison ou une autre, la mise à jour du pid ne fonctionne pas, c'est un coup a chercher pendant des heures. le skgid, me semble plus simple pour cela.
Alors, pour rendre à César ce qui est à César : le topic mentionné par zoc utilise des commandes cg* pour lancer dhclient directement dans le cgroup netprio adéquat plutôt que de l'y déplacer après lancement (= la race condition assurée).
Sinon, j'utilise effectivement systemd pour lancer les dhclient, quand tu dis qu'il y a des facilités cgroup, tu penses à quoi comme variable ? j'ai regardé vite fait et je n'est rien trouvé de spécial sur la partie cgroup/ip/routage.
systemd lance TOUT dans des cgroups dédiés... c'est tout simplement comme ça qu'il traque les processus relatifs à un service (finis les fichiers pid avec les race conditions qui vont avec). Tu peux voir ça avec systemd-cgls ou dans une moindre mesure avec systemctl status. Donc en théorie tu dois pouvoir simplement filtrer sur quelque chose comme -m cgroup --path system.slice/isc-dhcp-client@orange1.service (syntaxe iptables). Cela dit, j'ai comme l'impression que nftables n'offre pas les mêmes fonctionnalités qu'iptables pour matcher sur les cgroups (ça parle de matcher sur un cgroup number, je vois pas qui ça intéresse).
Ensuite, quand je trouvais dommage de ne pas pouvoir utiliser uniquement une regles mangle/OUTPUT, je suggérais de se passer de tout autre mécanisme comme le skgid. Et donc en analysant uniquement les caractéristiques 'standards' des paquets RENEW.
Ah oui, ça, c'est juste mort.
De plus, visiblement les rules [...]
Qu'en penses-tu ?
C'est marrant que ça ne fonctionne pas avec ipproto udp sport 68 dport 67, il y a peut-être un bug sous-jacent.
Mais pour réitérer mes recommandations : ne duplique pas tes discriminations. Tu as déjà discriminé sur UDP sport 68 dport 67 dans Netfilter/nftables et tu as associé cette discrimination aux fwmark 0x100 et 0x200. Plus besoin de répéter ces discriminations dans ip rule. Dans ip rule, tu mentionnes la fwmark, qui signifie non plus "le trafic DHCP machin truc" mais "ce qui doit être routé en utilisant la table de routage 0x100 / 0x200" et basta.
Je confirme que ça me semble une bonne idée de mettre toutes les ip rule fwmark en priorité. Si ça a des effets de bord, c'est probablement que tu as du trafic mal marqué.
Enfin, un mot sur toutes les rules "from x.x.x.x lookup xxx" : ces rules supposent que l'IP source est déjà connue et correcte au moment du routage. À manipuler avec précaution donc.
-
Re,
Tout d'abord je voudrais te remercier très chaleureusement (tout en respectant les gestes barrières...) pour ton aide et pour tes messages toujours aussi intéressants. C'est très instructif.
Pour les namespace, je vais creuser. Je me souviens avoir lu une petite doc sur wireguard et les namespace. Mais je ne sais pas si c'est applicable dans mon cas de gateway load-balancer multiwan. J'ai du routage évidemment, mais surtout du markage de paquets qui est (je pense) indispensable à mes use-cases. Si tu as une petite doc ou des liens interessants la-dessus, je suis preneur...
Enfin, pour mes rules "from x.x.x.x lookup xxx", je me demande si elles sont vraiment utiles ?
J'ai trouvé un petit script de config générique nftables / mutlwan : https://gist.github.com/elico/492d8f75f584ec1bed98b2a054a02cbb
On voit que dans ce script (je n'ai pas encore testé) :
- le markage se fait uniquement dans mangle/prerouting. Pas dans output ni postrouting.
- il y a juste une restauration dans mangle/postrouting.
- pas de rule "from x.x.x.x lookup xxx", uniquement "fmwark xxx lookup xxx"
Dans mon cas, je m'embête à marquer dans output, prerouting et postrouting. Est-ce bien utile ?
De même, je me demande si mes rules "from x.x.x.x lookup xxx" sont nécessaires ...
au plaisir de te lire... :)
-
Pour les namespace, je vais creuser. Je me souviens avoir lu une petite doc sur wireguard et les namespace. Mais je ne sais pas si c'est applicable dans mon cas de gateway load-balancer multiwan. J'ai du routage évidemment, mais surtout du markage de paquets qui est (je pense) indispensable à mes use-cases. Si tu as une petite doc ou des liens interessants la-dessus, je suis preneur...
Je n'ai pas spécialement de doc en tête mais d'après mon historique, j'avais lu ça : https://blog.scottlowe.org/2013/09/04/introducing-linux-network-namespaces/
À noter que le namespacing ne nuit normalement à aucune des techniques utilisées pour marquer, router ou filtrer des paquets (sauf peut-être les techniques qui souffriraient d'une segmentation physique).
J'ai chez moi un cas similaire mais plus simple (gateway + VPN + failover fibre->LTE) ; j'ai schématisé ce que ça donnerait si j'injectais un maximum de network namespaces, voir schéma ci-joint.
Enfin, pour mes rules "from x.x.x.x lookup xxx", je me demande si elles sont vraiment utiles ?
Je me suis posé la question aussi. De par l'apparente complexité de ton setup, je n'ai pas de réponse d'autorité à te fournir :)
J'ai trouvé un petit script de config générique nftables / mutlwan : https://gist.github.com/elico/492d8f75f584ec1bed98b2a054a02cbb
On voit que dans ce script (je n'ai pas encore testé) :
- le markage se fait uniquement dans mangle/prerouting. Pas dans output ni postrouting.
Dans mon cas, je m'embête à marquer dans output, prerouting et postrouting. Est-ce bien utile ?
mangle/output, c'est clairement un cas particulier pour rerouter du trafic local sortant, ton dhclient quoi.
mangle/prerouting a beaucoup de sens pour du trafic forwardé (le job principal d'un routeur quoi) parce qu'à ce niveau les paquets sont plus ou moins garantis frais/intacts/pas retouchés.
du marquage dans mangle/postrouting... effectivement, cette partie là n'a peut-être pas de sens, du moins pas pour influer sur le routing (puisque, par définition, dans postrouting, il est trop tard pour router ou re-router).
- il y a juste une restauration dans mangle/postrouting.
Elle ne semble pas servir à grand chose.
- pas de rule "from x.x.x.x lookup xxx", uniquement "fmwark xxx lookup xxx"
De même, je me demande si mes rules "from x.x.x.x lookup xxx" sont nécessaires ...
Clairement, si tout le trafic est marqué, les rules fwmark doivent suffire.
-
Je viens de trouver un tuto ddwrt où l’on voit qu’il y a bien les rule from xxx lookup xxx et le markage en postrouting egalement https://wiki.dd-wrt.com/wiki/index.php/Dual-WAN_for_simple_round-robin_load_equalization.
Il n’y a pas d’explication, mais il doit bien y avoir une raison...
-
Il n’y a pas d’explication, mais il doit bien y avoir une raison...
« copied from forum-posting by user aldoir Dual-WAN forum posting » -- peut-être parce qu'on est des milliers à adapter des confs trouvées ici et là à grands coups de copier-coller et qu'à force il s'y accumule des choses inutiles, comme du calcaire dans une machine à laver ? :)
Cela dit, ça met le doigt sur un autre principe important : toujours documenter le "pourquoi".
-
Du coup, j'ai modifié ma mangle/postrouting :
chain POSTROUTING {
type filter hook postrouting priority mangle; policy accept;
ct mark != 0x00000000 counter meta mark set ct mark
}
-> stocke le markage dans le paquet (je crois)
Mais j'ai hésité avec ca :
chain POSTROUTING {
type filter hook postrouting priority mangle; policy accept;
counter ct mark set mark
}
-> stocke le markage dans le conntrack (je crois)
Pour l'instant ca a l'air de tourner, je vais laisser tourner qques temps pour voir les effets.
Si tout est bon, je ferais de même avec la chaine mangle/OUTPUT (mais en conservant le markage DHCP bien sûr).
-
On te fait confiance pour réduire le nombre de lignes de configuration au strict minimum. Avec un peu de temps et de patience, tu dois pouvoir associer une explication à chaque ligne que tu conserves.
-
Bonjour,
de temps à autre, la liaison ne fonctionne plus et la seule manière de rétablir la connexion, est de re-démarrer dhclient. Aucune erreur particulière dans les logs.
Ceci se produit quand j'ai une désynchro VDSL coté modem. La liaison revient, mais dhclient n'est pas informé qu'il y a eu une coupure coté VDSL...
Y a t-il une option particulière dans dhclient pour automatiser ce restart ? j'ai regardé, rien vu de spécial...
une idée ?
merci.
-
C'est complètement hors-scope pour dhclient (il émet et reçoit des paquets sur une interface réseau, il ne monitore pas la santé des liens physiques en aval [ou amont, question de point de vue]). Cela dit, tu peux utiliser divers outils de monitoring pour surveiller ta connectivité et agir sur dhclient en conséquence. Par exemple, tu pourrais utiliser lsm avec un event script qui relance ton dhclient.
-
Merci, je me doutais bien de ta réponse :)
Sais-tu s'il y a un moyen propre de dire à un daemon DHCP existant de forcer son RENEW ? je n'ai rien vu dans le genre. j'ai bien essayé kill -1, mais le dhclient tombe.
J'aimerais éviter le restart pur et dur du process.
sinon, LSM, je ne connaissais pas, je vais jeter un oeil.
merci
-
Sais-tu s'il y a un moyen propre de dire à un daemon DHCP existant de forcer son RENEW ? je n'ai rien vu dans le genre. j'ai bien essayé kill -1, mais le dhclient tombe.
C'est spécifique à chaque implémentation. Dans le cas du client DHCP de l'ISC, il y a une interface « OMAPI » pour accéder à un « control object », mais honnêtement...
J'aimerais éviter le restart pur et dur du process.
... je ne pense pas que le jeu en vaille la chandelle. Claque un restart et basta :)
-
C'est spécifique à chaque implémentation. Dans le cas du client DHCP de l'ISC, il y a une interface « OMAPI » pour accéder à un « control object », mais honnêtement...
... je ne pense pas que le jeu en vaille la chandelle. Claque un restart et basta :)
J'arrive effectivement à cette même conclusion... J'ai ajouter un check dans mon watchdog sur les interfaces orange1 et orange2. Si elles sont HS (ping vers des IPs externes), restart le dhclient concerné.
C'est bourrin, mais ca marchera (enfin je crois).
merci en tout cas.