Je suis d'accord en ce qui concerne cet exemple. Avec pf c'est plus lisible et plus abordable.
Par contre je suis plus mitigé en ce qui concerne un exemple compliqué, par exemple un grand nombre de serveurs avec du nat.
Dans ce cas, moi qui ait appris à maîtriser la syntaxe netfilter (dans la douleur, certes), pf me pose des soucis. Par exemple, je n'arrive pas à saisir le cheminement d'un paquet dans les différentes règles. Avec netfilter, à défaut d'être simple et clair c'est bien expliqué, y'a même un schéma [1].
Je n'ai jamais été fichu de me mettre dans la tête à quoi faisait référence « in » et « out » : à l'interface ? au système ?
Intellectuellement j'aurais envie de dire l'interface, mais à chaque fois j'ai un doute.
Autre chose qui fait que c'est parfois pas facile à lire, toujours dans le cas d'un grand nombre de serveurs avec du nat, c'est qu'on est obligé de mettre d'abord les règles de nat etc, et ensuite les règles de filtrage. Pas moyen de faire des blocs de règles nat + filtrage par serveur par exemple.
Après, qu'on ne me fasse pas dire ce que je n'ai pas dit, techniquement je n'ai rien à reprocher à pf bien au contraire. Notamment la notion d'ancres (dommage qu'on ne puisse pas hériter des macros) et de tables est géniale (netfilter a ipset mais c'est plus compliqué à mettre en oeuvre). Ah si, un truc qui m'embête quand même : l'absence de conntrack pour le ftp. ftp-proxy, sur un grand nombre de serveurs NATés, c'est pas gérable [2].
[1] http://fr.wikipedia.org/wiki/Fichier:Netfilter_schema.png - Si quelqu'un me trouve l'équivalent pour PF je suis preneur.
[2] oui, le NAT c'est mal, et le ftp aussi, mais il faut bien faire avec l'existant, et c'est quand même bien pratique.
[^] # Re: claire
Posté par nodens . En réponse au journal Script Iptables. Évalué à 3.
Par contre je suis plus mitigé en ce qui concerne un exemple compliqué, par exemple un grand nombre de serveurs avec du nat.
Dans ce cas, moi qui ait appris à maîtriser la syntaxe netfilter (dans la douleur, certes), pf me pose des soucis. Par exemple, je n'arrive pas à saisir le cheminement d'un paquet dans les différentes règles. Avec netfilter, à défaut d'être simple et clair c'est bien expliqué, y'a même un schéma [1].
Je n'ai jamais été fichu de me mettre dans la tête à quoi faisait référence « in » et « out » : à l'interface ? au système ?
Intellectuellement j'aurais envie de dire l'interface, mais à chaque fois j'ai un doute.
Autre chose qui fait que c'est parfois pas facile à lire, toujours dans le cas d'un grand nombre de serveurs avec du nat, c'est qu'on est obligé de mettre d'abord les règles de nat etc, et ensuite les règles de filtrage. Pas moyen de faire des blocs de règles nat + filtrage par serveur par exemple.
Après, qu'on ne me fasse pas dire ce que je n'ai pas dit, techniquement je n'ai rien à reprocher à pf bien au contraire. Notamment la notion d'ancres (dommage qu'on ne puisse pas hériter des macros) et de tables est géniale (netfilter a ipset mais c'est plus compliqué à mettre en oeuvre). Ah si, un truc qui m'embête quand même : l'absence de conntrack pour le ftp. ftp-proxy, sur un grand nombre de serveurs NATés, c'est pas gérable [2].
[1] http://fr.wikipedia.org/wiki/Fichier:Netfilter_schema.png - Si quelqu'un me trouve l'équivalent pour PF je suis preneur.
[2] oui, le NAT c'est mal, et le ftp aussi, mais il faut bien faire avec l'existant, et c'est quand même bien pratique.