Je recherche des données pour optimiser un firewall sous
Netfilter. Par exemple, vaut-il mieux faire des règles à rallonge ou
restreindre les règles à un seul matching et utiliser les chaînes.
Plus précisément, qu'est-ce qui est, a priori, le plus rapide :
iptables -A FORWARD -i eth0 -o eth1 -j CHAINE
iptables -A CHAINE --source machin -j ACCEPT
iptables -A CHAINE --destination truc -j ACCEPT
--
Parenthesise to avoid ambiguity.
- The Elements of Programming Style (Kernighan & Plauger)
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
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
Emmanuel Fleury
Bonjour Vincent,
Vincent Bernat wrote:
Je recherche des données pour optimiser un firewall sous Netfilter. Par exemple, vaut-il mieux faire des règles à rallonge ou restreindre les règles à un seul matching et utiliser les chaînes.
Plus précisément, qu'est-ce qui est, a priori, le plus rapide :
iptables -A FORWARD -i eth0 -o eth1 -j CHAINE iptables -A CHAINE --source machin -j ACCEPT iptables -A CHAINE --destination truc -j ACCEPT
Je te conseille d'aller voir du coté de ipset. Voir: http://ipset.netfilter.org/
Amicalement -- Emmanuel Fleury
Anyone who has never made a mistake has never tried anything new. -- Albert Einstein
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Bonjour Vincent,
Vincent Bernat wrote:
Je recherche des données pour optimiser un firewall sous
Netfilter. Par exemple, vaut-il mieux faire des règles à rallonge ou
restreindre les règles à un seul matching et utiliser les chaînes.
Plus précisément, qu'est-ce qui est, a priori, le plus rapide :
iptables -A FORWARD -i eth0 -o eth1 -j CHAINE
iptables -A CHAINE --source machin -j ACCEPT
iptables -A CHAINE --destination truc -j ACCEPT
Je te conseille d'aller voir du coté de ipset.
Voir: http://ipset.netfilter.org/
Amicalement
--
Emmanuel Fleury
Anyone who has never made a mistake has never tried anything new.
-- Albert Einstein
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Je recherche des données pour optimiser un firewall sous Netfilter. Par exemple, vaut-il mieux faire des règles à rallonge ou restreindre les règles à un seul matching et utiliser les chaînes.
Plus précisément, qu'est-ce qui est, a priori, le plus rapide :
iptables -A FORWARD -i eth0 -o eth1 -j CHAINE iptables -A CHAINE --source machin -j ACCEPT iptables -A CHAINE --destination truc -j ACCEPT
Je te conseille d'aller voir du coté de ipset. Voir: http://ipset.netfilter.org/
Amicalement -- Emmanuel Fleury
Anyone who has never made a mistake has never tried anything new. -- Albert Einstein
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Vincent Bernat
OoO Vers la fin de l'après-midi du vendredi 02 décembre 2005, vers 16:44, Emmanuel Fleury disait:
Plus précisément, qu'est-ce qui est, a priori, le plus rapide :
iptables -A FORWARD -i eth0 -o eth1 -j CHAINE iptables -A CHAINE --source machin -j ACCEPT iptables -A CHAINE --destination truc -j ACCEPT
Je te conseille d'aller voir du coté de ipset. Voir: http://ipset.netfilter.org/
ipset permet en effet d'accélérer le traitement quand on cherche à matcher un grand nombre de sources, un grand nombre de destinations, un grand nombre de ports, etc, mais dans mon cas, c'est beaucoup plus éthérogène.
Il s'agit de savoir s'il vaut mieux factoriser dans une chaîne certains matchings (comme dans l'exemple ci-dessus) ou si le fait de sauter dans une chaîne est assez coûteux. -- panic("esp_handle: current_SC == penguin within interrupt!"); 2.2.16 /usr/src/linux/drivers/scsi/esp.c
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
OoO Vers la fin de l'après-midi du vendredi 02 décembre 2005, vers
16:44, Emmanuel Fleury <emmanuel.fleury@labri.fr> disait:
Plus précisément, qu'est-ce qui est, a priori, le plus rapide :
iptables -A FORWARD -i eth0 -o eth1 -j CHAINE
iptables -A CHAINE --source machin -j ACCEPT
iptables -A CHAINE --destination truc -j ACCEPT
Je te conseille d'aller voir du coté de ipset.
Voir: http://ipset.netfilter.org/
ipset permet en effet d'accélérer le traitement quand on cherche à
matcher un grand nombre de sources, un grand nombre de destinations,
un grand nombre de ports, etc, mais dans mon cas, c'est beaucoup plus
éthérogène.
Il s'agit de savoir s'il vaut mieux factoriser dans une chaîne
certains matchings (comme dans l'exemple ci-dessus) ou si le fait de
sauter dans une chaîne est assez coûteux.
--
panic("esp_handle: current_SC == penguin within interrupt!");
2.2.16 /usr/src/linux/drivers/scsi/esp.c
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
iptables -A FORWARD -i eth0 -o eth1 -j CHAINE iptables -A CHAINE --source machin -j ACCEPT iptables -A CHAINE --destination truc -j ACCEPT
Je te conseille d'aller voir du coté de ipset. Voir: http://ipset.netfilter.org/
ipset permet en effet d'accélérer le traitement quand on cherche à matcher un grand nombre de sources, un grand nombre de destinations, un grand nombre de ports, etc, mais dans mon cas, c'est beaucoup plus éthérogène.
Il s'agit de savoir s'il vaut mieux factoriser dans une chaîne certains matchings (comme dans l'exemple ci-dessus) ou si le fait de sauter dans une chaîne est assez coûteux. -- panic("esp_handle: current_SC == penguin within interrupt!"); 2.2.16 /usr/src/linux/drivers/scsi/esp.c
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Emmanuel Fleury
Vincent Bernat wrote:
ipset permet en effet d'accélérer le traitement quand on cherche à matcher un grand nombre de sources, un grand nombre de destinations, un grand nombre de ports, etc, mais dans mon cas, c'est beaucoup plus éthérogène.
Oui (mais c'est hétérogène). :)
Il s'agit de savoir s'il vaut mieux factoriser dans une chaîne certains matchings (comme dans l'exemple ci-dessus) ou si le fait de sauter dans une chaîne est assez coûteux.
Si on regarde le code du matching sous Netfilter, les règles ne sont pas factorisées et sont chargées les unes après les autres. Je dirais à vue de nez que dans un cas tu matches les variables avec une seule règles et dans l'autre il faut extraire la règle de la structure de données, ce qui consomme certainement plus de ressources.
Maintenant, ce n'est qu'une théorie, il faudrait faire des benchmarks sur des exemples plus gros (car au niveau d'une règle la différence apparaîtra comme non significative).
Amicalement -- Emmanuel Fleury
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Vincent Bernat wrote:
ipset permet en effet d'accélérer le traitement quand on cherche à
matcher un grand nombre de sources, un grand nombre de destinations,
un grand nombre de ports, etc, mais dans mon cas, c'est beaucoup plus
éthérogène.
Oui (mais c'est hétérogène). :)
Il s'agit de savoir s'il vaut mieux factoriser dans une chaîne
certains matchings (comme dans l'exemple ci-dessus) ou si le fait de
sauter dans une chaîne est assez coûteux.
Si on regarde le code du matching sous Netfilter, les règles ne sont pas
factorisées et sont chargées les unes après les autres. Je dirais à vue
de nez que dans un cas tu matches les variables avec une seule règles et
dans l'autre il faut extraire la règle de la structure de données, ce
qui consomme certainement plus de ressources.
Maintenant, ce n'est qu'une théorie, il faudrait faire des benchmarks
sur des exemples plus gros (car au niveau d'une règle la différence
apparaîtra comme non significative).
Amicalement
--
Emmanuel Fleury
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
ipset permet en effet d'accélérer le traitement quand on cherche à matcher un grand nombre de sources, un grand nombre de destinations, un grand nombre de ports, etc, mais dans mon cas, c'est beaucoup plus éthérogène.
Oui (mais c'est hétérogène). :)
Il s'agit de savoir s'il vaut mieux factoriser dans une chaîne certains matchings (comme dans l'exemple ci-dessus) ou si le fait de sauter dans une chaîne est assez coûteux.
Si on regarde le code du matching sous Netfilter, les règles ne sont pas factorisées et sont chargées les unes après les autres. Je dirais à vue de nez que dans un cas tu matches les variables avec une seule règles et dans l'autre il faut extraire la règle de la structure de données, ce qui consomme certainement plus de ressources.
Maintenant, ce n'est qu'une théorie, il faudrait faire des benchmarks sur des exemples plus gros (car au niveau d'une règle la différence apparaîtra comme non significative).
Amicalement -- Emmanuel Fleury
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Vincent Bernat
OoO En cette soirée bien amorcée du samedi 03 décembre 2005, vers 22:17, Emmanuel Fleury disait:
Si on regarde le code du matching sous Netfilter, les règles ne sont pas factorisées et sont chargées les unes après les autres. Je dirais à vue de nez que dans un cas tu matches les variables avec une seule règles et dans l'autre il faut extraire la règle de la structure de données, ce qui consomme certainement plus de ressources.
Cela dépend sans doute de combien de fois je matche sur la partie factorisable. Si je reprends mon exemple :
iptables -A FORWARD -i eth0 -o eth1 -j CHAINE iptables -A CHAINE --source machin -j ACCEPT iptables -A CHAINE --destination truc -j ACCEPT iptables -A CHAINE --blabla -j ACCEPT iptables -A CHAINE --bidule -j ACCEPT
Dans le premier cas, je verifie 4 fois les interfaces d'entrée et de sortie, dans le second cas, je ne le fais qu'une seule fois mais en contre-partie, je dois sauter dans une chaine. -- # Okay, what on Earth is this one supposed to be used for? 2.4.0 linux/drivers/char/cp437.uni
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
OoO En cette soirée bien amorcée du samedi 03 décembre 2005, vers
22:17, Emmanuel Fleury <emmanuel.fleury@labri.fr> disait:
Si on regarde le code du matching sous Netfilter, les règles ne sont pas
factorisées et sont chargées les unes après les autres. Je dirais à vue
de nez que dans un cas tu matches les variables avec une seule règles et
dans l'autre il faut extraire la règle de la structure de données, ce
qui consomme certainement plus de ressources.
Cela dépend sans doute de combien de fois je matche sur la partie
factorisable. Si je reprends mon exemple :
iptables -A FORWARD -i eth0 -o eth1 -j CHAINE
iptables -A CHAINE --source machin -j ACCEPT
iptables -A CHAINE --destination truc -j ACCEPT
iptables -A CHAINE --blabla -j ACCEPT
iptables -A CHAINE --bidule -j ACCEPT
Dans le premier cas, je verifie 4 fois les interfaces d'entrée et de
sortie, dans le second cas, je ne le fais qu'une seule fois mais en
contre-partie, je dois sauter dans une chaine.
--
# Okay, what on Earth is this one supposed to be used for?
2.4.0 linux/drivers/char/cp437.uni
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
OoO En cette soirée bien amorcée du samedi 03 décembre 2005, vers 22:17, Emmanuel Fleury disait:
Si on regarde le code du matching sous Netfilter, les règles ne sont pas factorisées et sont chargées les unes après les autres. Je dirais à vue de nez que dans un cas tu matches les variables avec une seule règles et dans l'autre il faut extraire la règle de la structure de données, ce qui consomme certainement plus de ressources.
Cela dépend sans doute de combien de fois je matche sur la partie factorisable. Si je reprends mon exemple :
iptables -A FORWARD -i eth0 -o eth1 -j CHAINE iptables -A CHAINE --source machin -j ACCEPT iptables -A CHAINE --destination truc -j ACCEPT iptables -A CHAINE --blabla -j ACCEPT iptables -A CHAINE --bidule -j ACCEPT
Dans le premier cas, je verifie 4 fois les interfaces d'entrée et de sortie, dans le second cas, je ne le fais qu'une seule fois mais en contre-partie, je dois sauter dans une chaine. -- # Okay, what on Earth is this one supposed to be used for? 2.4.0 linux/drivers/char/cp437.uni
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
