Je suis tombé sur une situation où un client doit mettre sur liste noire un ensemble d'un peu moins d'un million d'adresses IP individuelles (pas de sous-réseaux), et les performances du réseau sont une préoccupation. Bien que je suppose que les règles IPTables auraient moins d'impact sur les performances que les routes, ce n'est qu'une conjecture.
Quelqu'un a-t-il des preuves solides ou une autre justification pour favoriser IPTables ou le routage nul comme solution pour mettre sur liste noire les longues listes d'adresses IP? Dans ce cas, tout est automatisé, donc la facilité d'utilisation n'est pas vraiment un problème.
EDIT 26-Nov-11
Après quelques tests et développements, il semble qu'aucune de ces options ne soit réalisable. Il semble que les recherches d'itinéraire et iptables effectuent des recherches linéaires dans l'ensemble de règles et prennent tout simplement trop de temps pour traiter ces nombreuses règles. Sur le matériel moderne, mettre 1M d'éléments dans une liste noire iptables ralentit le serveur à environ 2 douzaines de paquets par seconde. Les IPTables et les routes nulles sont donc sortis.
ipset
, comme recommandé par Jimmy Hedman, serait génial, sauf qu'il ne vous permet pas de suivre plus de 65536 adresses dans un ensemble, donc je ne peux même pas essayer de l'utiliser à moins que quelqu'un n'ait des idées.
Apparemment, la seule solution pour bloquer autant d'IP consiste à effectuer une recherche indexée dans la couche application. N'est-ce pas?
Plus d'information:
Dans ce cas, le cas d'utilisation empêche une liste d'adresses IP de "contrevenants connus" d'accéder à du contenu statique sur un serveur Web. FWIW, le blocage via Apache Deny from
est tout aussi lent (sinon plus) car il effectue également un balayage linéaire.
FYI: La solution de travail finale consistait à utiliser le mod_rewrite d'apache en conjonction avec une carte berkeley DB pour effectuer des recherches sur la liste noire. La nature indexée des bases de données berkeley a permis à la liste d'évoluer avec les performances O (log N).