Partea nucleului care afișează astfel de statistici în fișierul /proc metoda sistemului de fișiere este Acolo:
dacă (v == SEQ_START_TOKEN) {
seq_puts(seq, "înregistrările căutate au găsit noi invalid ignore delete delete_list insert insert_failed drop early_drop icmp_error expect_new expect_create expect_delete search_restart\n");
returnează 0;
}
seq_printf(seq, "%08x %08x %08x %08x %08x %08x %08x %08x "
„%08x %08x %08x %08x %08x %08x %08x %08x %08x\n”,
nr_conntracks,
0,
st-> găsit,
0,
st->invalid,
st->ignora,
0,
0,
st->inserare,
st->insert_failed,
st->drop,
st->early_drop,
st->eroare,
st->expect_new,
st->expect_create,
st->expect_delete,
st->search_restart
);
după cum se vede, câmpuri căutat (înlocuit cu un alt câmp în nucleele ulterioare), nou, șterge, delete_list afișează întotdeauna 0: nimic nu alimentează aceste câmpuri.
După cum bănuiam în răspunsul meu anterior ("sau ar fi putut fi depășit"), nu există nicio statistică despre aceasta pentru metoda mai veche sau metoda mai nouă.
Aici este commit din 2016 care le-a eliminat (probabil pentru nucleul 4.9):
netfilter: conntrack: eliminați statisticile pachetului hotpath
Aceste contoare stau pe calea fierbinte și apar în performanță, asta mai ales
true pentru „găsit” și „căutat”, care sunt incrementate pentru fiecare pachet
prelucrate.
Informații precum
căutat=212030105
nou=623431
găsit=333613
delete=623327
nu pare prea util in ziua de azi:
pe sistemele ocupate găsite și căutate va depăși la fiecare câteva ore
(acestea sunt numere întregi de 32 de biți), altele mai ocupate la fiecare câteva zile.
pentru depanare există metode mai bune, cum ar fi ținta de urmărire a iptables,
jurnalul conntrack sysctls. În zilele noastre avem și un instrument de perfecționare.
Aceasta elimină contoarele de statistică a căilor de pachete, cu excepția celor care
sunt de așteptat să fie 0 (sau aproape de 0) pe un sistem normal, de ex.
„insert_failed” (cursa a avut loc) sau „invalid” (proto tracker respins).
Statul de inserare este păstrat pentru cazul ctnetlink.
Statistica găsită este reținută pentru verificarea tuple-is-taken atunci când NAT trebuie
determina dacă trebuie să aleagă o altă adresă sursă.
Semnat de: Florian Westphal [email protected]
Semnat de: Pablo Neira Ayuso [email protected]
Alternativă
Puteți folosi contrackd instrument (ambalat pe Ubuntu Acolo) care poate fi configurat să înregistreze evenimente pentru a furniza doar jurnalele și statistici (în loc de utilizarea sa principală pentru failover transparent între mai multe firewall-uri într-un cluster de înaltă disponibilitate). Ubuntu ar putea furniza o configurație pentru statistici în mod implicit (sau în documentație). Iată un exemplu de sistem în care contrackd serviciul rulează:
# conttrackd -s ct; somn 5; conntrackd -s ct
[Veni, 15 octombrie 08:34:08 2021] (pid=3443753) [avertisment] configurație Unix în așteptare depreciată, ignorând.
statistici cache:
conexiuni active curente: 65
conexiuni create: 121807 eșuate: 0
conexiuni actualizate: 116158 eșuate: 0
conexiuni distruse: 121742 eșuate: 0
trafic procesat:
0 octeți 0 bucăți
[Veni, 15 octombrie 08:34:13 2021] (pid=3443756) [avertisment] configurație Unix în așteptare depreciată, ignorând.
statistici cache:
conexiuni active curente: 68
conexiuni create: 121811 eșuate: 0
conexiuni actualizate: 116163 eșuate: 0
conexiuni distruse: 121743 eșuate: 0
trafic procesat:
0 octeți 0 bucăți
Instrumentul spune conexiuni create: a trecut de la 121807 la 121811. Cred că acesta este echivalentul nou câmp eliminat din nucleu.
Notă: trafic procesat: este cu siguranță pentru comunicarea firewall-to-firewall între doi contrackd demonii (deci va fi întotdeauna 0 aici).
