Forum Linux.debian/ubuntu Debian, systemd-networkd, masquerading et libiptc0

Posté par Trollgouin le 08 octobre 2024 à 17:16. Licence CC By‑SA.

Étiquettes : aucune

oct.

2024

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) le 09 octobre 2024 à 05:34. É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 :
```
git log --grep IPMasquerade
```
Certains messages de commit sont plutôt verbeux, par exemple 715a70e7218710d6a6c033e9157bf97fdf5d8ede, qui mentionne :
```
table ip io.systemd.nat {
        set masq_saddr {
                type ipv4_addr
                flags interval
                elements = { 192.168.59.160/28 }
        }
[…]
        chain postrouting {
                type nat hook postrouting priority srcnat + 1; policy accept;
                ip saddr @masq_saddr masquerade
        }
}
```
Et oui, la transition entre iptables et nftables est complètement chaotique, puisque les deux sont co-installables (avec iptables qui tire nftables), des alternatives disponibles pour iptables en mode legacy ou nft 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 que Recommends, 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 fait src/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
Répondre

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.

# Le code, le code, le code ?