Je maintiens depuis des ann=C3=A9es un script qui configure le firewalling =
sur
des serveurs.
Ce script est install=C3=A9 dans /etc/network/if-pre-up.d
Il comprend une bonne trentaine de r=C3=A8gles iptables dont des r=C3=A8gle=
s pour le
NAT.
J'ai lu que Linux rempla=C3=A7ait iptables par nftables.
Par ailleurs, la technologie eBPF semble aussi tr=C3=A8s prometteuse.
J'ai toute confiance sur l'existence dans Buster et ses successeurs de
moyens pour conserver le bon fonctionnement de scripts iptables.
N=C3=A9anmoins, je me demande si le moment n'est pas le bienvenu pour juste=
ment
pour sauter le pas en r=C3=A9=C3=A9crivant mes scripts iptables avec autre =
chose.
On annonce ici ou l=C3=A0:
- une plus grande p=C3=A9rennit=C3=A9
- de meilleurs performances
- une syntaxe plus simple.
Je serai tr=C3=A8s heureux d'=C3=A9changer ici des r=C3=A9flexions sur le s=
ujet.
Voici en vrac quelques questions et r=C3=A9flexions:
1. Avez-vous un retour d'exp=C3=A9rience positif ou non sur un passage
d'iptables =C3=A0 firewalld, en g=C3=A9n=C3=A9ral (ie sur Stretch, Jessie, =
...) ?
2. Trouvez-vous facilement de l'aide (mailing lists, documentation en
ligne, publications, ...) sur la version 0.6.3 de firewalld (celle de
Buster) ?
3. Comme le sugg=C3=A8re la r=C3=A9ponse =C3=A0 une question dans [1], doit=
-on vraiment
voir eBPF comme une cuisine interne =C3=A0 Linux et se focaliser sur firewa=
lld ?
<div dir=3D"ltr"><div dir=3D"ltr"><div>Bonjour,</div><div><br></div><div>Je=
maintiens depuis des ann=C3=A9es un script qui configure le firewalling su=
r des serveurs.</div><div>Ce script est install=C3=A9 dans /etc/network/if-=
pre-up.d</div><div>Il comprend une bonne trentaine de r=C3=A8gles iptables =
dont des r=C3=A8gles pour le NAT.</div><div><br></div><div>J'ai lu que =
Linux rempla=C3=A7ait iptables par nftables.</div><div>Par ailleurs, la tec=
hnologie eBPF semble aussi tr=C3=A8s prometteuse.</div><div><br></div><div>=
J'ai toute confiance sur l'existence dans Buster et ses successeurs=
de moyens pour conserver le bon fonctionnement de scripts iptables.</div><=
div>N=C3=A9anmoins, je me demande si le moment n'est pas le bienvenu po=
ur justement pour sauter le pas en r=C3=A9=C3=A9crivant mes scripts iptable=
s avec autre chose.</div><div><br></div><div>On annonce ici ou l=C3=A0:</di=
v><div>- une plus grande p=C3=A9rennit=C3=A9</div><div>- de meilleurs perfo=
rmances</div><div>- une syntaxe plus simple.</div><div><br></div><div>Je se=
rai tr=C3=A8s heureux d'=C3=A9changer ici des r=C3=A9flexions sur le su=
jet.</div><div>Voici en vrac quelques questions et r=C3=A9flexions:</div><d=
iv><br></div><div>1. Avez-vous un retour d'exp=C3=A9rience positif ou n=
on sur un passage d'iptables =C3=A0 firewalld, en g=C3=A9n=C3=A9ral (ie=
sur Stretch, Jessie, ...) ?</div><div><br></div><div>2. Trouvez-vous facil=
ement de l'aide (mailing lists, documentation en ligne, publications, .=
..) sur la version 0.6.3 de firewalld (celle de Buster) ?</div><div><br></d=
iv><div>3. Comme le sugg=C3=A8re la r=C3=A9ponse =C3=A0 une question dans [=
1], doit-on vraiment voir eBPF comme une cuisine interne =C3=A0 Linux et se=
focaliser sur firewalld ?</div><div><br></div><div>4. Commentaires et sugg=
estions ?</div><div><br></div><div></div><div>[1] <a href=3D"https://develo=
pers.redhat.com/blog/2018/08/10/firewalld-the-future-is-nftables/">https://=
developers.redhat.com/blog/2018/08/10/firewalld-the-future-is-nftables/</a>=
</div><div><br></div><div>Slts<br></div><div><br></div></div></div>
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
didier gaumet
Le 11/01/2019 à 15:44, Wallace a écrit :
Bonjour, Merci d'avoir lancé le sujet qui trottait dans mon esprit. Actuellement on gère iptables grâce à Shorewall qui fait très bien le travail et permet de retrouver une lecture similaire à une configuration de firewall appliance. C'est pratique pour que tout le monde soit au diapason sur la lecture. Y a Ferm qui fait pareil aussi. Shorewall a déjà annoncé qu'il ne partirait pas dans ce chantier de refonte étant trop lié à iptables. Personnellement je n'ai rien à reprocher à iptables et j'envisage donc de continuer de l'utiliser. Mais si l'on est bloqué par une suppression de iptables et obligation de passer sur nftables alors il va falloir anticiper. Il y a du coup deux questions : - y a t il eu une annonce quand on retrait du kernel ou le End Of Life de iptables? - nftables est il forcément lié à firewalld? ou est-ce que l'on peut parler directement au kernel comme avant?
Alors je suis une truffe pour tout ce qui est réseaux mais j'ai quand même l'impression qu'il y a un quiproquo sur nftables/firewalld, non? Firewalld n'est qu'une surcouche à, auparavant iptables, désormais nftables? Un peu comme Shorewall D'après ce que j'ai compris, le paquet iptables sera dans la prochaine version Debian et ne sera pas un pseudo-paquet pointant vers nftables, mais utilisera le backend nftables dans le noyau mais en conservant la syntaxe iptables? Et si on souhaite utiliser véritablement nftables, il est possible (au moins pour le moment) d'utiliser l'ancienne syntaxe iptables ou la nouvelle syntaxe dédiée nftables? Didier, truffe réseau en mal de culture ad-hoc ;-)
Le 11/01/2019 à 15:44, Wallace a écrit :
Bonjour,
Merci d'avoir lancé le sujet qui trottait dans mon esprit.
Actuellement on gère iptables grâce à Shorewall qui fait très bien le
travail et permet de retrouver une lecture similaire à une configuration
de firewall appliance. C'est pratique pour que tout le monde soit au
diapason sur la lecture. Y a Ferm qui fait pareil aussi.
Shorewall a déjà annoncé qu'il ne partirait pas dans ce chantier de
refonte étant trop lié à iptables.
Personnellement je n'ai rien à reprocher à iptables et j'envisage donc
de continuer de l'utiliser. Mais si l'on est bloqué par une suppression
de iptables et obligation de passer sur nftables alors il va falloir
anticiper.
Il y a du coup deux questions :
- y a t il eu une annonce quand on retrait du kernel ou le End Of Life
de iptables?
- nftables est il forcément lié à firewalld? ou est-ce que l'on peut
parler directement au kernel comme avant?
Alors je suis une truffe pour tout ce qui est réseaux mais j'ai quand
même l'impression qu'il y a un quiproquo sur nftables/firewalld, non?
Firewalld n'est qu'une surcouche à, auparavant iptables, désormais
nftables? Un peu comme Shorewall
D'après ce que j'ai compris, le paquet iptables sera dans la prochaine
version Debian et ne sera pas un pseudo-paquet pointant vers nftables,
mais utilisera le backend nftables dans le noyau mais en conservant la
syntaxe iptables? Et si on souhaite utiliser véritablement nftables, il
est possible (au moins pour le moment) d'utiliser l'ancienne syntaxe
iptables ou la nouvelle syntaxe dédiée nftables?
Didier, truffe réseau en mal de culture ad-hoc ;-)
Bonjour, Merci d'avoir lancé le sujet qui trottait dans mon esprit. Actuellement on gère iptables grâce à Shorewall qui fait très bien le travail et permet de retrouver une lecture similaire à une configuration de firewall appliance. C'est pratique pour que tout le monde soit au diapason sur la lecture. Y a Ferm qui fait pareil aussi. Shorewall a déjà annoncé qu'il ne partirait pas dans ce chantier de refonte étant trop lié à iptables. Personnellement je n'ai rien à reprocher à iptables et j'envisage donc de continuer de l'utiliser. Mais si l'on est bloqué par une suppression de iptables et obligation de passer sur nftables alors il va falloir anticiper. Il y a du coup deux questions : - y a t il eu une annonce quand on retrait du kernel ou le End Of Life de iptables? - nftables est il forcément lié à firewalld? ou est-ce que l'on peut parler directement au kernel comme avant?
Alors je suis une truffe pour tout ce qui est réseaux mais j'ai quand même l'impression qu'il y a un quiproquo sur nftables/firewalld, non? Firewalld n'est qu'une surcouche à, auparavant iptables, désormais nftables? Un peu comme Shorewall D'après ce que j'ai compris, le paquet iptables sera dans la prochaine version Debian et ne sera pas un pseudo-paquet pointant vers nftables, mais utilisera le backend nftables dans le noyau mais en conservant la syntaxe iptables? Et si on souhaite utiliser véritablement nftables, il est possible (au moins pour le moment) d'utiliser l'ancienne syntaxe iptables ou la nouvelle syntaxe dédiée nftables? Didier, truffe réseau en mal de culture ad-hoc ;-)
Olivier
--000000000000d69128057f312eae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le ven. 11 janv. 2019 à 16:24, Wallace a éc rit :
Ca voudrait donc dire que iptables ne fait plus parti du kernel? Je pense que des scripts iptables fonctionneront sans modification pendan t
encore de longues années. Pour une machine "ancienne", on devrait pouvoir la passer à Buster san s modification. Par contre, pour une nouvelle machine, je pense qu'on peut avoir intér êt à se poser la question d'une autre syntaxe ou d'un autre niveau d'abstraction . --000000000000d69128057f312eae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"> <div dir="ltr">Le ven. 11 janv. 2019 à 16:24, Wallace < <a href="mailto:"></a>> a é crit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> Ca voudrait donc dire que iptables ne fait plus parti du kernel?<br> <br> <br><div>Je pense que des scripts iptables fonctionneront sans modification pendant encore de longues années.</div><div>Pour une mac hine "ancienne", on devrait pouvoir la passer à Buster sans modification.</div><div><br></div><div>Par contre, pour une nouvelle machin e, je pense qu'on peut avoir intérêt à se poser la quest ion d'une autre syntaxe ou d'un autre niveau d'abstraction.<br> </div></div></div> --000000000000d69128057f312eae--
Le ven. 11 janv. 2019 à 16:24, Wallace <wallace@morkitu.org> a éc rit :
Ca voudrait donc dire que iptables ne fait plus parti du kernel?
Je pense que des scripts iptables fonctionneront sans modification pendan t
encore de longues années.
Pour une machine "ancienne", on devrait pouvoir la passer à Buster san s
modification.
Par contre, pour une nouvelle machine, je pense qu'on peut avoir intér êt à
se poser la question d'une autre syntaxe ou d'un autre niveau d'abstraction .
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"> <div dir="ltr">Le ven. 11 janv. 2019 à 16:24, Wallace < <a href="mailto:wallace@morkitu.org">wallace@morkitu.org</a>> a é crit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Ca voudrait donc dire que iptables ne fait plus parti du kernel?<br>
<br>
<br></blockquote><div>Je pense que des scripts iptables fonctionneront sans modification pendant encore de longues années.</div><div>Pour une mac hine "ancienne", on devrait pouvoir la passer à Buster sans modification.</div><div><br></div><div>Par contre, pour une nouvelle machin e, je pense qu'on peut avoir intérêt à se poser la quest ion d'une autre syntaxe ou d'un autre niveau d'abstraction.<br> </div></div></div>
--000000000000d69128057f312eae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le ven. 11 janv. 2019 à 16:24, Wallace a éc rit :
Ca voudrait donc dire que iptables ne fait plus parti du kernel? Je pense que des scripts iptables fonctionneront sans modification pendan t
encore de longues années. Pour une machine "ancienne", on devrait pouvoir la passer à Buster san s modification. Par contre, pour une nouvelle machine, je pense qu'on peut avoir intér êt à se poser la question d'une autre syntaxe ou d'un autre niveau d'abstraction . --000000000000d69128057f312eae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"> <div dir="ltr">Le ven. 11 janv. 2019 à 16:24, Wallace < <a href="mailto:"></a>> a é crit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> Ca voudrait donc dire que iptables ne fait plus parti du kernel?<br> <br> <br><div>Je pense que des scripts iptables fonctionneront sans modification pendant encore de longues années.</div><div>Pour une mac hine "ancienne", on devrait pouvoir la passer à Buster sans modification.</div><div><br></div><div>Par contre, pour une nouvelle machin e, je pense qu'on peut avoir intérêt à se poser la quest ion d'une autre syntaxe ou d'un autre niveau d'abstraction.<br> </div></div></div> --000000000000d69128057f312eae--
Olivier
--0000000000006f6170057f31d2c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le ven. 11 janv. 2019 à 17:55, Wallace a éc rit :
Clairement vu ce que je ressort de la conversation, quitte à faire u n saut autant sauter directement à BPF.
Justement, j'ai compris que BPF, c'était la cuisine interne de Linux: on configure avec nftables ou firewalld ou autre et c'est nftables qui s'appuie sur BPF à l'insu de l'administrateur. Bien entendu, je peux avoir compris de travers et je serai ravi qu'une personne plus qualifiée que moi me corrige ;-))) --0000000000006f6170057f31d2c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"> <div dir="ltr">Le ven. 11 janv. 2019 à 17:55, Wallace < <a href="mailto:"></a>> a é crit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div bgcolor="#FFFFFF"><p>Clairement vu ce que je ressort de la convers ation, quitte à faire un saut autant sauter directement à BPF.<br></p></div></bl ockquote><div>Justement, j'ai compris que BPF, c'était la cuis ine interne de Linux: on configure avec nftables ou firewalld ou autre et c 'est nftables qui s'appuie sur BPF à l'insu de l'admin istrateur.</div><div>Bien entendu, je peux avoir compris de travers e t je serai ravi qu'une personne plus qualifiée que moi me corrige ;-)))</div></div></div> --0000000000006f6170057f31d2c8--
Le ven. 11 janv. 2019 à 17:55, Wallace <wallace@morkitu.org> a éc rit :
Clairement vu ce que je ressort de la conversation, quitte à faire u n saut
autant sauter directement à BPF.
Justement, j'ai compris que BPF, c'était la cuisine interne de Linux: on
configure avec nftables ou firewalld ou autre et c'est nftables qui
s'appuie sur BPF à l'insu de l'administrateur.
Bien entendu, je peux avoir compris de travers et je serai ravi qu'une
personne plus qualifiée que moi me corrige ;-)))
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"> <div dir="ltr">Le ven. 11 janv. 2019 à 17:55, Wallace < <a href="mailto:wallace@morkitu.org">wallace@morkitu.org</a>> a é crit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><p>Clairement vu ce que je ressort de la convers ation, quitte à
faire un saut autant sauter directement à BPF.<br></p></div></bl ockquote><div>Justement, j'ai compris que BPF, c'était la cuis ine interne de Linux: on configure avec nftables ou firewalld ou autre et c 'est nftables qui s'appuie sur BPF à l'insu de l'admin istrateur.</div><div>Bien entendu, je peux avoir compris de travers e t je serai ravi qu'une personne plus qualifiée que moi me corrige ;-)))</div></div></div>
--0000000000006f6170057f31d2c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le ven. 11 janv. 2019 à 17:55, Wallace a éc rit :
Clairement vu ce que je ressort de la conversation, quitte à faire u n saut autant sauter directement à BPF.
Justement, j'ai compris que BPF, c'était la cuisine interne de Linux: on configure avec nftables ou firewalld ou autre et c'est nftables qui s'appuie sur BPF à l'insu de l'administrateur. Bien entendu, je peux avoir compris de travers et je serai ravi qu'une personne plus qualifiée que moi me corrige ;-))) --0000000000006f6170057f31d2c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"> <div dir="ltr">Le ven. 11 janv. 2019 à 17:55, Wallace < <a href="mailto:"></a>> a é crit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div bgcolor="#FFFFFF"><p>Clairement vu ce que je ressort de la convers ation, quitte à faire un saut autant sauter directement à BPF.<br></p></div></bl ockquote><div>Justement, j'ai compris que BPF, c'était la cuis ine interne de Linux: on configure avec nftables ou firewalld ou autre et c 'est nftables qui s'appuie sur BPF à l'insu de l'admin istrateur.</div><div>Bien entendu, je peux avoir compris de travers e t je serai ravi qu'une personne plus qualifiée que moi me corrige ;-)))</div></div></div> --0000000000006f6170057f31d2c8--
didier gaumet
Le 11/01/2019 à 18:13, Olivier a écrit :
Justement, j'ai compris que BPF, c'était la cuisine interne de Linux: on configure avec nftables ou firewalld ou autre et c'est nftables qui s'appuie sur BPF à l'insu de l'administrateur. Bien entendu, je peux avoir compris de travers et je serai ravi qu'une personne plus qualifiée que moi me corrige ;-)))
Je connaissais l'existence des différentes versions de (Berkeley) Packet Filter ((B)PF) dans les différentes versions de BSD en tant que pare-feu. De ce que je crois comprendre, Linux utilise déjà certaines briques de l'infrastructure BPF (qui serait une interface aux couches réseau plus qu'un simple pare-feu) et dont la pure partie pare-feu n'aurait jamais été intégrée à Linux ni à ses distributions. eBPF est la prochaine itération de BPF qui semble offrir des possibilités tellement avantageuses par rapport à l'existant que Linux cherche à en profiter, l'une des possibilités étant de la faire fonctionner en coordination avec nftables. Tout ça au conditionnel parce que signé La Truffe Réseau ;-)
Le 11/01/2019 à 18:13, Olivier a écrit :
Justement, j'ai compris que BPF, c'était la cuisine interne de Linux: on
configure avec nftables ou firewalld ou autre et c'est nftables qui
s'appuie sur BPF à l'insu de l'administrateur.
Bien entendu, je peux avoir compris de travers et je serai ravi qu'une
personne plus qualifiée que moi me corrige ;-)))
Je connaissais l'existence des différentes versions de (Berkeley) Packet
Filter ((B)PF) dans les différentes versions de BSD en tant que pare-feu.
De ce que je crois comprendre, Linux utilise déjà certaines briques de
l'infrastructure BPF (qui serait une interface aux couches réseau plus
qu'un simple pare-feu) et dont la pure partie pare-feu n'aurait jamais
été intégrée à Linux ni à ses distributions. eBPF est la prochaine
itération de BPF qui semble offrir des possibilités tellement
avantageuses par rapport à l'existant que Linux cherche à en profiter,
l'une des possibilités étant de la faire fonctionner en coordination
avec nftables.
Tout ça au conditionnel parce que signé La Truffe Réseau ;-)
Justement, j'ai compris que BPF, c'était la cuisine interne de Linux: on configure avec nftables ou firewalld ou autre et c'est nftables qui s'appuie sur BPF à l'insu de l'administrateur. Bien entendu, je peux avoir compris de travers et je serai ravi qu'une personne plus qualifiée que moi me corrige ;-)))
Je connaissais l'existence des différentes versions de (Berkeley) Packet Filter ((B)PF) dans les différentes versions de BSD en tant que pare-feu. De ce que je crois comprendre, Linux utilise déjà certaines briques de l'infrastructure BPF (qui serait une interface aux couches réseau plus qu'un simple pare-feu) et dont la pure partie pare-feu n'aurait jamais été intégrée à Linux ni à ses distributions. eBPF est la prochaine itération de BPF qui semble offrir des possibilités tellement avantageuses par rapport à l'existant que Linux cherche à en profiter, l'une des possibilités étant de la faire fonctionner en coordination avec nftables. Tout ça au conditionnel parce que signé La Truffe Réseau ;-)
Thierry Despeyroux
non pas de date fixée Le Fri, 11 Jan 2019 16:23:44 +0100, Wallace a écrit :
Le 11/01/2019 à 16:05, didier gaumet a écrit :
Alors je suis une truffe pour tout ce qui est réseaux mais j'ai quand même l'impression qu'il y a un quiproquo sur nftables/firewalld, non? Firewalld n'est qu'une surcouche à, auparavant iptables, déso rmais nftables? Un peu comme Shorewall
Aucune idée je n'ai pas encore creusé le sujet.
D'après ce que j'ai compris, le paquet iptables sera dans la prochaine version Debian et ne sera pas un pseudo-paquet pointant vers nftables, mais utilisera le backend nftables dans le noyau mais en conservant la syntaxe iptables? Et si on souhaite utiliser véritablement nftables, il est possible (au moins pour le moment) d'utiliser l'ancienne syntaxe iptables ou la nouvelle syntaxe dédiée nftables?
Ca voudrait donc dire que iptables ne fait plus parti du kernel? J'ai rien trouvé en news à ce sujet. Néanmoins quand on voit un article comme celui là : https://cilium.io/blog/2018/04/17/why-is-the-kernel-community-replacing-i ptables/ On peut se dire que nftables est un remplaçant à peine plus performant. BPF semble bien plus prometteur pour les réseaux à plus de 10Gbs.
Didier, truffe réseau en mal de culture ad-hoc ;-)
On ne peut pas tout maitriser et j'avoue avoir un peu lâcher ce sujet vu qu'iptables fait le boulot et qu'on a pas encore été confron té à des interfaces à plus de 10Gbs...
non pas de date fixée
Le Fri, 11 Jan 2019 16:23:44 +0100,
Wallace <wallace@morkitu.org> a écrit :
Le 11/01/2019 à 16:05, didier gaumet a écrit :
>
> Alors je suis une truffe pour tout ce qui est réseaux mais j'ai
> quand même l'impression qu'il y a un quiproquo sur
> nftables/firewalld, non?
>
> Firewalld n'est qu'une surcouche à, auparavant iptables, déso rmais
> nftables? Un peu comme Shorewall
Aucune idée je n'ai pas encore creusé le sujet.
>
> D'après ce que j'ai compris, le paquet iptables sera dans la
> prochaine version Debian et ne sera pas un pseudo-paquet pointant
> vers nftables, mais utilisera le backend nftables dans le noyau
> mais en conservant la syntaxe iptables? Et si on souhaite utiliser
> véritablement nftables, il est possible (au moins pour le moment)
> d'utiliser l'ancienne syntaxe iptables ou la nouvelle syntaxe
> dédiée nftables?
Ca voudrait donc dire que iptables ne fait plus parti du kernel?
J'ai rien trouvé en news à ce sujet.
Néanmoins quand on voit un article comme celui là :
On peut se dire que nftables est un remplaçant à peine plus
performant. BPF semble bien plus prometteur pour les réseaux à plus
de 10Gbs.
>
> Didier, truffe réseau en mal de culture ad-hoc ;-)
On ne peut pas tout maitriser et j'avoue avoir un peu lâcher ce sujet
vu qu'iptables fait le boulot et qu'on a pas encore été confron té à
des interfaces à plus de 10Gbs...
non pas de date fixée Le Fri, 11 Jan 2019 16:23:44 +0100, Wallace a écrit :
Le 11/01/2019 à 16:05, didier gaumet a écrit :
Alors je suis une truffe pour tout ce qui est réseaux mais j'ai quand même l'impression qu'il y a un quiproquo sur nftables/firewalld, non? Firewalld n'est qu'une surcouche à, auparavant iptables, déso rmais nftables? Un peu comme Shorewall
Aucune idée je n'ai pas encore creusé le sujet.
D'après ce que j'ai compris, le paquet iptables sera dans la prochaine version Debian et ne sera pas un pseudo-paquet pointant vers nftables, mais utilisera le backend nftables dans le noyau mais en conservant la syntaxe iptables? Et si on souhaite utiliser véritablement nftables, il est possible (au moins pour le moment) d'utiliser l'ancienne syntaxe iptables ou la nouvelle syntaxe dédiée nftables?
Ca voudrait donc dire que iptables ne fait plus parti du kernel? J'ai rien trouvé en news à ce sujet. Néanmoins quand on voit un article comme celui là : https://cilium.io/blog/2018/04/17/why-is-the-kernel-community-replacing-i ptables/ On peut se dire que nftables est un remplaçant à peine plus performant. BPF semble bien plus prometteur pour les réseaux à plus de 10Gbs.
Didier, truffe réseau en mal de culture ad-hoc ;-)
On ne peut pas tout maitriser et j'avoue avoir un peu lâcher ce sujet vu qu'iptables fait le boulot et qu'on a pas encore été confron té à des interfaces à plus de 10Gbs...
