Bonjour les gens :)
Sur une machine, j'essaie de faire toute la conf réseau à coup de systemd-networkd, dans utiliser autre chose (notamment iptables).
Je butte sur le masquerading. Je détaille:
Le réseau sur eth0 est bien configuré et marche nickel.
J'ai un sous réseau sur eth1. Je veux le masquerader (?) quand il sort sous eth0. J'ai vu qu'il y a une option de systemd-networkd qui permettrait de faire ça. Je tente la conf suivante:
[Match]
Name=eth0
[Network]
Address=192.168.XXX/23
Gateway=192.168.XXX/23
DNS=192.168.XXX 4.4.4.4
IPMasquerade=ipv4
Et ça ne marche pas (pas d'erreur mais mes paquets sont jetés. Extraits d'un tcpdump sur eth1 :
16:52:18.131094 IP tarasque > 192.168.XXX: ICMP host tarasque unreachable - admin prohibited filter, length 74
Pourtant, ça a fait quelque-chose. J'ai bien ip_forward qui est passé à vrai grâce à systemd-controlld. Par contre, je ne vois aucune règle dans la chaine postrouting de la table NAT avec iptables.
J'ai gratté un peu dans les bugs de paquets debian, vu que l'intégration de la libiptc0 qui permet si j'ai bien compris de s'interfacer avec iptable, mais j'ai rien trouvé de concluant.
La page de Systemd-Networkd sur le wiki debian ne traite pas le forwarding.
Le man ne m'aide pas. J'ai rien dans les logs.
Je m'y prends sans doute mal. Une idée? Un bon doc à lire ?
Merci d'avance
EDIT: bon, de nos jours systemd-netword bascule sur nft si il est disponible (et il l'était).
J'ai bien une règle nft pour systemd :
table ip io.systemd.nat {
chain prerouting {
type nat hook prerouting priority dstnat + 1; policy accept;
}
chain output {
type nat hook output priority dstnat + 1; policy accept;
}
chain postrouting {
type nat hook postrouting priority srcnat + 1; policy accept;
}
}
mais je doute de sa validité: on y notifie ni interface, ni adresse.
# Le code, le code, le code ?
Posté par Cyril Brulebois (site web personnel) . Évalué à 2 (+0/-0).
(Il paraît que se répéter est à la mode, à la mode, à la mode…)
Quand lire la doc de la distribution (et des autres, notamment celle d'ArchLinux suggère qu'il peut manquer des morceaux…) ne suffit pas, j'ai tendance à aller regarder le code, et surtout l'historique.
Je te suggère donc ceci dans
systemd.git
:Certains messages de commit sont plutôt verbeux, par exemple 715a70e7218710d6a6c033e9157bf97fdf5d8ede, qui mentionne :
Et oui, la transition entre
iptables
etnftables
est complètement chaotique, puisque les deux sont co-installables (aveciptables
qui tirenftables
), des alternatives disponibles pouriptables
en modelegacy
ounft
mais bien évidemment, en fonction de comment les règles sont positionnées, les différents outils les voient ou non…Et bien évidemment, de nombreux outils continuent à dépendre (via
Depends
plutôt queRecommends
, donc non négociable…) d'iptables
, ce qui exclut de purger ce paquet pour limiter les interactions foireuses…En fonction de l'ensemble des paquets installés, tu peux essayer de virer
iptables
pour voir si ça aide.Si c'est plutôt un problème côté
systemd
, tu peux essayer de regarder ce que faitsrc/shared/firewall-util-nft.c
pour voir si ça te donne une piste quant à un éventuel réglage manquant dans ta configuration ?Enfin, il existe un backport pour Debian stable, si tu soupçonnes un éventuel problème upstream qui serait déjà corrigé, mais ça fait plein de paquets à mettre à jour (dont
udev
et différentes bibliothèques), et c'est un peu pénible de revenir en arrière ensuite.Debian Consultant @ DEBAMAX
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.