Vlákno názorů k článku Monitorování přenesených dat v síti s 1000 IP adresami od ezzzdiy@gmail.com - Az z toho mam skoro dojem ze se...
-
ezzzdiy@gmail.com (neregistrovaný)
Az z toho mam skoro dojem ze se jedna o pokus zruinovat konkurenci tim ze jim doporucuje nepouzitelny setup.
Je sice hezke ze se autor pokousi o reseni na vlastni pest, sice to funguje, ale zbytecne slozite a hlavne s narocnosti O(pocet_zakazniku^3). Ta mocnina je aproximace vlivu CPU data cache.
Perlickou uz je pak jen to ze resi blbosti jako mongodb, coz je ovsem naprosto irelevantni bottleneck :)
Takze, jak doopravdy na to:
To kdo muze a nemuze do internetu se dela tak ze ipset a -t nat SNAT/DNAT pravidla. Figl je pak v tom ze se toto zpracuje pouze jednou pro kazde nove vytvorene spojeni, data co pak tecou uz ale nevidime a ani nas nemusi zajimat - drzi si je conntrack. To mame 1, max 2 pravidla (ipset!). Pro 1:1 NAT verejnych ip pouzivame target NETMAP, v nejhorsim muzeme mit nekolik set pravidel pokud vnitrni a verejne ip na sebe "nepasuji".
Do filter a mangle chainu *NIKDY* nic necpat, protoze se prochazi per packet, namisto per-spojeni jak je tomu u -t nat tabulky. Samozrejme takto resime i redirekt pro nezname IP atd.
Provisioning (tj pokud mame tarify) se dela pres http://lartc.org/howto/lartc.adv-filter.hashing.html
Accounting (k cemu vlastne? ze by 3G operator? :) se dela pres http://dev.medozas.de/files/xtables/xtables-addons.8.html
(xtables-addons je bezne pouzivany balik v modernich distribucich, stejne tak ipset kernel modul).
Vysledek? Kazdy paket je (ne uplne presne, kvuli faktorum jako chainy hash tabulek) O(1), narozdil O(pocet_ip_za_natem^neco)
HA-VEL na linuxech routuji i 10GBps (pravda, bez conntracku), holt low-cost, nicmene ukazka toho ze to jde, jen staci trocha toho RTFM.
PS: Na boxu s Quad L5420 @ 2.5GHz v 9 vecer tece 1.5gbps @ 250kpps pro cca 3500 useru za natem. 70% per core je stale idle, ale pocitam ze nekde pri 750kpps to pujde do kolen, coz je bohuzel limit levnych PC sestav.
-
Ondřej CaletkaZlatý podporovatelOpravdu zajímavý příspěvek. Nechceš to rozepsat do pořádného článku/seriálu? Informací z téhle oblasti je málo a podle mě nad tím tápe hodně lidí.
-
Pokud jde o matchování velkého množství adres, není už pohodlnější místo hromady pravidel použít userspace queuing a kontrolovat nová spojení proti nějaké rychlé databázi? Můj bastl (https://github.com/jmakovicka/nfblock) který používám na blacklistování 200k+ roszahů, mi tady na NB s Pentiem na 1.6GHz zvládá matchovat něco přes 2 milióny IP za sekundu, přičemž jede na jednom jádře.
