\chapter{Firewall}
\label{firewall}

Jako firewall označujeme hardware nebo software, který monitoruje vstupní
i výstupní provoz ze síťových rozhraní, a na základě množiny bezpečnostních
pravidel rozhoduje, zda daný provoz má být propuštěn (např. ke zpracování
v aplikační vrstvě či odeslán ze síťového rozhraní) nebo zablokován. O~tom,
zda má být každý jednotlivý packet povolen či zahozen, se zpravidla rozhoduje
na základě obsahu hlaviček linkové, síťové či transportní vrstvy ISO OSI modelu,
ale používají se i~firewally, které dokáží kontrolovat síťový provoz na základě
obsahu dat aplikační vrstvy. Kromě samotného filtrování nabízí firewally i~jiné
funkce -- např. překlad síťových adres (NAT), zakončení tunelů virtuálních privátních
sítí (VPN), směrování atd.

Existují různé druhy firewallů, které můžeme rozdělit do mnoha skupin. Většinou
však nelze říci, že by nějaký konkrétní firewall patřil pouze do jedné skupiny.
Častější jsou firewally, které dokáží fungovat ve více režimech a můžeme je tedy
zařadit do více skupin.

\section{Rozdělení firewallů}
\label{firewall-rozdeleni}

\subsection{Podle umístění v síti}
\label{firewall-rozdeleni-podle-umisteni}

\subsubsection{Síťový (network-based) firewall}
\label{network-based-firewall}

Jedná se o~síťové zařízení, které se připojuje na rozhraní dvou a více sítí.
Tyto sítě, v~mnoha případech, spravují různé osoby, proto je nutné nedůvěřovat
veškerému provozu, který prochází mezi sítěmi, a raději jej filtrovat podle
bezpečnostních politik chráněné sítě. Jak bylo naznačeno, minimálně jedna
síť je důvěryhodná, a tedy firewallem chráněná, zbylá síť/sítě jsou nedůvěryhodné
(např. Internet). Z~textu vyplývá, že síťový firewall se používá k~ochraně
celé sítě, tedy více koncových stanic (klientských počítačů či serverů)
a mezilehlých síťových prvků (směrovačů, přepínačů). Síťový firewall obvykle
funguje i~jako hraniční směrovač důvěryhodné sítě.

\subsubsection{Osobní (host-based) firewall}
\label{host-based-firewall}

Jak již název napovídá, jedná se o~firewall, který slouží k~ochraně jedné
konkrétní koncové stanice (klientského počítače či serveru). Standardně bývá
tento typ firewallu součástí operačního systému. Osobní firewall slouží
k~ochraně operačního systému a aplikací na něm běžících. Díky možnosti filtrování
i~odchozího provozu ze stanice lze ochránit i~další zařízení v~síti v~případě,
že by došlo ke zkompromitování uživatelské aplikace.

\subsection{Podle principu fungování}
\label{firewall-rozdeleni-podle-principu}

\subsubsection{Packetový filtr}
\label{packetovy-filtr}

Jedná se o~nejjednodušší typ firewallu. Jeho činnost je založena na porovnávání
každého jednotlivého packetu vůči bezpečnostní politice, kterou zde představuje
filtrovací tabulka. Ta je tvořena sloupci pro zdrojovou a cílovou síťovou adresu
daného packetu, zdrojový a cílový port aplikace a většinou také obsahuje sloupec
pro typ protokolu, který je přenášen v~datové části internetového protokolu. Nezbytnou
součástí tabulky je i~sloupec pro zapsání akce, která má být s~vyhovujícím packetem
provedena -- povolení či zahození. Algoritmus samotného firewallu se tedy stará o~zjištění
údajů o~adresách, portech a protokolu z~každého příchozího (či odchozího) packetu a
porovnává tyto údaje vůči pravidlům ve filtrovací tabulce. Ta je procházena odshora dolů
a podle prvního pravidla, které zpracovávanému packetu vyhoví, je s~packetem naloženo
(podle informace ze sloupce akce). Proto je potřeba do tabulky vkládat pravidla od
specifických k~obecnějším. V~případě, že packet nevyhoví ani jednomu pravidlu, bývá
na konci tabulky uvedeno obecné pravidlo, které každý packet povolí nebo zahodí.

Důležitou vlastností tohoto firewallu je to, že každý packet je vyhodnocován zvlášť
bez jakýchkoliv vazeb na dřívější komunikaci. To s~sebou přináší výhodu celkem rychlého
zpracování, ovšem jedná se o~velice jednoduché filtrování, kdy firewall nemá možnost
kontrolovat, zda komunikace probíhá ve správném pořadí a v~souladu s~pravidly, které
jsou definovány ve standardech jednotlivých protokolů (např. správné sestavení TCP
komunikace na základě třícestného vyjednávání).

\subsubsection{Packetový filtr se stavovou inspekcí}
\label{packetovy-filtr-s-spi}

Packetový filtr se stavovou inspekcí je rozšířenou verzí obyčejného packetového filtru.
Kromě filtrovací tabulky si vede i~tabulku povolených spojení. V~té si zaznamenává stav spojení,
která přes firewall prochází. Přijde-li na firewall packet, je obvykle nejdříve porovnáván
vůči tabulce spojení. Pokud je spojení, ke kterému packet patří, v~tabulce nalezeno,
může být provedena další protokolová kontrola (např. správná sekvenční a potvrzovací
čísla v~hlavičce TCP) a aktualizace stavu ve stavové tabulce. V~případě, že i~těmto následným
kontrolám packet vyhoví, je firewallem akceptován. Pokud záznam v~tabulce spojení není,
musí být packet porovnán vůči filtrovací tabulce. Jestliže packet vyhoví pravidlům z~filtrovací
tabulky, je vytvořen nový záznam v~tabulce spojení, na základě kterého bude kontrolována a
propouštěna následná komunikace. Ačkoliv by se mohlo zdát, že stavová inspekce má význam
pouze u~stavových protokolů (nejznámější zástupce je zřejmě TCP), běžně se využívá i~u protokolů
bezstavových (např. UDP, ICMP). V~tom případě se ke každému takovému spojení přiřadí časovač,
po jehož vypršení se spojení z~tabulky smaže. Pokud by následovala další komunikace daného spojení,
musela by se opět ověřovat vůči filtrovací tabulce.

Výhodou tohoto typu firewallu je schopnost rozpoznávat a rozumět určitým protokolům a také
vyšší rychlost zpracování síťového provozu díky tomu, že známá a již povolená spojení se vyhledávají
rychleji v~tabulce spojení, než kdyby se měla kontrolovat vůči filtrovací tabulce \cite{burda}.

\subsubsection{Aplikační brána (příp. proxy firewall)}
\label{proxy-firewall}

Aplikační brána filtruje procházející provoz až v~aplikační vrstvě modelu ISO OSI. Algoritmus
firewallu postupně načítá procházející packety tak, aby tvořily kompletní zprávu aplikace (v případě, že
je zpráva rozdělená do více packetů) a nad ní pak provádí kontrolu. Přitom nekontroluje pouze
hlavičky aplikačních protokolů, ale často analyzuje i~samotná aplikační data. Tím lze objevit
škodlivý kód, který je možné zahodit dříve, než dorazí na cílovou stanici. Samotná komunikace
neprobíhá přímo mezi klientem v~chráněné síti a serverem v~nedůvěryhodné síti, jako tomu bylo
u packetových filtrů, ale zprostředkovává ji právě aplikační brána. Klient tedy otevře nové spojení
na aplikační bránu a předá jí svůj požadavek na komunikaci. Brána otevře spojení s~cílovou stanicí z~přijatého
požadavku a přepošle jí požadavek od klienta. Odpověď serveru brána přijme a předá ji filtrovací aplikaci,
která nad ní provede kontrolu. Pokud je vše v~pořádku, je odpověď serveru přeposlána již otevřeným spojením
na klienta.

Z popisu principu fungování aplikační brány je jasné, že výhodou tohoto typu firewallu bude
vysoká ochrana chráněné sítě. Ovšem na druhou stranu, kvůli filtraci až na sedmé vrstvě ISO OSI modelu,
je datová propustnost menší než u~packetových filtrů, a navíc musí být klientská aplikace přizpůsobená
ke komunikaci přes aplikační bránu.

\subsection{Podle transparentnosti}
\label{firewall-rozdeleni-podle-transparentnosti}

\subsubsection{Netransparentní firewall}
\label{netransparentni-firewall}

V tomto režimu funguje firewall jako klasický směrovač. Kromě toho však směrovaný provoz i~filtruje.
Jako každý jiný směrovač tedy musí mít minimálně dvě fyzická či logická síťová rozhraní, přičemž každé
z nich má přidělenou adresu z~různých (pod)sítí (viz obrázek \ref{fig:netransparentni-firewall}). Po přijetí packetu je tedy mimo samotné filtrace provedeno
i směrovací rozhodnutí -- tedy na základě směrovací tabulky je rozhodnuto, na které odchozí rozhraní bude packet
předán. Díky tomu může být firewall použit pro zakončení VPN tunelů, být součástí domény směrovačů pro dynamické
směrování nebo třeba dělat překlad síťových adres. Nevýhodou může být určitá možnost detekce firewallu v~síti či
možné problémy s~adresováním při nasazení. Mluvíme-li obecně o~firewallech, máme ve většině případů na mysli tento typ.

\vspace{4mm}

\begin{figure}[h]
	\centering
	\includegraphics[width=\textwidth,keepaspectratio=true]{netransparentni-fw}
	\vspace{1mm}
	\caption{Schéma funkčnosti netransparentního firewallu.}
	\label{fig:netransparentni-firewall}
\end{figure}

\subsubsection{Transparentní firewall}
\label{transparentni-firewall}

Firewall v~tomto režimu se chová zcela transparentně pro veškerý IP provoz. Jeho činnost spočívá v~příjmu
rámce, jeho zkontrolování a v~případě, že vyhoví nastaveným pravidlům, je předán na výstupní rozhraní (viz obrázek \ref{fig:transparentni-firewall}). Aby tento
způsob předávání rámců fungoval, musí síťová rozhraní podporovat a být přepnuta do tzv. \uv{promiskuitního módu}.
Při příjmu rámce, který obsahuje jinou cílovou linkovou adresu než je linková adresa rozhraní, není v~tomto módu rámec
zahozen, ale je předán dále ke zpracování. Díky tomu, že se firewall nepodílí na směrování provozu, je v~síti téměř
nezjistitelný (někdy je označovaný jako \uv{stealth firewall}), nerozděluje adresní prostor tam, kde je nasazen,
a je možné ho použít k~ochraně zařízení, které neobsahuje vlastní firewall, bez nutnosti přeadresace. Bohužel jej
není možné použít pro zakončení VPN tunelů, nemusí umožňovat překlad síťových adres nebo jeho nastavení či řešení
problémů nemusí být tak přímočaré, jako v~případě firewallu netransparentního \cite{ciscotransparentfirewall}. V~této práci
se primárně zaměříme na tento druh firewallu.

\vspace{4mm}

\begin{figure}[h]
	\centering
	\includegraphics[width=\textwidth,keepaspectratio=true]{transparentni-fw}
	\vspace{1mm}
	\caption{Schéma funkčnosti transparentního firewallu.}
	\label{fig:transparentni-firewall}
\end{figure}

\section{Obvyklé umístění firewallů v síti}
\label{obvykle-umisteni-firewallu}

Z předchozích odstavců není úplně těžké odhadnout, jaké druhy firewallů se v~kterých částech sítě používají. Základním
vybavením každé koncové stanice by měl být osobní firewall, který určí, jaký provoz může stanice přijímat a odesílat.
Pokud stanice nemůže být vybavena osobním firewallem, možností je umístit před tuto stanici transparentní firewall,
který se o~filtraci síťového provozu postará. Díky transparentnosti není ani potřeba řešit přeadresování stanice. Na
perimetru chráněné sítě by se měl nacházet síťový firewall. Jedná se většinou o~(stavový) packetový filtr netransparentního typu. Za něj se umisťuje
aplikační brána (spíše ale více bran, pro každý analyzovaný protokol zvlášť). Tato topologie je výhodná v~tom, že packetový
filtr provede rychlé hrubé odfiltrování nežádoucího provozu a zbytek je důkladněji prověřen v~aplikačních bránách \cite{burda}.
Kromě netransparentního packetového filtru je možné použít kombinaci transparentního packetového filtru s~klasickým směrovačem,
kdy se transparentní firewall umístí do vnější sítě před směrovač. Tím je možné odfiltrovat provoz ještě předtím, než dorazí na
hraniční směrovač.

\chapter{Vysokorychlostní zpracování a filtrace packetů v Linuxu}
\label{vysokorychlostni-zpracovani}

\section{Tradiční přístup ke zpracování packetů}
\label{tradicni-pristup}

Jak již bylo naznačeno v~úvodu, Linux je univerzální jádro operačního systému, které v~oblasti síťového zásobníku nabízí
bohaté možnosti, jež se hodí pro různé aplikace. Bohužel tento přístup s~sebou přináší limity v~oblasti výkonu. Hlavním
problémem nejen Linuxu, ale i~dalších univerzálních operačních systémů, je výkon zpracování vstupně-výstupních (IO) operací. Obvyklý
způsob jejich zpracování je pomocí přerušení (IRQ). Přerušení slouží k~upozornění procesoru, že například síťová karta přijala nový packet a je
nutné jej zpracovat. Díky tomuto způsobu zpracování IO operací se může procesor v~čase mezi přerušeními věnovat jiné činnosti.
Přerušení se však hodí pro prostředí, kdy systém není příliš zatížen IO operacemi. V~případě vysokého síťového zatížení, s~čímž
se dá v~případě firewallu počítat, se přerušení stávají značně neefektivní metodou zpracování vstupně-výstupních operací, jelikož
každý IRQ je drahou operací. Snadno se tak může stát, že procesor začne být zatížen jen vyřizováním požadavků na přerušení, místo toho,
aby zpracovával samotné packety. Tento jev se označuje jako \uv{interrupt livelock} \cite{gallenmuller}.

Druhou možností, jak ke zpracování vstupně-výstupních operací přistoupit, je tzv. \uv{polling}. Při této metodě se procesor
aktivně a pravidelně vyptává síťové karty, zda přijala nová data, která je potřeba vyřídit. Jelikož je polling méně nákladnou
operací než přerušení, lze tím docílit vyšší propustnosti a snížení latencí, ovšem za cenu alokování procesoru jen pro tuto činnost.

Proto byl v~Linuxu verze 2.4.20 představen hybridní přístup pojmenovaný NAPI (New API) \cite{salim}. NAPI funguje tak, že po
startu systému je nastaven režim přerušení. Při přijetí nového packetu je vyvolán požadavek na přerušení. Poté jsou pro dané
zařízení přerušení zakázána a přechází se do režimu pollingu. V~tomto režimu procesor pravidelně přistupuje k~síťové kartě
a dává pokyn k~přesunu dat z~vyrovnávací paměti síťové karty do paměti RAM. Dokud jsou ve vyrovnávací paměti data, je dané 
zařízení plánováno stále v~režimu pollingu. V~opačném případě se polling zakáže a opět se povolí přerušení. Tímto přístupem
lze dosáhnout propustnosti až několika Gbit/s \cite{gallenmuller2}, ovšem ovladač síťové karty musí NAPI podporovat.

\section{Možnosti zrychlení zpracování packetů}
\label{moznosti-zrychleni}

V předchozí sekci bylo vysvětleno, proč Linux není efektivní při vysoké síťové zátěži a jakým způsobem se to samotné jádro
snaží řešit. Ovšem existují i~jiné způsoby, jakými lze dosáhnout vyšší datové propustnosti \cite{gallenmuller}:

\begin{itemize}

	\item {\bf Obejít síťový zásobník jádra} -- jednou z~nejúčinnějších metod, jak zrychlit zpracování packetů, je vůbec je nevpouštět
	do jádra a jeho síťového zásobníku, ale zpracovávat je v~uživatelském prostoru (user-space) pomocí vlastního síťového zásobníku,
	který bude přesně odpovídat požadavkům aplikace. Tímto způsobem lze dosáhnout vysoké efektivity zpracování, ovšem je třeba
	upravit ovladač síťové karty tak, aby nepředával data jádru, ale uživatelské aplikaci. Jádro tedy neuvidí žádná síťová data,
	a tudíž není možné využít jakýchkoliv jiných jeho síťových služeb.
	\item {\bf Využívat polling místo přerušení} -- pro systémy s~vysokým síťovým zatížením je efektivnější využívat polling místo
	drahých přerušení, jak bylo vysvětleno v~\ref{tradicni-pristup}.
	\item {\bf Kopírovat data co nejméně} -- je logické, že čím více se budou zpracovávaná data kopírovat (např. mezi síťovým
	rozhraním a jádrem, jádrem a uživatelskou aplikací), tím větší bude zpoždění celkového zpracování. Ideálně by měl ovladač
	síťového rozhraní zkopírovat data do paměti a přímo s~touto pamětí by měla aplikace pracovat. Tímto lze dosáhnout i~velice
	rychlého předávání dat mezi rozhraními -- stačí v~paměti data označit jako odchozí z~jiného rozhraní.
	\item {\bf Zpracovávat data v~dávkách} -- místo provádění operací nad každým packetem zvlášť, je efektivnější je zpracovávat
	v dávkách několika packetů. Tím se náklady spojené s~danou operací rozloží do více packetů.
	\item {\bf Alokace paměti předem} -- pro každou alokaci paměti je potřeba vyvolat systémové volání, při kterém musí jádro
	nalézt dostatečně velký paměťový prostor. Každé takové volání samozřejmě stojí čas. Proto se jako vhodná technika jeví alokace
	paměti třeba při startu aplikace. Jelikož se velikost paměti při běhu aplikace již nemůže měnit, je třeba zvolit takovou velikost,
	která bude dostatečná po celou dobu běhu aplikace.

\end{itemize}

\section{Nástroje a knihovny pro vysokorychlostní zpracování a filtraci}
\label{nastroje-a-knihovny}

\subsection{netfilter + iptables}
\label{netfilter}

Dobře známý filtrovací podsystém Linuxového jádra, jehož je standardní součástí od verze 2.4. Je velice univerzální, a proto jej
lze použít v~mnoha různých situacích: od prostého packetového filtru přes stavový packetový filtr až po zařízení provádějící
překlad síťových adres či jinou změnu v~hlavičkách packetů. Může pracovat jako osobní, ale i~síťový, firewall. Netfilter vytváří
v jádře několik záchytných bodů (hooks) v~různých fázích zpracování packetu. Dynamicky načítané jaderné moduly pak mohou k~těmto
bodům zaregistrovat svou callback funkci a tím zajistit, že bude-li packet procházet daným bodem, bude předán k~prozkoumání
i~zaregistrovanému modulu. Počet registrací k~danému záchytnému bodu není omezen a packet je postupně předán všem registrovaným
modulům (pokud není některým zahozen) \cite{pesa}. Nejznámější utilitou pro správu pravidel a jaderných modulů je zřejmě \texttt{iptables}.
Kromě \texttt{iptables} ale existují i~jiné utility, např. \texttt{ip6tables} nebo \texttt{ebtables}. Právě druhá zmíněná utilita
slouží k~filtrování na úrovni linkové vrstvy ISO OSI modelu. Pomocí \texttt{ebtables} lze filtrovat až do transportní vrstvy, ovšem
pouze podle adres (IP nebo portů) a bezstavově. Díky modulu \texttt{bridge-netfilter} (označovaný i~jako \texttt{br-netfilter} nebo
\texttt{bridge-nf}) lze i~při transparentním filtrování využívat možností \texttt{iptables}, tzn. provádět například stavovou inspekci
či překlad síťových adres. V~jádrech 3.18-rc1 a novějších je potřeba tento modul načíst, ve starších jádrech je integrován přímo v~modulech
\texttt{iptables}, takže jej není nutné explicitně načítat.


\subsection{nftables}
\label{nftables}

Nový podsystém pro filtrování a úpravu síťového provozu v~Linuxu. Součástí jádra od verze 3.13. Využívá infrastrukturu Netfilteru
(záchytné body), ovšem dynamicky načítané moduly jsou jiné než využívají \texttt{iptables} a další. Moduly v~jádře vytváří virtuální
stroj, který pracuje se speciálním byte kódem, do kterého jsou zkompilovány jednotlivá filtrovací pravidla. Nabízí přímou možnost pro
vkládání množin parametrů (např. IP adres nebo portů) do jednoho pravidla, takže je možné sloučit více pravidel, a tím zrychlit celkové
vykonávání filtrace. O~uživatelské rozhraní se stará nová utilita \texttt{nft}, která sjednocuje \texttt{iptables} a další \texttt{*tables}
utility. Syntaxe pravidel je zcela odlišná od syntaxe netfilter utilit. \texttt{nft} slouží zároveň jako kompilátor a dekompilátor
pro byte kód, který nahrává do/z jaderného virtuálního stroje. Tím je přesunuta velká část logiky do uživatelské utility a jádro tak
může pracovat jen s~byte kódem \cite{nftables}.


\subsection{PF\_RING}
\label{pf-ring}

PF\_RING je knihovna, resp. sada knihoven (framework), a jaderný modul, pomocí nichž lze zpracovávat síťový provoz při vysoké rychlosti.
Využívá principů popsaných v~sekci \ref{moznosti-zrychleni}. PF\_RING dokáže pracovat jak s~běžnými ovladači síťových karet, tak nabízí
upravené ovladače karet Intel a dalších výrobců, pomocí kterých lze linuxové jádro zcela obejít a dosáhnout tak vyšší datové propustnosti.
Bohužel jsou tyto ovladače použitelné pouze po zakoupení licence \cite{pfringzc}.
Při využití standardních ovladačů jsou v~jádře vytvořeny dvě cyklické fronty (jedna pro příjem, druhá pro vysílání), které s~ovladačem karty komunikují pomocí NAPI. Z~těchto front pak čtou (příp.
do nich zapisují) uživatelské aplikace pomocí PF\_RING knihovny (viz obrázek \ref{fig:pf_ring}).

PF\_RING nabízí API pro filtrování provozu pomocí syntaxe BPF (stejně jako \texttt{tcpdump} například), ale dokáže využít i~možnosti
filtrovat provoz hardwarově přímo v~síťové kartě. Hardwarový filtr je však podporován pouze minimálním počtem karet, proto mu dále nebude
věnována pozornost. Ačkoliv zřejmě neexistuje žádná volně dostupná implementace firewallu využívající PF\_RING, v~rámci jeho zdrojových
kódů je distribuována i~příkladová aplikace \texttt{pfbridge}, která umožňuje přemostit dvě síťová rozhraní a provádět filtraci průchozího
provozu. Využívá právě zmíněnou syntaxi BPF a samotný filtr označuje provoz, který má být propuštěn (tudíž jen ty packety, které vyhoví
filtru, budou propuštěny, vše ostatní bude zahozeno).

\begin{figure}[h]
	\centering
	\includegraphics[keepaspectratio=true]{pf_ring}
	\vspace{4mm}
	\caption{Schéma funkčnosti knihoven a jaderného modulu PF\_RING \cite{pfring}.}
	\label{fig:pf_ring}
\end{figure}

\subsection{netmap}
\label{netmap}

Stejně jako PF\_RING se i~netmap skládá z~knihoven a jaderného modulu. Původně byl vyvíjen pro FreeBSD, ovšem nyní existují verze pro Linux,
a dokonce i~Windows. Svou architekturou je velice podobný PF\_RINGu -- cyklické fronty pro každý směr a každé síťové rozhraní, do
kterých zapisují a ze kterých čtou jak ovladače síťových karet, tak aplikace. Pro vysokou rychlost zpracování jsou vyžadovány upravené ovladače
karet, ale netmap nabízí i~emulační mezivrstvu, s~jejíž pomocí je možné používat standardní jaderné ovladače. V~případě, že není aktivní žádná
netmap aplikace, chovají se ovladače obvyklým způsobem (předávají data jadernému síťovému zásobníku). Po spuštění netmap aplikace je ovladač
přepnut do tzv. \uv{netmap módu}, během kterého nedostává jádro žádná data, ale všechna jsou předávána netmap aplikaci. Po ukončení této aplikace
je opět přepnuto do původního režimu \cite{gallenmuller2}.

Pro demonstraci možností a dobré kompatibility API, implementoval autor netmapu FreeBSD firewall \texttt{ipfw} pomocí frameworku netmap.
Díky tomu je možné celkem snadno zprovoznit vysokorychlostní packetový filtry umožňující i~tvarování
provozu na běžně dostupném hardwaru.

\subsection{Data Plane Development Kit}
\label{dpdk}

Data Plane Development Kit neboli DPDK je další skupina knihoven, jenž umožňuje zpracování síťového provozu při vysoké rychlosti s~minimálním
zatížením procesoru. Opět staví na principech ze sekce \ref{moznosti-zrychleni} a sdílených cyklických frontách. Kromě samotné akcelerace zpracování síťových dat nabízí
i jiné funkce, které se mohou hodit při vývoji komplexních síťových aplikací, např. algoritmy pro hledání nejdelšího prefixu využívané při
implementaci L3 směrování či QoS funkce. DPDK je podporován mnoha výrobci, proto nabízí zřejmě nejvíce upravených ovladačů síťových karet ze
všech zmíněných frameworků \cite{dpdkdrivers}. Nenabízí podporu pro žádný transparentní nebo hybridní mód, je-li tedy síťová karta ovládána
pomocí DPDK, nejsou žádná data předávána jádru, ať už běží nějaká DPDK aplikace nebo ne. Veškeré části DPDK včetně ovladačů fungují pouze na
principu pollingu a nevyužívají tedy žádným způsobem přerušení. Ovladače síťových karet provádí značnou část svých operací v~uživatelském prostoru,
na jádro je ponechána pouze inicializace karty. Tento speciální typ ovladače se označuje UIO \cite{gallenmuller}.

Ačkoliv je DPDK hojně podporovaný výrobci, a někteří výrobci staví své produkty umožňující filtraci packetů nad tímto frameworkem (např. \cite{brocade} nebo \cite{6wind}),
volně dostupných filtrovacích nástrojů příliš neexistuje. Pro názornou ukázku možností DPDK jsou v~rámci jeho zdrojových kódů šířeny DPDK aplikace \texttt{l3fwd-acl} a \texttt{ip\_pipeline},
které slouží k~ukázce bezstavového (ne)transparentního packetového filtru.

\subsection{Snabb}
\label{snabb}

Snabb, dříve známý jako SnabbSwitch, je síťový framework kompletně napsaný v~odlehčeném vysokoúrovňovém skriptovacím jazyce Lua. Aby byl omezen dopad
nižší výkonnosti skriptovacích jazyků oproti kompilovaným jazykům, je využívána JIT kompilace LuaJIT. Díky zvolenému jazyku jsou před
programátory schovány implementační detaily, a proto je možné psát vysokorychlostní síťové aplikace snadno a pomocí malého počtu řádků kódu.
Snabb nevyužívá jaderné ovladače síťových karet, ani nějaké jejich upravené verze, ale dodává své vlastní ovladače, taktéž napsané v~jazyce Lua a využívající přístupu UIO.
Kvůli této závislosti jsou podporovány prakticky jen karty Intel.

Snabb API nabízí mnoho různých funkcí, včetně podpory pro filtrování pomocí BPF. Bohužel žádná z~příkladových aplikací tuto funkčnost prakticky
nedemonstruje. O~implementaci kompletního firewallu nad frameworkem Snabb se snaží projekt SnabbWall, který v~době psaní této práce měl zatím implementovánu
část detekcí toků, ale samotný packetový filtr ještě nebyl vyvinut \cite{snabbwall}.

\subsection{PFQ}
\label{pfq}

PFQ je síťový framework napsaný částečně v~jazyce C/C++ a částečně ve funkcionálním jazyce Haskell. Je optimalizovaný pro vícejádrové
procesorové architektury a síťové karty s~více hardwarovými frontami. Nepotřebuje ke své funkci upravené ovladače a zaměřuje se spíše
na zpracování packetů v~prostoru jádra než v~uživatelském prostoru. Do linuxového jádra je načten v~podobě modulu, se kterým pak komunikují
uživatelské aplikace přes knihovny, které jsou dostupné pro jazyky C, C++ a Haskell. Samotný modul využívá pro komunikaci s~ovladačem síťové karty rozhraní NAPI.

Jako některé další zmíněné frameworky, nabízí PFQ ve svém API funkce pro filtrování packetů pomocí BPF či VLAN hlavičky. Bohužel aplikaci
demonstrující tuto funkci zřejmě není možné najít.

\subsection{nf-HiPAC}
\label{hipac}

nf-HiPAC je framework pro vysokovýkonnostní klasifikaci packetů pro netfilter. Pro optimalizaci výkonu využívá algoritmy, které snižují
počet přístupů do paměti. Zachovává syntaxi používanou utilitou \texttt{iptables}, avšak podporuje pouze filtraci packetů (ať už stavovou
či bezstavovou). Překlad síťových adres či jiná změna hlaviček packetů není podporována \cite{nfhipac}.

I když vypadá tento projekt slibně, je již více než 10 let neaktivní a podporuje pouze jádra 2.6.11 až 2.6.14 \cite{nfhipacreq}. Dnes již tyto verze
nejsou podporovány, a z~bezpečnostního pohledu o~nich nemá cenu uvažovat.


\chapter{Linková agregace}
\label{linkova-agregace}

Linkovou agregací se myslí technika, při které se více fyzických propojení mezi dvěma síťovými prvky chová stejně jako jedno logické propojení
nabízející vyšší datovou propustnost (danou součtem rychlostí jednotlivých fyzických rozhraní, viz obrázek \ref{fig:linkaggreg}) a zvýšení dostupnosti propojení mezi danými prvky \cite{soun}.
V případě výpadku jednoho z~fyzických propojů, je možné i~nadále přenášet data zbývajícími propojeními bez zaznamenání daného selhání, pouze se sníží
přenosová kapacita propojení. Díky existenci standardu IEEE 802.3ad nebo nověji IEEE 802.1AX-2008, je možné agregovat linky mezi zařízeními různých výrobců.
Standardy kromě statické agregace, kdy je nutné agregaci ručně nastavit na obou zařízeních, definuje i~LACP, což je L2 protokol pro dynamickou konfiguraci
linek pro agregaci. Při agregaci musí mít všechny linky stejné parametry (linkovou rychlost, duplex atd.).

\begin{figure}[h]
	\centering
	\includegraphics[width=\textwidth,keepaspectratio=true]{linkova-agregace-teorie}
	\vspace{6mm}
	\caption{Příklad, jakým způsobem funguje agregace linek.}
	\label{fig:linkaggreg}
\end{figure}

Na Linuxu existují pro agregaci linek dvě hlavní řešení -- NIC bonding a NIC teaming. Kromě některých vylepšení, které NIC teaming nabízí oproti bondingu \cite{nicteaming},
je hlavní rozdíl mezi nimi v~umístění samotné logiky -- zatímco při bondingu jsou veškeré operace prováděny v~prostoru jádra pomocí zásuvného modulu, NIC teaming funguje jako démon
v uživatelském prostoru. Obě tato řešení jsou však kompatibilní jen se standardním síťovým zásobníkem Linuxu. V~případě použití filtrovacích nástrojů, které obchází
linuxový zásobník, je třeba linkovou agregaci řešit ve spolupráci s~těmito nástroji. Jediným frameworkem, u~kterého byl nalezen popis agregace linek, je DPDK \cite{dpdkbond}.

Aby mohla být filtrace při agregovaných linkách vyzkoušena, je potřeba nejen podpora v~samotných firewallech, ale také celé síťové infrastruktury. Jak je popsáno dále v~textu,
při testování v~experimentální síti se podařilo infrastrukturu přepojit tak, aby mohla být linková agregace a filtrace vyzkoušena, ovšem jen pro dvě 1Gbit/s (tedy do maximální
přenosové rychlosti 2 Gbit/s).


\chapter{Praktické testování vysokorychlostní filtrace v~Linuxu}
\label{prakticka-cast}

\noindent
Praktické testování nástrojů a knihoven pro vysokorychlostní filtraci síťového provozu na běžném hardwaru bylo rozděleno do několika částí.
Aby nebylo nutné alokovat drahé prostředky (hlavně přepínač a porty na generátoru provozu) pro 10Gbit/s rychlost na dlouhou dobu, byly
v první fázi nastaveny a otestovány filtrovací nástroje na rychlosti do 1~Gbit/s a až poté, co bylo testovací prostředí nastaveno, se síť
přepojila na plně 10~Gbit/s přenosovou rychlost.

Po odzkoušení filtrace při rychlosti dat 10 Gbit/s bylo testování filtračních nástrojů přesunuto na experimentální pracoviště, kde byly nástroje testovány při různých nastaveních filtrace,
a také byla vyzkoušena možnost filtrace na agregovaných linkách.

\section{Výběr nástrojů a knihoven pro testování}
\label{vyber-nastroju-pro-testovani}

Již ze shrnutí v~sekci \ref{nastroje-a-knihovny} lze částečně odvodit, které nástroje a knihovny nabízí ukázkové či samostatně vyvíjené programy umožňující
filtraci síťového provozu a které ne, či se k~testování v~rámci této práce nehodí. Zcela určitě by ve výběru neměla chybět v~dnešní době klasická varianta filtrování
pomocí netfilteru a \texttt{iptables}, aby se potvrdilo či vyvrátilo, že se linuxové jádro pro vysokorychlostní filtraci dat opravdu nehodí.
Dále byl vybrán k~otestování nástroj nftables, aby se mohlo případně projevit, zda s~novým filtrovacím podsystémem přichází i~vyšší výkonnost filtrace. Mezi další
vybrané patří framework PF\_RING. Ten v~rámci svých zdrojových kódů distribuuje ukázkovou aplikaci, která umožňuje přemostit dvě síťová rozhraní a aplikovat při tom
určitý filtr. Jako poslední byl vybrán framework netmap, pomocí nějž byl implementován firewall \texttt{ipfw} označovaný jako \texttt{netmap-ipfw}. Ostatní nástroje
a knihovny buď nenabízí již implementované filtrovací programy, anebo se pro tuto práci nehodí. Frameworky Snabb a PFQ v~době psaní této práce nenabízely nástroje pro
filtrování. nf-HiPAC se zase nehodí z~důvodu požadavku provozování na velice starém jádře. DPDK sice nabízí ukázkové filtrovací aplikace, ovšem buď se nejedná o~transparentní
filtraci (\texttt{ip\_pipeline}) anebo umožňuje filtrovat transparentně (\texttt{l3fwd-acl}), ale poradí si jen s~protokoly na síťové a transportní vrstvě (IP, TCP, UDP), ale ne na linkové
vrstvě (ARP), což vytváří požadavek na statické definování záznamů v~ARP tabulce. Tento problém se projevil při počátečním seznamování se s~frameworkem a na jeho základě
bylo DPDK z~výběru pro testování vyloučeno.

Výsledný seznam tedy je: netfilter + \texttt{iptables}, nftables, PF\_RING a netmap (respektive firewall \texttt{netmap-ipfw}). Verze a licence nástrojů ve výběru lze nalézt v~tabulce \ref{tab:verze}.

\begin{table}[ht]
	\centering
	\begin{tabular}{|l|l|l|}
		\hline
		Název & Licence & Verze \\
		\hline
		\hline
		netfilter + \texttt{iptables} & GPLv2 & 1.4.21 (Linux 3.16) \\
		nftables & GPLv2 & v0.6 (Linux 4.7, viz dále \ref{test:nfinstal}) \\
		PF\_RING & LGPL 2.1 & vývojová verze, listopad 2016 \\
		netmap + \texttt{netmap-ipfw} & BSD 2-Clause & vývojová verze, listopad 2016 \\
		\hline
	\end{tabular}
	\vspace{6mm}
	\caption{Verze a licence vybraných nástrojů pro otestování v~první a druhé fázi testování.}
	\label{tab:verze}
\end{table}

\section{Testovací prostředí}
\label{testovaci-prostredi}

\subsection{Generátor provozu -- Spirent Avalanche 3100B}
\label{generator-provozu}

Spirent Avalanche 3100B je síťové hardwarové zařízení, které slouží k~testování jiných zařízení a aplikací. Dokáže testovat jak výkon daného zařízení/aplikace,
tak odzkoušet zabezpečení či kvalitu dostupných služeb. Pracuje na transportní až aplikační vrstvě referenčního modelu ISO OSI. Zařízení, které bylo použito
k vypracování této práce, má k~dispozici 2$\times$ 10Gbit/s SFP+ a 12$\times$ 1Gbit/s RJ-45 Ethernet rozhraní, dokáže vygenerovat více něž jeden milion HTTP GET dotazů a vytvořit jimi datový tok
několika desítek Gbit/s. Obecně dokáže vytvořit a udržovat až 30 milionů stavových spojení. Všechny důležité informace a podporované protokoly lze najít v~datasheetu \cite{spirent}.
Zátěž lze v~zařízení Spirent Avalanche 3100B definovat různými způsoby, např. určením požadované datové propustnosti či nastavením počtu simulovaných uživatelů. Pro náš
případ se však osvědčilo nastavení počtu provedených transakcí za sekundu. Transakcí je zde myšleno například stažení jedné webové stránky nebo jeden DNS dotaz.


\subsection{Testovací server -- IBM System x3550 M2}
\label{testovaci-server}

Jako testovací stroj byl zvolen server značky IBM a typu System x3550 M2. Server obsahuje dva osmijádrové procesory Intel Xeon L5520 pracujících na frekvenci 2,27 GHz.
Operační paměť má kapacitu 48 GB a pevný disk dokáže uložit až 350 GB dat. Na základní desce se také nachází dvě síťová rozhraní Broadcom NetXtreme II BCM5709 Gigabit Ethernet.
První z~těchto rozhraní bylo použito pro vzdálenou správu systému. Dále byla do serveru přidána PCI Express síťová karta Intel 10-Gigabit X540-AT2, jež byla použita pro testování
nástrojů a knihoven pro filtraci síťového provozu. Karta Intel obsahuje dvě metalická Ethernet rozhraní, která podporují linkové rychlosti 100 Mbit/s, 1 Gbit/s a 10 Gbit/s, ale pouze ve full-duplexním režimu.
Linuxový ovladač pro tato rozhraní se načítá jako jaderný modul a má označení \texttt{ixgbe}.
Jako operační systém byla zvolena linuxová distribuce Debian ve stabilní verzi 8 (kódové označení Jessie) s~jádrem Linux 3.16.

\section{Testovací metody}
\label{testovaci-metody}

Pro otestování funkčnosti a výkonnosti jednotlivých filtrovacích nástrojů byl generátor provozu nastaven tak, aby generoval provoz pro tři různé
protokoly -- TCP, UDP a ICMP. Z~protokolů nad TCP byl vybrán protokol HTTP, který komunikuje na serveru na portu 80, z~aplikačních protokolů nad
UDP byl zvolen protokol DNS, který komunikuje na serveru na portu 53, a z~ICMP byl vybrán typ zprávy 8 -- \uv{Echo request}, který je generován
známým nástrojem \texttt{ping}. Při zkoušení jednotlivých filtrovacích nástrojů bude tedy test opakován několikrát, kdy v~každém opakování bude
zahazován jeden z~protokolů plus bude proveden jeden test na vyzkoušení filtrace podle zdrojové IP adresy. Jelikož Spirent Avalanche 3100B dokáže
generovat provoz z~více zdrojových adresních rozsahů, které pak ve výsledcích dokáže od sebe oddělit, v~případě filtrování podle zdrojové adresy
nás bude zajímat, zda z~jednoho rozsahu prošel veškerý provoz a z~druhého žádný. V~případě filtrování podle protokolů a portů nás bude zajímat, zda
byl vybraný protokol zablokován a ostatní povoleny. Jinými slovy -- ze zablokovaných adresních rozsahů či protokolů musí být všechny transakce neúspěšné,
ostatní transakce by měly být úspěšné.

\section{První fáze -- testování do rychlosti 1 Gbit/s}
\label{pocatecni-faze}

\subsection{Síťová topologie}
\label{prvni-faze-sitova-topologie}

Síťová topologie testovacího prostředí byla zvolena tak, aby žádné další zařízení nemohlo zasahovat do síťového provozu a jakýmkoliv způsobem jej ovlivňovat. Proto byl generátor provozu
připojen přímo k~testovacímu serveru pomocí metalické UTP kabeláže kategorie 6. Jelikož testovací server slouží pouze k~transparentnímu filtrování, provoz generovaný zařízením Spirent Avalanche
3100B musel být někde zakončen a zpracován. Pro tento účel byl opět využit již zmíněný Spirent Avalanche 3100B, který může zároveň fungovat jako generátor (klientská část), tak i~příjemce (serverová část).
Proto byl testovací server propojen s~generátorem (a příjemcem) provozu dvěma rozhraními (viz obrázek \ref{fig:topologie-prostredi}). V~tomto případě sloužil port 4 pro generování provozu a port 5
pro zpracování provozu. Vezmeme-li v~potaz informace z~odstavce \ref{generator-provozu}, je očividné, že maximální linková rychlost tohoto zapojení je 1 Gbit/s. Je to z~toho důvodu, že
metalická rozhraní na zařízení Spirent Avalanche 3100B jsou \uv{jen} gigabitové. To nám ovšem pro počáteční seznámení se s~filtrovacími nástroji a jejich vyzkoušení nevadí. Testovací server
i generátor Avalanche 3100B byl pak také jedním rozhraním připojen do sítě pro vzdálenou parametrizaci a správu.

\vspace{4mm}

\begin{figure}[h]
	\centering
	\includegraphics[width=\textwidth,keepaspectratio=true]{sitova-topologie}
	\vspace{4mm}
	\caption{Tímto způsobem byla zařízení v~první fázi síťově propojena.}
	\label{fig:topologie-prostredi}
\end{figure}

\subsection{Nastavení Spirent Avalanche 3100B}
\label{nastaveni-spirent-avalanche}

Jak bylo popsáno dříve, Spirent Avalanche 3100B funguje jako generátor provozu, tak i~jeho příjemce. Proto je nutné nastavit jak klientkou část,
tak i~serverovou část. Pro server byla zvolena IP adresa \texttt{192.168.1.1}, na níž bude směrován generovaný provoz. Zdrojové IP adresy klientů
byly rozděleny do dvou rozsahů -- první (dále označovaný jako rozsah1) obsahuje adresy \texttt{192.168.1.10-192.168.1.100}, druhý (dále
označovaný jako rozsah2) obsahuje adresy \texttt{192.168.1.110-192.168.1.200}.


\noindent
Samotné nastavení testu bylo provedeno tímto způsobem:
\begin{itemize}
	\item zátěž byla nastavena na 22 000 transakcí za sekundu,
	\item test probíhal 25 sekund a byl nastaven tak, aby ihned po startu začal generovat nastavenou zátěž,
	\item akce, které probíhaly během testu, byly následující:
	\begin{itemize}
		\item \verb+get http://192.168.1.1/index.html+ -- jedná se o~HTTP GET, který vyžaduje stažení 6kB webové stránky nacházející se na daném URL,
		\item \verb+ICMP://192.168.1.1 ECHO LENGTH=64+ -- odeslání 64 B dlouhého ICMP Echo požadavku na adresu \texttt{192.168.1.1},
		\item \verb+DNS A 192.168.1.1 www.spirent.com+ -- odeslání DNS dotazu na přeložení domény www.spirent.com na DNS server \texttt{192.168.1.1},
	\end{itemize}
	\item tímto nastavením byl vygenerován provoz o~průměrné velikosti cca 618 Mbit/s (referenční měření, viz dále).
\end{itemize}

Ještě před samotným testováním nástrojů bylo provedeno referenční měření s~výše uvedeným nastavením, kdy bylo klientské rozhraní (port 4) připojeno kabelem přímo na na rozhraní serverové (port 5).
Výsledek referenčního měření shrnuje tabulka \ref{tab:g1ref} a graf \ref{chart:g1ref}.

\newcommand\http{1}
\newcommand\dns{1}
\newcommand\icmp{1}
%\renewcommand\http{0}
\renewcommand\http{0} %568:\FPeval{http}{(0/1)*100}
\renewcommand\dns{0} %569:\FPeval{dns}{(0/1)*100}
\renewcommand\icmp{0} %570:\FPeval{icmp}{(0/1)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí při referenčním měření podle protokolu.}
	\label{chart:g1ref}
\end{chart}

\subsection{netfilter + iptables}
\label{test:ni}

\subsubsection{Instalace a nastavení}
\label{test:niinstal}

V tomto případě není potřeba cokoliv instalovat. V~Debianu, ale i~dalších linuxových distribucích, je netfilter standardní součástí jádra a \texttt{iptables}
bývá výchozím firewallem, takže ihned po instalaci bývá k~dispozici. Co už ovšem je potřeba nastavit, je přemostění síťových rozhraní, na kterém se pak bude provádět filtrace.
To lze provést například tímto způsobem:

\begin{listing}{1}
# ip link add name br0 type bridge
# ip link set br0 up
# ip link set eth2 up master br0
# ip link set eth3 up master br0
\end{listing}

\noindent
Znak \texttt{\#} na začátku řádku znamená, že je tento příkaz vykonáván uživatelem \texttt{root}.

První řádek vytváří nové rozhraní \texttt{br0} typu most. V~druhém řádku
se nové rozhraní spustí. Řádky 3 a 4 zařadí fyzická rozhraní \texttt{eth2} a \texttt{eth3} (viz obrázek \ref{fig:topologie-prostredi}) do nově vytvořeného mostu, a také je spustí.
Tím se začnou fyzická rozhraní chovat jako rozhraní přepínače. Nyní je možné spustit testy a testovat filtraci.

Jelikož je ve stabilní verzi Debianu verze jádra 3.16, není nutné načítat žádný jaderný modul (viz \ref{netfilter}). V~případě novějších jader by bylo potřeba načíst zásuvný modul \texttt{bridge-netfilter},
což by se provedlo následujícím příkazem:

\begin{listing}{1}
# modprobe br_netfilter
\end{listing}

\subsubsection{Testování -- bez filtrace}

Nejdříve provedeme spuštění testu bez samotné filtrace. Filtrovací tabulka \texttt{iptables} je tedy prázdná:

\begin{listing}{1}
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
\end{listing}

Z tabulky \ref{tab:niwo} a grafu \ref{chart:niwo} vyplývá, že došlo k~nechtěnému zahození 679 ICMP zpráv (tj. 0,24 \% ICMP provozu). Mohlo by to poukazovat na určité limity přemostění síťových rozhraní
v Linuxu. Během měření bylo dosaženo průměrné datové propustnosti zhruba 616 Mbit/s.

\renewcommand\http{0} %631:\FPeval{http}{(0/1)*100}
\renewcommand\dns{0} %632:\FPeval{dns}{(0/1)*100}
\renewcommand\icmp{0.23743666} %633:\FPeval{icmp}{(679/285971)*100}

\begin{chart}[H]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netfilter + \texttt{iptables} -- bez filtrace.}
	\label{chart:niwo}
\end{chart}


\subsubsection{Testování -- filtrace HTTP}

Pro filtrování HTTP zadáme tento příkaz:

\begin{listing}{1}
# iptables -A FORWARD -m physdev --physdev-is-bridged \
      -p tcp -m tcp --dport 80 -j DROP
\end{listing}

Příkaz přidá do řetězce \texttt{FORWARD} filtrovací tabulky pravidlo, které se aplikuje pouze na provoz, který je jádrem přemostěn
(část \verb+-m physdev --physdev-is-bridged+) a jehož transportní protokol je TCP a cílový port 80. Pokud nějaký packet odpovídá těmto
podmínkám, bude zahozen.

Výsledek měření shrnuje graf \ref{chart:nihttp} a tabulka \ref{tab:nihttp}. Jak je vidět, veškerý HTTP provoz byl opravdu odfiltrován a neproběhla žádná úspěšná transakce
na tomto protokolu. Kromě toho došlo k~nechtěnému zahození 4 ICMP zpráv a jedné DNS transakce, což je ale zanedbatelné množství.

\renewcommand\http{100} %703:\FPeval{http}{((168951+168952)/(168952+168951))*100}
\renewcommand\dns{0.00035049472} %704:\FPeval{dns}{((0+1)/(142655+142656))*100}
\renewcommand\icmp{0.0014019592} %705:\FPeval{icmp}{(4/285315)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netfilter + \texttt{iptables} -- filtrace HTTP.}
	\label{chart:nihttp}
\end{chart}


\subsubsection{Testování -- filtrace DNS}

Pro filtraci DNS zadáme podobný příkaz jako u~HTTP, ovšem s~jiným portem a jiným transportním protokolem:

\begin{listing}{1}
# iptables -A FORWARD -m physdev --physdev-is-bridged \
      -p udp -m udp --dport 53 -j DROP
\end{listing}

Příkaz je velice podobný příkazu pro filtrování HTTP provozu, proto zřejmě nepotřebuje další vysvětlování.

Jak je z~tabulky \ref{tab:nidns} vidět, DNS bylo správně zcela odfiltrováno. Jak ovšem ukazuje graf \ref{chart:nidns}, došlo i~k velké nechtěné filtraci HTTP a ICMP. Není zcela jasné, čím byla tato situace způsobena.

\renewcommand\http{2.999013} %740:\FPeval{http}{((4389+4362)/(145898+145898))*100}
\renewcommand\dns{100} %741:\FPeval{dns}{((142353+142376)/(142353+142376))*100}
\renewcommand\icmp{3.9840973} %742:\FPeval{icmp}{(11344/284732)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netfilter + \texttt{iptables} -- filtrace DNS.}
	\label{chart:nidns}
\end{chart}

\subsubsection{Testování -- filtrace ICMP}

Velice podobně jako v~předchozích případech zapíšeme pravidlo pro filtraci ICMP:

\begin{listing}{1}
# iptables -A FORWARD -m physdev --physdev-is-bridged \
      -p icmp -m icmp --icmp-type 8 -j DROP
\end{listing}

Jelikož není ICMP transportní protokol, nefiltrujeme zde podle čísla portu, ale podle typu ICMP zprávy.

V grafu \ref{chart:niicmp} můžeme vidět, že ICMP bylo opravdu odfiltrováno, ovšem spolu s~ním částečně i~ostatní protokoly (viz také tabulku \ref{tab:niicmp}).


\renewcommand\http{0.1209942} %777:\FPeval{http}{((182+172)/(146288+146288))*100}
\renewcommand\dns{0.080249666} %778:\FPeval{dns}{((112+122)/(145797+145793))*100}
\renewcommand\icmp{100} %779:\FPeval{icmp}{(292233/292233)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netfilter + \texttt{iptables} -- filtrace ICMP.}
	\label{chart:niicmp}
\end{chart}

\vspace{-5mm}

\subsubsection{Testování -- filtrace rozsahu IP adres}

V případě, že chceme filtrovat rozsah IP adres, máme několik možností, jak to udělat. Buď můžeme zadat zdrojovou adresu jako podsíť (adresa sítě + prefix), nebo pokud nechceme celou podsíť, ale jen její část, můžeme využít rozšíření \texttt{iprange}:

\begin{listing}{1}
# iptables -A FORWARD -m physdev --physdev-is-bridged -m iprange \
       --src-range 192.168.1.110-192.168.1.200 -j DROP
\end{listing}

Jak je v~příkazu vidět, používáme rozšíření \texttt{iprange} a argumentem \texttt{--src-range} definujeme rozsah zdrojových adres, kterých se má pravidlo týkat.

Tabulka \ref{tab:nisubnet} a graf \ref{chart:nisubnet} dokazují, že opravdu došlo k~odfiltrování provozu z~vybraného rozsahu IP adres, kdežto druhý rozsah zůstal povolen.

\renewcommand\http{0} %814:\FPeval{http}{((0+0)/(166354+166354))*100}
\renewcommand\dns{100} %815:\FPeval{dns}{((166353+88264)/(166353+88264))*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph,
			symbolic x coords={rozsah1, rozsah2},
			xtick=data,
			height=5cm,
			width=6.5cm,
			ymin=0,
			ymax=100,
			ylabel=\%,
			nodes near coords,
			nodes near coords align={vertical},
			x tick label style={align=center,text width=2.5cm}
		]
			\addplot[ybar,fill=black] coordinates {
				(rozsah1,  \http)
				(rozsah2,   \dns)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netfilter + \texttt{iptables} -- filtrace rozsahu IP adres.}
	\label{chart:nisubnet}
\end{chart}

\vspace{-3mm}

\subsection{nftables}
\label{test:nf}

\subsubsection{Instalace a nastavení}
\label{test:nfinstal}

Od verze jádra Linux 3.13 jsou nftables jeho standardní součástí, proto je potřeba doinstalovat jen utilitu \texttt{nft}.
To v~prostředí Debianu a jeho derivátů provedeme příkazem:

\vspace{-1mm}

\begin{listing}{1}
# apt-get install nftables
\end{listing}

Tím dojde k~nainstalování ovládací aplikace. Na rozdíl od \texttt{iptables} nemají nftables přednastavené tabulky a řetězce pro přidávání
pravidel. K~tomuto účelu jsou v~adresáři \texttt{/usr/share/doc/nftables/examples/syntax/} ukázkové skripty, které lze využít. My využijeme
soubor \texttt{bridge-filter}:

\begin{listing}{1}
# nft -f /usr/share/doc/nftables/examples/syntax/bridge-filter
\end{listing}

\noindent
Tím dojte k~vytvoření podobné struktury jako u~\texttt{iptables}:

\begin{listing}{1}
# nft -a list table bridge filter
table bridge filter {
        chain input {
                type filter hook input priority -200; policy accept;
        }

        chain forward {
                type filter hook forward priority -200; policy accept;
        }

        chain output {
                type filter hook output priority 200; policy accept;
        }
}
\end{listing}

Nastavení přemostění síťových rozhraní se provede stejně jako v~\ref{test:niinstal}. Tím by bylo prostředí pro nftables připraveno. Ovšem
během testování bylo zjištěno, že v~jádře 3.16 stabilní verze Debianu nefunguje filtrace pomocí určení cílového portu transportního protokolu.
Proto byl z~repozitáře \uv{backports} doinstalován balíček s~jádrem verze 4.7, na kterém byl test nftables prováděn.

\subsubsection{Testování -- bez filtrace}

Stejně jako v~podsekci \ref{test:ni} provedeme nejdříve testování bez pravidel. Z~grafu \ref{chart:nfwo} a tabulky \ref{tab:nfwo} vidíme, že došlo k~zanedbatelnému počtu zahození ICMP
zpráv. Ostatní protokoly byly přeneseny 100\% úspěšně. Při tomto testu dosáhla datová propustnost průměrné velikosti 617 Mbit/s.

\renewcommand\http{0} %895:\FPeval{http}{((0+0)/(143229+143229))*100}
\renewcommand\dns{0} %896:\FPeval{dns}{((0+0)/(145797+145793))*100}
\renewcommand\icmp{0.01326547} %897:\FPeval{icmp}{(38/286458)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: nftables -- bez filtrace.}
	\label{chart:nfwo}
\end{chart}


\subsubsection{Testování -- filtrace HTTP}

Nyní provedeme filtraci HTTP provozu:

\begin{listing}{1}
# nft add rule bridge filter forward ether type ip \
    tcp dport 80 drop
\end{listing}

Tento příkaz přidá do tabulky \texttt{bridge filter} a řetězce \texttt{forward} pravidlo, že pokud bude rámec L2 obsahovat IP provoz
(\texttt{ether type ip}) a v~transportní vrstvě bude přenášen TCP provoz směřující na port 80 (\texttt{tcp dport 80}), bude rámec zahozen (\texttt{drop}).
Graf \ref{chart:nfhttp} shrnuje očekávaný výsledek (viz také tabulku \ref{tab:nfhttp}):

\renewcommand\http{100} %929:\FPeval{http}{(339820/339820)*100}
\renewcommand\dns{0.0010507918} %930:\FPeval{dns}{(3/285499)*100}
\renewcommand\icmp{0.0017512889} %931:\FPeval{icmp}{(5/285504)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: nftables -- filtrace HTTP.}
	\label{chart:nfhttp}
\end{chart}


\subsubsection{Testování -- filtrace DNS}

Podobně jako HTTP vyfiltrujeme i~DNS. Pouze určíme, že se jedná o~UDP provoz a cílový port je 53:

\begin{listing}{1}
# nft add rule bridge filter forward ether type ip \
    udp dport 53 drop
\end{listing}

\noindent
Výsledek měření je dle očekávání a je možné ho naleznout v~grafu \ref{chart:nfdns} a tabulce \ref{tab:nfdns}.

\renewcommand\http{0.015025666} %961:\FPeval{http}{(43/286177)*100}
\renewcommand\dns{100} %962:\FPeval{dns}{(286134/286134)*100}
\renewcommand\icmp{0.063606562} %963:\FPeval{icmp}{(182/286134)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: nftables -- filtrace DNS.}
	\label{chart:nfdns}
\end{chart}


\subsubsection{Testování -- filtrace ICMP}

Stejně jako u~\texttt{iptables} se i~zde mírně změní filtrovací příkaz

\begin{listing}{1}
# nft add rule bridge filter forward ether type ip \
    icmp type 8 drop
\end{listing}

Jak bychom čekali, graf \ref{chart:nficmp} dokládá, že i~filtrace ICMP byla úspěšná. Z~tabulky \ref{tab:nficmp} lze vyčíst přesné hodnoty.

\renewcommand\http{0.0061158755} %994:\FPeval{http}{(18/294316)*100}
\renewcommand\dns{0} %995:\FPeval{dns}{(0/294294)*100}
\renewcommand\icmp{100} %996:\FPeval{icmp}{(294298/294298)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: nftables -- filtrace ICMP.}
	\label{chart:nficmp}
\end{chart}


\subsubsection{Testování -- filtrace rozsahu IP adres}

Na rozdíl od \texttt{iptables}, není potřeba kvůli filtrování rozsahu načítat do nftables žádný modul. Nftables podporují rozsahy adres již v~základu:

\begin{listing}{1}
# nft add rule bridge filter forward ether type ip \
       ip saddr {192.168.1.110-192.168.1.200} drop
\end{listing}

Speciální syntaxí se složenými závorkami definujeme množinu hodnot. Můžeme ji zadat buď jako seznam oddělený čárkami, rozsahem, či kombinací.
Po spuštění testu dostaneme výsledek, jenž shrnuje tabulka \ref{tab:nfsubnet} a graficky vyjadřuje graf \ref{chart:nfsubnet}. Filtrování rozsahu IP adres tedy funguje správně.

\renewcommand\http{0} %1027:\FPeval{http}{((0+0)/(166464+166464))*100}
\renewcommand\dns{100} %1028:\FPeval{dns}{((166464+88338)/(166464+88338))*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph,
			symbolic x coords={rozsah1, rozsah2},
			xtick=data,
			height=5cm,
			width=6.5cm,
			ymin=0,
			ymax=100,
			ylabel=\%,
			nodes near coords,
			nodes near coords align={vertical},
			x tick label style={align=center,text width=2.5cm}
		]
			\addplot[ybar,fill=black] coordinates {
				(rozsah1,  \http)
				(rozsah2,   \dns)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: nftables -- filtrace rozsahu IP adres.}
	\label{chart:nfsubnet}
\end{chart}


\subsection{PF\_RING}
\label{test:pfring}

\subsubsection{Instalace a nastavení}
\label{test:pfringinstall}

PF\_RING již není součástí standardního balíčkovacího systému, a tudíž je nutné stáhnout jeho zdrojové kódy a ručně zkompilovat.
Aby mohla být kompilace úspěšná, musíme doinstalovat další požadované balíčky tímto příkazem:

\begin{listing}{1}
# apt-get install git build-essential bison \
    flex linux-headers-$(uname -r) libnuma-dev
\end{listing}

Nyní můžeme přistoupit ke stažení zdrojových kódů a jejich kompilaci. Stažení provedeme z~veřejného repozitáře GitHub:

\begin{listing}{1}
# git clone https://github.com/ntop/PF_RING.git
# cd PF_RING
\end{listing}

\noindent
Pro zkompilování zdrojových kódů použijeme příkaz:

\begin{listing}{1}
# make
\end{listing}

Pokud proběhne kompilace úspěšně, je v~adresáři \texttt{kernel} vytvořen soubor \texttt{pf\_ring.ko}, což je jaderný modul,
který je pro správnou funkci potřeba načíst:

\begin{listing}{1}
# cd kernel
# insmod pf_ring.ko
# cd ..
\end{listing}

V tuto chvíli již je možné spouštět PF\_RING aplikace. Nás bude nejvíce zajímat program \texttt{pfbridge} v~adresáři \texttt{userland/examples}.
Nápověda tohoto prográmku vypadá následovně:

\begin{listing}{1}
# cd userland/examples/
# ./pfbridge -h
pfbridge - Forwards traffic from -a -> -b device using vanilla PF_RING

-h              [Print help]
-v              [Verbose]
-p              [Use pfring_send() instead of bridge]
-a <device>     [First device name]
-b <device>     [Second device name]
-g <core_id>    Bind this app to a core
-w <watermark>  Watermark
\end{listing}

Jak je z~nápovědy patrné, program přeposílá rámce z~jednoho rozhraní na druhé. Pokud tedy chceme oboustrannou komunikaci, musíme prográmek pustit dvakrát.
To nejjednodušeji provedeme v~dalším terminálu. Ačkoliv není v~nápovědě zmínka o~filtrovací volbě, ze zdrojového kódu této utility lze vyčíst, že rozpoznává
ještě argument \texttt{-f}, jehož hodnotou může být filtr v~BPF syntaxi (např. \texttt{tcpdump} používá stejnou syntaxi). Bližší informace o~BPF syntaxi lze nalézt v~\cite{bpf}. Při použití volby \texttt{-f} je výchozí politikou
\uv{zahoď vše}, tzn. že ve filtru musíme explicitně určit to, co má být povoleno. Prostředí je připravené, můžeme přistoupit k~samotnému testování.


\subsubsection{Testování -- bez filtrace}

Pro otestování pouhého předávání rámců spustíme ve dvou různých terminálech (ozn. \texttt{term1} a \texttt{term2}) tyto příkazy:

\begin{listing}{1}
(term1)# ./pfbridge -a eth2 -b eth3
(term2)# ./pfbridge -a eth3 -b eth2
\end{listing}

Až na pár nepodstatných zahození je výsledek měření v~tabulce \ref{tab:pfwo} očekávaný (viz graf \ref{chart:pfwo}). Průměrná rychlost přenosu byla necelých 617 Mbit/s.

\renewcommand\http{0} %1138:\FPeval{http}{(0/286314)*100}
\renewcommand\dns{0} %1139:\FPeval{dns}{(0/286314)*100}
\renewcommand\icmp{0.0048897364} %1140:\FPeval{icmp}{(14/286314)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: PF\_RING -- bez filtrace.}
	\label{chart:pfwo}
\end{chart}


\subsubsection{Testování -- filtrace HTTP}

Pro filtraci HTTP již musíme použít parametr \texttt{-f}:

\begin{listing}{1}
(term1)# ./pfbridge -a eth2 -b eth3 -f "not tcp dst port 80"
(term2)# ./pfbridge -a eth3 -b eth2 -f "not tcp dst port 80"
\end{listing}

Notací \texttt{"not tcp dst port 80"} říkáme, že má být povoleno vše, co není TCP provoz směřující na port 80.
Výsledek v~tabulce \ref{tab:pfhttp} je opět spíše očekávaný. Grafické znázornění tabulky ukazuje graf \ref{chart:pfhttp}.

\renewcommand\http{100} %1171:\FPeval{http}{(339242/339242)*100}
\renewcommand\dns{0.00070095259} %1172:\FPeval{dns}{(2/285326)*100}
\renewcommand\icmp{0.0024532739} %1173:\FPeval{icmp}{(7/285333)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: PF\_RING -- filtrace HTTP.}
	\label{chart:pfhttp}
\end{chart}

\subsubsection{Testování -- filtrace DNS}

Podobně jako pro HTTP vytvoříme filtr DNS provozu:

\begin{listing}{1}
(term1)# ./pfbridge -a eth2 -b eth3 -f "not udp dst port 53"
(term2)# ./pfbridge -a eth3 -b eth2 -f "not udp dst port 53"
\end{listing}

\noindent
Výsledek shrnuje tabulka \ref{tab:pfdns} a graf \ref{chart:pfdns}.

\renewcommand\http{0} %1203:\FPeval{http}{(0/286059)*100}
\renewcommand\dns{100} %1204:\FPeval{dns}{(286059/286059)*100}
\renewcommand\icmp{0.044396436} %1205:\FPeval{icmp}{(127/286059)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: PF\_RING -- filtrace DNS.}
	\label{chart:pfdns}
\end{chart}

\vspace{-4mm}

\subsubsection{Testování -- filtrace ICMP}

Jelikož ICMP není transportním protokolem, je i~syntaxe filtru mírně odlišná a přizpůsobená požadavkům ICMP:

\begin{listing}{1}
(term1)# ./pfbridge -a eth2 -b eth3 -f "not icmp[icmptype]=icmp-echo"
(term2)# ./pfbridge -a eth3 -b eth2 -f "not icmp[icmptype]=icmp-echo"
\end{listing}

Hranatými závorkami ve filtru říkáme, že nás z~ICMP hlavičky zajímá pole \texttt{icmptype}, a to se musí rovnat konstantě \texttt{icmp-echo} (lze použít i~dekadickou hodnotu 8).
Výsledek tohoto měření je vyjádřen grafem \ref{chart:pficmp} a samozřejmě tabulkou \ref{tab:pficmp}.

\renewcommand\http{0} %1238:\FPeval{http}{(0/294328)*100}
\renewcommand\dns{0} %1239:\FPeval{dns}{(0/294324)*100}
\renewcommand\icmp{100} %1240:\FPeval{icmp}{(294328/294328)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: PF\_RING -- filtrace ICMP.}
	\label{chart:pficmp}
\end{chart}

\vspace{-4mm}

\subsubsection{Testování -- filtrace rozsahu IP adres}

Zadávání rozsahu IP adres, který neodpovídá podsíti, je v~BPF syntaxi problém. Proto musel být příkaz složen z~několika podmínek:

\begin{listing}{1}
(term1)# ./pfbridge -a eth2 -b eth3 -f "not src host 192.168.1.110 \
                                    and not src host 192.168.1.111 \
                                    and not src net 192.168.1.112/28 \
                                    and not src net 192.168.1.128/26 \
                                    and not src net 192.168.1.192/29 \
                                    and not src host 192.168.1.200"
(term2)# ./pfbridge -a eth3 -b eth2 -f "not src host 192.168.1.110 \
                                    and not src host 192.168.1.111 \
                                    and not src net 192.168.1.112/28 \
                                    and not src net 192.168.1.128/26 \
                                    and not src net 192.168.1.192/29 \
                                    and not src host 192.168.1.200"
\end{listing}

Celý rozsah2 = \texttt{192.168.1.110-192.168.1.200} byl rozdělen na několik samostatných adres a několik podsítí. Samostatné výrazy pak byly spojeny logickou konjunkcí.
Ačkoliv není filtr zadán přímočaře, výsledek zobrazený v~grafu \ref{chart:pfsubnet} a tabulce \ref{tab:pfsubnet} odpovídá požadovanému.

\renewcommand\http{0} %1281:\FPeval{http}{((0+0)/(166464+166464))*100}
\renewcommand\dns{100} %1282:\FPeval{dns}{((166464+88338)/(166464+88338))*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph,
			symbolic x coords={rozsah1, rozsah2},
			xtick=data,
			height=5.3cm,
			width=6.5cm,
			ymin=0,
			ymax=100,
			ylabel=\%,
			nodes near coords,
			nodes near coords align={vertical},
			x tick label style={align=center,text width=2.5cm}
		]
			\addplot[ybar,fill=black] coordinates {
				(rozsah1,  \http)
				(rozsah2,   \dns)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: PF\_RING -- filtrace rozsahu IP adres.}
	\label{chart:pfsubnet}
\end{chart}

\vspace{2mm}

\subsection{netmap}
\label{test:netmap}

\vspace{2mm}

\subsubsection{Instalace a nastavení}
\label{test:netmapinstall}

Stejně jako PF\_RING není ani netmap součástí balíčkovacího systému Debianu a je nutné ho zkompilovat.
Požadavky na nainstalované balíky a hlavičkové soubory jsou podobné jako u~PF\_RINGu (viz podsekce \ref{test:pfringinstall}).
Pokud jsou tedy nainstalované, můžeme přistoupit ke stažení zdrojových kódů a kompilaci. Zdrojové kódy stáhneme opět z~GitHubu:

\vspace{1mm}

\begin{listing}{1}
# git clone https://github.com/luigirizzo/netmap.git
# cd netmap/LINUX
\end{listing}

\vspace{1mm}

V adresáři \texttt{LINUX} jsou všechny potřebné kódy pro platformu Linux. Kompilace se provede standardním způsobem:

\vspace{1mm}

\begin{listing}{1}
# ./configure
# make
\end{listing}

\vspace{1mm}

Po kompilaci vznikne v~adresáři soubor \texttt{netmap.ko}, což je zásuvný modul do jádra, který se stará o~komunikaci mezi ovladačem síťové karty
a netmap aplikacemi. Načteme jej do jádra:

\begin{listing}{1}
# insmod netmap.ko
# cd ../../
\end{listing}

Nyní je potřeba stáhnout a zkompilovat samotný firewall \texttt{netmap-ipfw}. Stáhneme jej z~GitHubu do stejného adresáře, ve kterém se nachází adresář s~netmapem:

\begin{listing}{1}
# git clone https://github.com/luigirizzo/netmap-ipfw.git
# cd netmap-ipfw
\end{listing}

Při kompilaci musíme určit cestu k~adresáři \texttt{sys/} ze zdrojových kódů samotného netmapu:

\begin{listing}{1}
# make NETMAP_INC=../netmap/sys
\end{listing}

Tím dojde k~vytvoření binárního souboru \texttt{kipfw} a \texttt{ipfw/ipfw}. \texttt{kipfw} je démon, který se stará o~přemostění síťových rozhraní
a aplikování nastavených filtrovacích pravidel. \texttt{ipfw/ipfw} slouží ke správě pravidel firewallu. Dříve než ale budeme moci firewall spustit,
musíme přepnout síťová rozhraní do promiskuitního módu, jinak by komunikace nefungovala:

\begin{listing}{1}
# ip link set eth2 promisc on
# ip link set eth3 promisc on
\end{listing}

Následně můžeme spustit firewall démona a předat mu názvy síťových rozhraní, mezi kterými má filtrovat:

\begin{listing}{1}
# ./kipfw netmap:eth2 netmap:eth3
\end{listing}

Démona necháme běžet a v~jiném terminálu si můžeme prohlédnout aktuální filtrovací tabulku:

\begin{listing}{1}
# cd ./ipfw
# ./ipfw show
65535 0 0 allow ip from any to any
\end{listing}

To znamená, že poslední pravidlo (s pořadovým číslem 65 535) povoluje vše. Toto je základní instalace a nastavení, aby netmap spolu s~\texttt{netmap-ipfw} fungoval.


\subsubsection{Testování -- bez filtrace}

Jelikož jsme nechali \texttt{kipfw} běžet a výchozí pravidlo povoluje vše, můžeme vyzkoušet propustnost bez filtrace. Až na pár zahození je výsledek zobrazený v~grafu \ref{chart:nmwo} dle očekávání (viz také tabulku \ref{tab:nmwo}).
V tomto případě dosáhla datová propustnost průměrné velikosti 615 Mbit/s. 

\renewcommand\http{0} %1392:\FPeval{http}{(0/285434)*100}
\renewcommand\dns{0} %1393:\FPeval{dns}{(0/285434)*100}
\renewcommand\icmp{0.048697773} %1394:\FPeval{icmp}{(139/285434)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netmap -- bez filtrace.}
	\label{chart:nmwo}
\end{chart}

\subsubsection{Testování -- filtrace HTTP}

Abychom vyfiltrovali HTTP, musíme přidat pravidlo:

\begin{listing}{1}
# ./ipfw add drop tcp from any to any dst-port 80
\end{listing}

Pravidlo říká, že bude zahozen veškerý TCP provoz z~kterékoliv IP adresy (\texttt{from any}) mířící na jakoukoliv IP adresu (\texttt{to any}) na port 80.
Výsledkem měření je graf \ref{chart:nmhttp} a tabulka \ref{tab:nmhttp}.

\renewcommand\http{100} %1428:\FPeval{http}{(343151/343151)*100}
\renewcommand\dns{0.00070104596} %1429:\FPeval{dns}{(2/285288)*100}
\renewcommand\icmp{0.0014020723} %1430:\FPeval{icmp}{(4/285292)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netmap -- filtrace HTTP.}
	\label{chart:nmhttp}
\end{chart}


\subsubsection{Testování -- filtrace DNS}

Stejně jako u~ostatních testovaných nástrojů je syntaxe filtru DNS podobná filtraci HTTP:

\begin{listing}{1}
# ./ipfw add drop udp from any to any dst-port 53
\end{listing}

\noindent
Výsledek měření v~tabulce \ref{tab:nmdns} je znázorněn grafem \ref{chart:nmdns}.

\renewcommand\http{0} %1460:\FPeval{http}{(0/284794)*100}
\renewcommand\dns{100} %1461:\FPeval{dns}{(284794/284794)*100}
\renewcommand\icmp{0.0056180959} %1462:\FPeval{icmp}{(16/284794)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netmap -- filtrace DNS.}
	\label{chart:nmdns}
\end{chart}


\subsubsection{Testování -- filtrace ICMP}

Syntaxe pro filtr ICMP se příliš neliší od filtrace transportních protokolů:

\begin{listing}{1}
# ./ipfw add drop icmp from any to any icmptypes 8
\end{listing}

V tomto případě zadáváme místo cílového portu typ ICMP zprávy.
Graf \ref{chart:nmicmp} dokládá, že i~filtrace ICMP byla úspěšná (viz také tabulku \ref{tab:nmicmp}).

\renewcommand\http{0} %1492:\FPeval{http}{(0/295184)*100}
\renewcommand\dns{0.00033880044} %1493:\FPeval{dns}{(1/295159)*100}
\renewcommand\icmp{100} %1494:\FPeval{icmp}{(295184/295184)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netmap -- filtrace ICMP.}
	\label{chart:nmicmp}
\end{chart}


\subsubsection{Testování -- filtrace rozsahu IP adres}

Ani \texttt{netmap-ipfw} neumožňuje zadat přímo rozsah IP adres, ale na rozdíl od PF\_RINGu je možné samostatné adresy a podsítě zadat jako seznam oddělený čárkami:

\begin{listing}{1}
# ./ipfw add drop ip from 192.168.1.110,192.168.1.111, \
      192.168.1.112/28,192.168.1.128/26,192.168.1.192/29, \
      192.168.1.200 to any
\end{listing}

Opět byl tedy rozsah2 rozdělen na jednotlivé adresy a podsítě a jako seznam zadán do volby \texttt{from}. Filtrace IP rozsahu opět fungoval správně (viz tabulka \ref{tab:nmsubnet}).
Grafické znázornění výsledku, které vychází z~tabulky \ref{tab:nmsubnet}, je v~grafu \ref{chart:nmsubnet}.

\renewcommand\http{0} %1528:\FPeval{http}{((0+0)/(166464+166464))*100}
\renewcommand\dns{100} %1529:\FPeval{dns}{((166464+88338)/(166464+88338))*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph,
			symbolic x coords={rozsah1, rozsah2},
			xtick=data,
			height=5cm,
			width=6.5cm,
			ymin=0,
			ymax=100,
			ylabel=\%,
			nodes near coords,
			nodes near coords align={vertical},
			x tick label style={align=center,text width=2.5cm}
		]
			\addplot[ybar,fill=black] coordinates {
				(rozsah1,  \http)
				(rozsah2,   \dns)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netmap -- filtrace rozsahu IP adres.}
	\label{chart:nmsubnet}
\end{chart}


\section{Druhá fáze -- testování do rychlosti 10 Gbit/s}
\label{druha-faze}

Během opakovaného proměřování vybraných nástrojů na rychlosti do 10 Gbit/s byly provedeny naprosto stejné úkony a příkazy, které byly provedeny v~první fázi. Proto již dále nebudou tyto činnosti popisovány. Pokud by ovšem nastala nějaká změna, bude v~textu samozřejmě popsána.

\subsection{Síťová topologie}
\label{druha-faze-sitova-topologie}

Jelikož má generátor provozu 10Gbit/s rozhraní pouze typu SFP+ s~vloženými optickými moduly, bylo nutné vyřešit konverzi signálu z~optického na elektrický, protože testovaný server měl k~dispozici jen metalická rozhraní.
K tomuto účel posloužil přepínač Cisco řady 4900, který nabízí jak SFP+, tak metalické porty pro rychlost 10 Gbit/s. Do něj tedy byly Spirent Avalanche 3100B i~testovací server připojeni. Aby bylo zaručeno, že generovaný provoz
bude procházet přes testovací server, byly v~rámci přepínače vytvořeny dvě virtuální sítě (VLAN), a do každé z~nich bylo přidáno jedno rozhraní od obou zařízení. Tím se zaručilo, že provoz se nemohl dostat jinou cestou než přes
testovací server. Celou topologii lze zhlédnout na obrázku \ref{fig:topologieprostredi10g}. V~tomto případě bylo pro generování provozu použito rozhraní 12 a rozhraní 13 pro zpracování provozu.

\begin{figure}[h]
	\centering
	\includegraphics[width=\textwidth,keepaspectratio=true]{sitova-topologie-10g}
	\vspace{4mm}
	\caption{Tímto způsobem byla zařízení síťově propojena ve druhé fázi. Čárkovaná čára znamená optické propojení, plná čára značí metalické propojení.}
	\label{fig:topologieprostredi10g}
\end{figure}

\subsection{Nastavení Spirent Avalanche 3100B}
\label{nastavenispirentavalanche10g}

Z pohledu adresování byl Spirent Avalanche 3100B nastaven stejně jako v~první fázi testování (viz \ref{nastaveni-spirent-avalanche}). Co se ale muselo změnit byla generovaná zátěž, a tedy akce při testu vykonávané.
Nastavení testu bylo provedeno tímto způsobem:
\begin{itemize}
	\item zátěž byla nastavena na 17 000 transakcí za sekundu,
	\item test probíhal 25 sekund a byl nastaven tak, aby ihned po startu začal generovat nastavenou zátěž,
	\item akce, které probíhaly během testu, byly následující:
	\begin{itemize}
		\item 350$\times$ \verb+get http://192.168.1.1/index.html+ -- jedná se o~HTTP GET, který vyžaduje stažení 30kB webové stránky nacházející se na daném URL,
		\item 15$\times$ \verb+ICMP://192.168.1.1 ECHO LENGTH=1472+ -- odeslání 1472 B dlouhého ICMP Echo požadavku na adresu \texttt{192.168.1.1},
		\item 15$\times$ \verb+DNS A 192.168.1.1 www.spirent.com+ -- odeslání DNS dotazu na přeložení domény www.spirent.com na DNS server \texttt{192.168.1.1}, jehož odpovědí je jeden A záznam,
	\end{itemize}
	\item tímto nastavením byl vygenerován provoz o~průměrné rychlosti cca 8,4 Gbit/s (referenční měření, viz dále).
\end{itemize}

Stejně jako v~první fázi bylo před samotným testováním provedeno referenční měření. To probíhalo při přímém propojení portu 12 a 13 na zařízení Spirent Avalanche 3100B pomocí optického propojovacího kabelu. Naměřené hodnoty jsou shrnuty v~tabulce \ref{tab:g10ref} a jejich grafické znázornění zobrazuje graf \ref{chart:g10ref}.

\renewcommand\http{0} %1602:\FPeval{http}{(0/823056)*100}
\renewcommand\dns{0} %1603:\FPeval{dns}{(0/102026)*100}
\renewcommand\icmp{0} %1604:\FPeval{icmp}{(0/102940)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí při referenčním měření na rychlosti 10 Gbit/s. Očekávaně k~žádnému neúspěchu nedošlo.}
	\label{chart:g10ref}
\end{chart}

\subsection{netfilter + iptables}
\label{test10g:ni}

\subsubsection{Testování -- bez filtrace}

Nejdříve bylo provedeno měření bez jakéhokoliv zásahu do filtrovací tabulky. Výsledek je zaznamenán v~tabulce \ref{tab:ni10gwo} a zobrazen grafem \ref{chart:ni10gwo}. V~tabulce je vidět, že ačkoliv nebyla filtrace povolena, došlo k~docela značnému zahazování provozu ($\sim$5,17 \%).
To poukazuje na limity přemostění síťových rozhraní pomocí jádra Linux. Při tomto měření bylo dosaženo průměrné datové propustnosti cca 3,49~Gbit/s.

\renewcommand\http{10.118889} %1630:\FPeval{http}{(37109/366730)*100}
\renewcommand\dns{0.092379919} %1631:\FPeval{dns}{(183/198095)*100}
\renewcommand\icmp{0.58009792} %1632:\FPeval{icmp}{(1019/175660)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netfilter + \texttt{iptables} -- bez filtrace.}
	\label{chart:ni10gwo}
\end{chart}


\subsubsection{Testování -- filtrace HTTP}

\noindent
Výsledek měření při filtraci HTTP zobrazuje graf \ref{chart:ni10ghttp} a tabulka \ref{tab:ni10ghttp}.

\renewcommand\http{100} %1656:\FPeval{http}{(238488/238488)*100}
\renewcommand\dns{0.014048961} %1657:\FPeval{dns}{(278/1978794)*100}
\renewcommand\icmp{0.01371354} %1658:\FPeval{icmp}{(270/1968857)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netfilter + \texttt{iptables} -- filtrace HTTP.}
	\label{chart:ni10ghttp}
\end{chart}

Při filtraci HTTP došlo správně k~jeho úplnému odstranění z~provozu a zároveň došlo k~zahození i~ostatního provozu. Toto ovlivnění je však velmi malé (setiny procenta).
Při tomto, ale i~dalších filtracích, nemá cenu uvádět průměrnou rychlost přenosu, jelikož odfiltrováním části provozu musí zákonitě dojít ke snížení datové propustnosti,
a tudíž jsou výsledky vůči referenčnímu měření této hodnoty neporovnatelné. Spíše nás zajímá ovlivnění nefiltrovaného provozu.


\subsubsection{Testování -- filtrace DNS}

Výsledek tohoto testu vyjadřuje graf \ref{chart:ni10gdns} a tabulka \ref{tab:ni10gdns}.

\renewcommand\http{0.038527304} %1685:\FPeval{http}{(283/734544)*100}
\renewcommand\dns{100} %1686:\FPeval{dns}{(27807/27807)*100}
\renewcommand\icmp{0.011689176} %1687:\FPeval{icmp}{(13/111214)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netfilter + \texttt{iptables} -- filtrace DNS.}
	\label{chart:ni10gdns}
\end{chart}

\subsubsection{Testování -- filtrace ICMP}

\noindent
Tabulka \ref{tab:ni10gicmp} shrnuje výsledek tohoto měření. Z~uvedené tabulky vychází i~graf \ref{chart:ni10gicmp}.

\renewcommand\http{7.104374} %1710:\FPeval{http}{(28008/394236)*100}
\renewcommand\dns{0.010411922} %1711:\FPeval{dns}{(40/384175)*100}
\renewcommand\icmp{100} %1712:\FPeval{icmp}{(75306/75306)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netfilter + \texttt{iptables} -- filtrace ICMP.}
	\label{chart:ni10gicmp}
\end{chart}

Na tomto měření je vidět, že kromě odstranění ICMP provozu došlo i~k nezanedbatelnému zahození HTTP provozu (cca 7,1 \%).


\subsubsection{Testování -- filtrace rozsahu IP adres}

Výsledek tohoto měření je vyjádřen tabulkou \ref{tab:ni10gsubnet} a grafem \ref{chart:ni10gsubnet}.

\renewcommand\http{1.8715438} %1737:\FPeval{http}{((9446+37)/(404048+102646))*100}
\renewcommand\dns{100} %1738:\FPeval{dns}{((48616+14683)/(48616+14683))*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph,
			symbolic x coords={rozsah1, rozsah2},
			xtick=data,
			height=5cm,
			width=6.5cm,
			ymin=0,
			ymax=100,
			ylabel=\%,
			nodes near coords,
			nodes near coords align={vertical},
			x tick label style={align=center,text width=2.5cm}
		]
			\addplot[ybar,fill=black] coordinates {
				(rozsah1,  \http)
				(rozsah2,   \dns)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netfilter + \texttt{iptables} -- filtrace rozsahu IP adres.}
	\label{chart:ni10gsubnet}
\end{chart}

I při tomto měření došlo k~celkem velkému ovlivnění HTTP provozu z~rozsahu adres, který měl projít beze ztráty.

\subsection{nftables}
\label{test10g:nf}

\subsubsection{Testování -- bez filtrace}

Opět bylo provedeno nejdříve měření bez jediného filtrovacího pravidla.
Výsledek je dán tabulkou \ref{tab:nf10gwo} a z~ní vycházejícím grafem \ref{chart:nf10gwo}.

\renewcommand\http{0.20445214} %1778:\FPeval{http}{(1330/650519)*100}
\renewcommand\dns{0} %1779:\FPeval{dns}{(0/161151)*100}
\renewcommand\icmp{0.015512351} %1780:\FPeval{icmp}{(21/135376)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: nftables -- bez filtrace.}
	\label{chart:nf10gwo}
\end{chart}

Porovnáme-li výsledky s~tabulkou \ref{tab:ni10gwo} (netfilter + \texttt{iptables} -- bez filtrace), zjistíme, že došlo k~zásadnímu vylepšení výkonu 
-- provedlo se více transakcí, a zároveň došlo ke snížení ztrátovosti. Datová propustnost byla průměrně 6,6~Gbit/s. Toto zlepšení může být
způsobeno jak vylepšeními nftables oproti netfilteru + \texttt{iptables}, tak novějším jádrem Linux (zdůvodnění použití novějšího jádra pro testování nftables lze nalézt v~podsekci \ref{test:nfinstal}).


\subsubsection{Testování -- filtrace HTTP}

Výsledek filtrace HTTP pomocí nftables ukazuje graf \ref{chart:nf10ghttp} a tabulka \ref{tab:nf10ghttp}.

\renewcommand\http{100} %1807:\FPeval{http}{(238830/238830)*100}
\renewcommand\dns{0.013602289} %1808:\FPeval{dns}{(270/1984960)*100}
\renewcommand\icmp{0.013989438} %1809:\FPeval{icmp}{(276/1972917)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: nftables -- filtrace HTTP.}
	\label{chart:nf10ghttp}
\end{chart}

Provedeme-li porovnání s~tabulkou \ref{tab:ni10ghttp}, vidíme, že dosažené výsledky jsou v~tomto případě srovnatelné. Je to nejspíš z~toho důvodu,
že odstraněním datově náročného provozu není zátěž tak vysoká, aby si s~ní nftables ani netfilter + \texttt{iptables} neporadily.


\subsubsection{Testování -- filtrace DNS}

Graf \ref{chart:nf10gdns} shrnuje výsledek filtrace DNS, který je vyjádřen tabulkou \ref{tab:nf10gdns}. Výsledek je ve srovnání s~netfilterem a \texttt{iptables} o~poznání horší.

\renewcommand\http{1.6864262} %1835:\FPeval{http}{(9933/588997)*100}
\renewcommand\dns{100} %1836:\FPeval{dns}{(33089/33089)*100}
\renewcommand\icmp{0.076565404} %1837:\FPeval{icmp}{(192/250766)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: nftables -- filtrace DNS.}
	\label{chart:nf10gdns}
\end{chart}


\subsubsection{Testování -- filtrace ICMP}

V tomto případě (viz tabulka \ref{tab:nf10gicmp} a graf \ref{chart:nf10gicmp}) došlo opět k~mírnému zlepšení oproti netfilteru a \texttt{iptables} -- provedlo se více transakcí a bylo méně neúspěšných transakcí.

\renewcommand\http{1.3955601} %1860:\FPeval{http}{(7772/556909)*100}
\renewcommand\dns{0.014669656} %1861:\FPeval{dns}{(53/361290)*100}
\renewcommand\icmp{100} %1862:\FPeval{icmp}{(28120/28120)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: nftables -- filtrace ICMP.}
	\label{chart:nf10gicmp}
\end{chart}



\subsubsection{Testování -- filtrace rozsahu IP adres}

\noindent
Výsledek v~tabulce \ref{tab:nf10gsubnet} a grafu \ref{chart:nf10gsubnet} dokazuje, že filtrování rozsahu IP adres v~nftables je výkonnější než v~případě netfilteru + \texttt{iptables}. HTTP a DNS provoz z~povoleného rozsahu dokonce nebyl ovlivněn vůbec.

\renewcommand\http{0} %1887:\FPeval{http}{((0+0)/(404048+102646))*100}
\renewcommand\dns{100} %1888:\FPeval{dns}{((2175+589)/(2175+589))*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph,
			symbolic x coords={rozsah1, rozsah2},
			xtick=data,
			height=5cm,
			width=6.5cm,
			ymin=0,
			ymax=100,
			ylabel=\%,
			nodes near coords,
			nodes near coords align={vertical},
			x tick label style={align=center,text width=2.5cm}
		]
			\addplot[ybar,fill=black] coordinates {
				(rozsah1,  \http)
				(rozsah2,   \dns)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: nftables -- filtrace rozsahu IP adres.}
	\label{chart:nf10gsubnet}
\end{chart}


\subsection{PF\_RING}
\label{test10g:pf}

\subsubsection{Testování -- bez filtrace}

Nejdříve bylo provedeno měření (viz tabulka \ref{tab:pf10gwo} a graf \ref{chart:pf10gwo}) bez použití filtrovacího argumentu.

\renewcommand\http{2.0063745} %1926:\FPeval{http}{(7938/395639)*100}
\renewcommand\dns{0.084828473} %1927:\FPeval{dns}{(93/109633)*100}
\renewcommand\icmp{1.0561481} %1928:\FPeval{icmp}{(1116/105667)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: PF\_RING -- bez filtrace.}
	\label{chart:pf10gwo}
\end{chart}

Srovnáme-li výsledek s~předchozími nástroji, zjistíme, že PF\_RING je na tom lépe než netfilter + \texttt{iptables}. Ačkoliv se provedlo o~něco méně transakcí, počet neúspěšných transakcí je zhruba 4krát menší.
Ve srovnání s~nftables je však PF\_RING daleko horší. Datová propustnost při měření se průměrně pohybovala okolo 4~Gbit/s.



\subsubsection{Testování -- filtrace HTTP}

Výsledek filtrace HTTP shrnuje tabulka \ref{tab:pf10ghttp} a z~ní vycházející graf \ref{chart:pf10ghttp}.

\renewcommand\http{100} %1955:\FPeval{http}{(238843/238843)*100}
\renewcommand\dns{0.014288887} %1956:\FPeval{dns}{(267/1868585)*100}
\renewcommand\icmp{0.014824408} %1957:\FPeval{icmp}{(277/1868540)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: PF\_RING -- filtrace HTTP.}
	\label{chart:pf10ghttp}
\end{chart}


Filtrace HTTP proběhla úspěšně a výsledky všech třech zatím vyzkoušených nástrojů jsou v~zásadě srovnatelné.


\subsubsection{Testování -- filtrace DNS}

Filtrace DNS v~podání PF\_RINGu nedopadla příliš dobře (viz graf \ref{chart:pf10gdns} a tabulku \ref{tab:pf10gdns}).

\renewcommand\http{6.1237905} %1983:\FPeval{http}{(24221/395523)*100}
\renewcommand\dns{100} %1984:\FPeval{dns}{(53745/53745)*100}
\renewcommand\icmp{3.6807792} %1985:\FPeval{icmp}{(5245/142497)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: PF\_RING -- filtrace DNS.}
	\label{chart:pf10gdns}
\end{chart}

Zcela jistě nejhorší výsledek filtrace DNS z~doposud vyzkoušených filtračních nástrojů. Šestiprocentní ztráta HTTP provozu, kdežto ostatní nástroje dosáhly maximálně 1,7\% ztráty.


\subsubsection{Testování -- filtrace ICMP}

Výsledek měření filtrace ICMP ukazuje tabulka \ref{tab:pf10gicmp}, a tu shrnuje graf \ref{chart:pf10gicmp}.

\renewcommand\http{2.8433662} %2010:\FPeval{http}{(10862/382012)*100}
\renewcommand\dns{0.048832333} %2011:\FPeval{dns}{(85/174065)*100}
\renewcommand\icmp{100} %2012:\FPeval{icmp}{(26416/26416)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: PF\_RING -- filtrace ICMP.}
	\label{chart:pf10gicmp}
\end{chart}

Porovnáme-li opět výsledky předchozích nástrojů, zjistíme, že si PF\_RING stojí lépe než netfilter + \texttt{iptables} (asi 3\% ztrátovost
HTTP provozu oproti 7 \%). Ovšem nftables je v~tomto případě efektivnější (jen asi 1,4\% ztrátovost).

\subsubsection{Testování -- filtrace rozsahu IP adres}

Výsledek posledního testu pro PF\_RING je v~tabulce \ref{tab:pf10gsubnet} a shrnuje jej graf \ref{chart:pf10gsubnet}.

\renewcommand\http{0.31229935} %2037:\FPeval{http}{((1420+10)/(401056+56838))*100}
\renewcommand\dns{100} %2038:\FPeval{dns}{((11402+5430)/(11402+5430))*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph,
			symbolic x coords={rozsah1, rozsah2},
			xtick=data,
			height=5cm,
			width=6.5cm,
			ymin=0,
			ymax=100,
			ylabel=\%,
			nodes near coords,
			nodes near coords align={vertical},
			x tick label style={align=center,text width=2.5cm}
		]
			\addplot[ybar,fill=black] coordinates {
				(rozsah1,  \http)
				(rozsah2,   \dns)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: PF\_RING -- filtrace rozsahu IP adres.}
	\label{chart:pf10gsubnet}
\end{chart}

Pouhým srovnáním čísel zjistíme, že při testování netfilteru + \texttt{iptables} bylo vyzkoušeno zhruba stejně HTTP transakcí z~povoleného rozsahu,
avšak cca 9 400 zahození oproti cca 1~400 zahození PF\_RINGu je už značný rozdíl. Ovšem nftables byly při tomto testu nejlepší.


\subsection{netmap}
\label{test10g:nm}

\subsubsection{Testování -- bez filtrace}

I v~tomto případě provedeme nejdříve test bez filtrace (viz tabulku \ref{tab:nm10gwo}).

\renewcommand\http{11.260088} %2079:\FPeval{http}{(42427/376791)*100}
\renewcommand\dns{2.6457332} %2080:\FPeval{dns}{(2125/80318)*100}
\renewcommand\icmp{3.7175179} %2081:\FPeval{icmp}{(3020/81237)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netmap -- bez filtrace.}
	\label{chart:nm10gwo}
\end{chart}

Je zvláštní, že nástroj přímo určený k~vysokorychlostní filtraci, dopadne nejhůře z~doposud testovaných nástrojů (viz graf \ref{chart:nm10gwo}).
Celkové zahození 8,8 \% transakcí je zcela největší číslo z~provedených testů v~této fázi testování (samozřejmě bereme v~potaz jen stejný test u~ostatních nástrojů).
Průměrná rychlost přenosu dat se pohybovala okolo 3,6~Gbit/s.

\subsubsection{Testování -- filtrace HTTP}

Výsledek měření při filtraci HTTP zobrazuje tabulka \ref{tab:nm10ghttp}.

\renewcommand\http{100} %2107:\FPeval{http}{(238859/238859)*100}
\renewcommand\dns{0.024983337} %2108:\FPeval{dns}{(280/1120747)*100}
\renewcommand\icmp{0.02459998} %2109:\FPeval{icmp}{(273/1109757)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netmap -- filtrace HTTP.}
	\label{chart:nm10ghttp}
\end{chart}


V porovnání s~ostatními nástroji, se při tomto testu vyzkoušelo méně transakcí, ačkoliv počty zahození povolených protokolů jsou stejné.
V relativních jednotkách se ale jedná o~setiny procent a méně (viz graf \ref{chart:nm10ghttp}).

\subsubsection{Testování -- filtrace DNS}

Tabulka \ref{tab:nm10gdns} shrnuje výsledek filtrace DNS pomocí netmapu. Grafické znázornění tabulky je v~grafu \ref{chart:nm10gdns}.

\renewcommand\http{31.562539} %2135:\FPeval{http}{(93647/296703)*100}
\renewcommand\dns{100} %2136:\FPeval{dns}{(140317/140317)*100}
\renewcommand\icmp{19.51228} %2137:\FPeval{icmp}{(28069/143853)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netmap -- filtrace DNS.}
	\label{chart:nm10gdns}
\end{chart}

Filtrace DNS je opět nejhorší výsledek z~výběru firewallů -- ztrátovost HTTP dosáhla k~necelým 32 \%!

\subsubsection{Testování -- filtrace ICMP}

Tabulka \ref{tab:nm10gicmp} shrnuje výsledek tohoto měření.

\renewcommand\http{25.599472} %2161:\FPeval{http}{(66265/258853)*100}
\renewcommand\dns{5.8642346} %2162:\FPeval{dns}{(10262/174993)*100}
\renewcommand\icmp{100} %2163:\FPeval{icmp}{(187194/187194)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netmap -- filtrace ICMP.}
	\label{chart:nm10gicmp}
\end{chart}

Opět ne moc dobrý výsledek: $1 \over 4$ HTTP provozu byla zahozena (viz graf \ref{chart:nm10gicmp}). U~ostatních nástrojů je maximum 7 \% zahozeného HTTP provozu.


\subsubsection{Testování -- filtrace rozsahu IP adres}

\noindent
Výsledek posledního testu v~tabulce \ref{tab:nm10gsubnet} a grafu \ref{chart:nm10gsubnet} opět podtrhuje velice slabý výkon netmapu.

\renewcommand\http{3.5453983} %2189:\FPeval{http}{((15434+25)/(351854+84176))*100}
\renewcommand\dns{100} %2190:\FPeval{dns}{((31912+18908)/(31912+18908))*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph,
			symbolic x coords={rozsah1, rozsah2},
			xtick=data,
			height=5cm,
			width=6.5cm,
			ymin=0,
			ymax=100,
			ylabel=\%,
			nodes near coords,
			nodes near coords align={vertical},
			x tick label style={align=center,text width=2.5cm}
		]
			\addplot[ybar,fill=black] coordinates {
				(rozsah1,  \http)
				(rozsah2,   \dns)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netmap -- filtrace rozsahu IP adres.}
	\label{chart:nm10gsubnet}
\end{chart}



Dosažená ztrátovost provozu z~povoleného rozsahu dosahuje cca 3,55 procent. I~u~net\-fil\-teru s~\texttt{iptables} to bylo jen asi 1,87 \%.

Ačkoliv výsledky netmapu nejsou příliš dobré, je zde možnost je vylepšit použitím upravených ovladačů síťových karet speciálně pro spolupráci s~netmapem.
Tyto ovladače jsou distribuovány v~rámci zdrojových kódů netmapu a jsou dostupné především pro síťové karty Intel. V~první fázi testování nebylo nutné
použít upravené ovladače, jelikož výkon standardních ovladačů byl dostatečný pro dané použití. Nyní se však tato možnost nabízí.


\subsection{netmap s vlastními ovladači NIC}
\label{test10g:nmspec}

\subsubsection{Instalace a nastavení}

Upravené ovladače by se měly zkompilovat zároveň s~netmapem, tudíž by již měly být připraveny z~první fáze testování.
Nalézt je můžeme v~adresáři \texttt{netmap/LINUX/[název ovladače]}. V~našem případě je to adresář \texttt{netmap/LINUX/ixgbe},
jelikož \texttt{ixgbe} je název ovladače. Ovladač není nic jiného než jaderný modul, který je potřeba nahrát do jádra. Nejdříve
je však nutné vyjmout z~jádra modul se standardním jaderným ovladačem:

\begin{listing}{1}
# rmmod ixgbe
\end{listing}

Následně je možné vložit do jádra upravený ovladač. Je třeba upozornit, že je nutné mít již načtený jaderný modul netmapu. Jelikož však byl upravený ovladač novější a s~novými funkcemi než standardní ovladač,
bylo v~tomto případě potřeba nejdříve načíst ještě jeden modul \uv{vxlan} (pro nás zcela nesouvisející):

\begin{listing}{1}
# modprobe vxlan
# cd netmap/LINUX/ixgbe
# insmod ixgbe.ko
\end{listing}

Tím by měla být instalace upravených ovladačů dokončena. Správnost lze zkontrolovat následujícím příkazem, který by měl vrátit podobný výpis:

\begin{listing}{1}
# lsmod | grep netmap
netmap                126169  1 ixgbe
\end{listing}

Důležitý je řádek 2, který říká, že modul \texttt{netmap} o~velikosti 126 169 bajtů v~paměti je používaný jedním modulem \texttt{ixgbe}.

\subsubsection{Testování -- bez filtrace}

Jako obvykle provedeme nejdříve měření bez filtračních pravidel. Výsledek znázorňuje graf \ref{chart:nm10gwospec} a tabulka \ref{tab:nm10gwospec}.

\renewcommand\http{0} %2265:\FPeval{http}{(0/819744)*100}
\renewcommand\dns{0} %2266:\FPeval{dns}{(0/87212)*100}
\renewcommand\icmp{0} %2267:\FPeval{icmp}{(0/85177)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netmap (vlastní ovladač) -- bez filtrace.}
	\label{chart:nm10gwospec}
\end{chart}

Porovnáme-li hodnoty s~netmapem bez speciálních ovladačů, zjistíme, že došlo k~velkému zvýšení výkonu. Dokonce nedošlo k~jediné neúspěšné transakci!
Celkový počet transakcí je jen o~několik málo tisíc menší než referenční měření. I~průměrná datová propustnost je srovnatelná: $\sim$8,3 Gbit/s!

\subsubsection{Testování -- filtrace HTTP}

Výsledek tohoto měření zobrazuje graf \ref{chart:nm10ghttpspec} zároveň s~tabulkou \ref{tab:nm10ghttpspec}. Hodnoty tohoto testu jsou srovnatelné u~všech testovaných nástrojů.

\renewcommand\http{100} %2292:\FPeval{http}{(238848/238848)*100}
\renewcommand\dns{0.013670912} %2293:\FPeval{dns}{(271/1982311)*100}
\renewcommand\icmp{0.013764256} %2294:\FPeval{icmp}{(272/1976133)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netmap (vlastní ovladač) -- filtrace HTTP.}
	\label{chart:nm10ghttpspec}
\end{chart}


\subsubsection{Testování -- filtrace DNS}

Tabulka \ref{tab:nm10gdnsspec} shrnuje výsledek filtrace DNS pomocí netmapu s~upraveným ovladačem a graf \ref{chart:nm10gdnsspec} dokazuje, že filtrace DNS pomocí této kombinace nástrojů je jednoznačně nejvýkonnější,
jelikož zde nedošlo k~žádnému nechtěnému zahození. U~všech ostatních nástrojů k~nějakému minimálnímu zahození došlo.

\renewcommand\http{0} %2318:\FPeval{http}{(0/837744)*100}
\renewcommand\dns{100} %2319:\FPeval{dns}{(5707/5707)*100}
\renewcommand\icmp{0} %2320:\FPeval{icmp}{(0/110729)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netmap (vlastní ovladač) -- filtrace DNS.}
	\label{chart:nm10gdnsspec}
\end{chart}

\subsubsection{Testování -- filtrace ICMP}

V tomto případě (viz tabulka \ref{tab:nm10gicmpspec}) byla filtrace opět provedena bez jakéhokoliv nechtěného zahození, jak dokazuje graf \ref{chart:nm10gicmpspec}.

\renewcommand\http{0} %2342:\FPeval{http}{(0/833157)*100}
\renewcommand\dns{0} %2343:\FPeval{dns}{(0/100748)*100}
\renewcommand\icmp{100} %2344:\FPeval{icmp}{(4803/4803)*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph]
			\addplot[ybar,fill=black] coordinates {
				(HTTP,  \http)
				(DNS,   \dns)
				(ICMP,  \icmp)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netmap (vlastní ovladač) -- filtrace ICMP.}
	\label{chart:nm10gicmpspec}
\end{chart}

\subsubsection{Testování -- filtrace rozsahu IP adres}

I poslední výsledek měření v~tabulce \ref{tab:nm10gsubnetspec} a grafu \ref{chart:nm10gsubnetspec} dokazuje, že netmap (respektive \texttt{netmap-ipfw}) ve spojení s~upraveným ovladačem síťové karty,
by mohl být ideální platformou pro vysokorychlostní filtraci dat na běžně dostupném hardwaru. Opět nedošlo k~žádnému (anebo minimálnímu) nechtěnému zahození provozu, který
pocházel z~povoleného rozsahu (lze důvodně předpokládat, že zahozený ICMP provoz pocházel ze zablokovaného rozsahu -- počet neúspěšných ICMP transakcí zhruba odpovídá počtu
neúspěšných DNS transakcí).

\renewcommand\http{0} %2369:\FPeval{http}{((0+0)/(351854+84176))*100}
\renewcommand\dns{100} %2370:\FPeval{dns}{((1095+484)/(1095+484))*100}

\begin{chart}[ht]
	\centering
	\begin{tikzpicture}
		\begin{axis}[bar width=23pt, ybar=5pt, firstBarGraph,
			symbolic x coords={rozsah1, rozsah2},
			xtick=data,
			height=5cm,
			width=6.5cm,
			ymin=0,
			ymax=100,
			ylabel=\%,
			nodes near coords,
			nodes near coords align={vertical},
			x tick label style={align=center,text width=2.5cm}
		]
			\addplot[ybar,fill=black] coordinates {
				(rozsah1,  \http)
				(rozsah2,   \dns)
			};
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Procentuální vyjádření neúspěšných transakcí: netmap (vlastní ovladač) -- filtrace rozsahu IP adres.}
	\label{chart:nm10gsubnetspec}
\end{chart}


\section{Vyhodnocení výsledků 1. a 2. fáze}

Výsledky měření v~první fázi testování byly v~drtivé většině případů srovnatelné a dle očekávání. Výjimkou byla pouze filtrace DNS, kdy si netfilter a \texttt{iptables} příliš neporadily s~ostatním provozem
a v~docela velké míře zahazovaly HTTP a ICMP transakce. Ve většině případů se také vyskytovala nechtěná zahození, ovšem ve velmi malé míře (setiny procenta). Při pozorování průběhu měření bylo zjištěno,
že tato zahození se vyskytovala ihned po spuštění testu. Je tedy možné, že budou tyto ztráty souviset s~výchozím režimem, ve kterém se ovladač síťové karty nachází. Jak již bylo popsáno v~sekci \ref{tradicni-pristup},
je zpočátku ovladač v~režimu, kdy posílá požadavky na přerušení. Až při určitém zatížení přechází do režimu pollingu. A~zřejmě právě v~době, než ovladač přejde z~režimu přerušení do režimu pollingu, může dojít k~určitým ztrátám,
jelikož byl test nastaven tak, aby generoval danou zátěž ihned po startu testu.

Druhá fáze měření byla již zajímavější. Z~logiky věci bylo jasné, že filtrace téměř 10Gbit/s provozu nebude tak snadná jako filtrace provozu do rychlosti 1 Gbit/s, a s~největší pravděpodobností bude docházet
k nevynuceným ztrátám. Což se záhy potvrdilo. Z~naměřených výsledků zcela nevyplývá, že by na tom jádro Linux společně s~netfilterem a \texttt{iptables} byly výkonnostně příliš špatně. V~některých testech dopadlo spojení
netfilter + \texttt{iptables} lépe než PF\_RING a prakticky ve všech testech bylo lepší než netmap s~jaderným ovladačem. Ten v~této konfiguraci propadl ve všech testech. Naproti tomu velice dobře dopadly nftables. Až
na filtraci DNS byly výsledky ze všech testovaných nástrojů se standardními linuxovými ovladači nejlepší. I~tak byla propustnost oproti referenčnímu měření o~téměř 2 Gbit/s nižší. Jako nejlepší se při testech
ukázal netmap ve spojení se speciálně upravenými ovladači. Drtivá většina testů byla úspěšná, tedy testy proběhly bez jediného nevynuceného zahození. Také bylo dosaženo datové propustnosti srovnatelné s~referenčním měřením.


\section{Testování v experimentální síti}
\label{testovanivexperimentalnisiti}

V rámci výzkumu a vývoje detekčních a filtračních schopností systémů pro ochranu před DDoS útoky, vzniklo na půdě Fakulty elektrotechniky a komunikačních technologií VUT experimentální pracoviště, skládající se
z uzavřené sítě, v~níž je možné testovat a simulovat různé druhy síťového provozu a kybernetických útoků. Jako generátor provozu slouží Spirent Avalanche 3100B, který byl již popsán v~sekci \ref{testovaci-prostredi}.
Dále jsou součástí sítě dva servery, které fungují jako cíle generovaného provozu. Hlavními prvky experimentální sítě jsou pak dva servery pro detekci útoků a osm filtračních serverů. Pro síťovou infrastrukturu
jsou využity hlavně přepínače firmy Mikrotik. Páteř sítě je propojena optickými propoji a funguje na rychlosti 10 Gbit/s, ovšem jednotlivé servery jsou připojeny k~1Gbit/s rozhraním. Součástí sítě jsou i~další zařízení
Mikrotik, které slouží pouze ke generování šumového provozu. Všechny důležité prvky sítě jsou pak připojeny do zvláštního síťového segmentu, který slouží ke správě zařízení a je možné skrz něj přistupovat do Internetu. Topologie
celého experimentálního pracoviště je zobrazena na obrázku \ref{fig:topologieexperimentalnisite}.

\begin{figure}[h]
	\centering
	\includegraphics[width=\textwidth,keepaspectratio=true]{topologie-experimentalni-site}
	\vspace{6mm}
	\caption{Topologie sítě experimentálního pracoviště. Plnou čarou jsou metalické propoje, čárkovanou čárou jsou optické propoje.}
	\label{fig:topologieexperimentalnisite}
\end{figure}

Aby bylo zaručeno, že určitý provoz bude procházet přes správný filtrovací server, je na přepínači, ke kterému jsou filtrační servery připojeny, nastaveno, aby na základě určité cílové IP adresy posílal provoz určitým
síťovým rozhraním. Toto nastavení je provedeno jen pro provoz ve směru Spirent Avalanche 3100B $\rightarrow$ cílové servery. V~opačném směru jsou rámce předávány přímo mezi přepínači bez účasti filtračních serverů.
Díky tomuto nastavení může v~síti pracovat paralelně více studentů bez toho, aby se výrazným způsobem vzájemně ovlivňovali.

\subsection{Testovací server -- HP ProLiant DL380}

Původní testovací server IBM System x3550 M2 z~první a druhé fáze nebyl do experimentální sítě zapojen, ale místo toho byl využit server HP ProLiant DL380 (všechny filtrovací servery byly tohoto typu). Server obsahuje
dva jednojádrové 64bitové procesory Intel Xeon pracující na frekvenci 3,40 GHz. K~dispozici má 8 GB operační paměti a pevné disky mají dohromady kapacitu 218 GB. Z~pohledu síťových možností připojení se na základní desce
serveru nacházejí dvě síťová rozhraní Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet. Jedno z~těchto rozhraní bylo využito pro připojení k~síti pro správu operačního systému, druhé zůstalo nevyužito. Dále byla do
počítačového systému vložena rozšiřující karta s~dalšími dvěma síťovými rozhraními. Tato rozhraní byla typu Intel Corporation 82546EB, a každé z~nich nabízí přenosovou rychlost až 1 Gbit/s. V~linuxovém jádře využívá ovladače \texttt{e1000}.
Obě rozhraní z~rozšiřující karty byla využita pro připojení k~experimentální síti. Operačním systémem na tomto serveru byl Debian Jessie s~jádrem Linux ve verzi 4.9.

Pro vyzkoušení filtrace na agregovaných linkách byla ze serveru původní Intel karta vyjmuta a nahrazena čtyřportovou verzí stejné značky i~typu. Agregovaly se tedy dvě a dvě 1Gbit/s linky (viz další text).

\subsection{Koordinace práce s experimentální sítí}

Jak již bylo uvedeno v~úvodu této sekce, s~experimentální infrastrukturou může paralelně pracovat více uživatelů. Jelikož jsou prostředky sdílené a jedná se o~čistě přepínanou síť, bylo každému uživateli přiděleno jedno
gigabitové rozhraní na generátoru Spirent Avalanche 3100B, dále dostal přidělený blok šesti zdrojových IP adres, ze kterých Avalanche odesílá provoz, a nakonec dvě cílové IP adresy, které byly nastaveny na cílových serverech
(na každém cílovém serveru jedna). Na základě těchto cílových adres byly na přepínači Mikrotik-IN (viz obrázek \ref{fig:topologieexperimentalnisite}) nastavena pravidla, podle kterých přepínal odchozí provoz přes jednotlivé
filtrační servery. Prostředky alokované pro vypracování této práce:

\begin{itemize}
	\item gigabitové rozhraní číslo 4 na Spirent Avalanche 3100B,
	\item zdrojové IP adresy: \texttt{192.168.2.174-192.168.2.179},
	\item cílové IP adresy: \texttt{192.168.2.143} a \texttt{192.168.2.153}.
\end{itemize}

\subsection{Organizace a způsob testování}
\label{organizaceazpusobtestovani}

Podobně jako při předchozím testování filtrovacích nástrojů v~malé, uzavřené a jednoúčelové síti, bylo i~testování v~síti experimentálního pracoviště rozděleno do dvou fází. V~první fázi probíhalo testování opět na rychlosti přenosu dat
do 1 Gbit/s. V~druhé fázi byla ve filtračním serveru vyměněna síťová karta za model s~více 1Gbit/s síťovými rozhraními a síť upravena tak, aby mohla být odzkoušena agregace síťových rozhraní. V~tomto případě byl tedy server
testován na rychlosti do 2 Gbit/s.

Testovací scénář první fáze byl na základě požadavků zadání práce zvolen takto: kaž\-dý nástroj byl podroben několika testům a každý test proběhl pro dvě různé přenosové rychlosti. Jelikož prochází přes filtrační server primárně jen provoz
z generátoru na cílové servery, musí být přenosová rychlost regulována pomocí požadavků, které generátor odesílá. Nižší testovací rychlost byla z~největší části tvořena nejmenšími možnými packety. Tabulka \ref{tab:rozlozenimalepackety} ukazuje
procentuální zastoupení délek packetů při nižší přenosové rychlosti. V~tomto nastavení bylo bez filtrace dosaženo datové propustnosti průměrně cca 176 Mbit/s a generátor posílal packety průměrnou rychlostí zhruba 335 000 packetů/s.

Akce prováděné generátorem při vytváření síťového provozu nižší přenosové rychlosti byly tyto:
\begin{itemize}
	\item \verb+get http://192.168.2.143/index2.html+\\
			\verb+get http://192.168.2.153/index2.html+ -- provede HTTP GET na oba cílové servery, který vyžaduje stažení prázdné webové stránky nacházející se na daném URL (požadavek i~odpověď tedy obsahují jen běžné hlavičky),
	\item \verb+DNS A 192.168.2.143 localhost+\\
			\verb+DNS A 192.168.2.153 localhost+ -- odeslání DNS dotazu na A záznam domény \uv{localhost} na cílové servery \texttt{192.168.2.143} a \texttt{192.168.2.153},
	\item 351$\times$ \verb+ICMP://192.168.2.143 ECHO LENGTH=18+\\
			351$\times$ \verb+ICMP://192.168.2.153 ECHO LENGTH=18+ -- odeslání ICMP Echo dotazu opět na oba cílové servery (délka 18 bajtů je délka jen datové části, se všemi hlavičkami vychází délka rámce na 64 bajtů).
\end{itemize}

\begin{table}[ht]
	\centering
	\begin{tabular}{|c|c|}
	\hline
	\textbf{Velikost packetu (bajty)} & \textbf{Procentuální zastoupení (\%)}\\
	\hline
	\hline
	0--64 & 98,74 \\
	\hline
	65--128 & 0,63 \\
	\hline
	257--512 & 0,63 \\
	\hline
	\end{tabular}
	\vspace{6mm}
	\caption{Rozložení velikostí packetů při nižší přenosové rychlosti (cca 176 Mbit/s).}
	\label{tab:rozlozenimalepackety}
\end{table}

Vyšší přenosová rychlost, při které byly nástroje testovány, byla naopak tvořena z~větší části packety, jejichž velikost přesahovala 1 024 bajtů. Zastoupení jednotlivých velikostí v~datovém toku lze najít v~tabulce \ref{tab:rozlozenivelkepackety}.
Při nastavení této datové propustnosti bylo bez filtrace dosaženo průměrně asi 775 Mbit/s odesílaných dat při průměrných cca 88 000 packetů za sekundu.

Akce, které generátor prováděl, byly následující:
\begin{itemize}
	\item \verb+post http://192.168.2.143/<POST_FILE="img0" CONTENT_TYPE="image/jpg">+\\
			\verb+post http://192.168.2.153/<POST_FILE="img0" CONTENT_TYPE="image/jpg">+ -- provede HTTP dotaz metodou POST na oba cílové servery, ve kterém odešle 1,4~kB velký soubor (\texttt{img0} je označení daného souboru v~softwaru pro ovládání generátoru),
	\item \verb+DNS A 192.168.2.143 localhost+\\
			\verb+DNS A 192.168.2.153 localhost+ -- stejný význam jako u~nižší přenosové rychlosti,
	\item 65$\times$ \verb+ICMP://192.168.2.143 ECHO LENGTH=1200+\\
			65$\times$ \verb+ICMP://192.168.2.153 ECHO LENGTH=1200+ -- odeslání ICMP Echo dotazu (s~délkou datové části 1~200~bajtů) na oba cílové servery.
\end{itemize}

\begin{table}[ht]
	\centering
	\begin{tabular}{|c|c|}
	\hline
	\textbf{Velikost packetu (bajty)} & \textbf{Procentuální zastoupení (\%)}\\
	\hline
	\hline
	0--64 & 10,46 \\
	\hline
	65--128 & 1,38 \\
	\hline
	129--256 & 1,32 \\
	\hline
	1 025--1 500 & 85,52 \\
	\hline
	1 500+ & 1,32 \\
	\hline
	\end{tabular}
	\vspace{6mm}
	\caption{Rozložení velikostí packetů při vyšší přenosové rychlosti (cca 775 Mbit/s).}
	\label{tab:rozlozenivelkepackety}
\end{table}

Na obrázku \ref{fig:avalancheloadsu} je možné zhlédnout společné nastavení zátěže a časového průběhu pro nižší rychlost. Pokud byla testována rychlost vyšší, tak se kromě samotných akcí měnila i~zátěž z~1\,060 na 580 simulovaných uživatelů za sekundu (SimUsers/second).
Jeden test trval celkově 67 sekund, ovšem plná zátěž byla generována jen 30 sekund.
Prvních 30 sekund nebyl generován žádný provoz, protože bylo zjištěno, že během této půl minuty dochází k~velkému počtu zahozených spojení. S~největší pravděpodobností je to způsobeno tím, že Spirent Avalanche 3100B zprovozní testovací port jen na dobu testování,
a pak jej zase vypne. Přepínač Cisco 4900, ke kterému byl generátor připojen, měl nastaveny porty tak, aby po aktivaci portu necelých 30 sekund vyčkával a přijímal a odesílal jen rámce spanning tree protokolu (protokol pro eliminaci smyček v~přepínané síti) a ostatní provoz zahazoval (lze tak
usoudit na základě zachycené komunikace). Zbylých 7 sekund je pak tzv. \uv{ramp down} fáze, která slouží k~uvolnění alokovaných prostředků pro spojení.

\begin{figure}[ht]
	\centering
	\includegraphics[keepaspectratio=true]{avalanche-load-su}
	\vspace{4mm}
	\caption{Nastavení zátěže a časového průběhu testu pro nižší rychlost.}
	\label{fig:avalancheloadsu}
\end{figure}

Nastavení filtračních nástrojů při jednotlivých testech bylo následující:
\begin{enumerate}
	\item bez filtrace,
	\item pravidlo pro filtraci na základě zdrojové IP adresy + pravidlo pro filtraci na základě cílové IP adresy,
	\item pravidlo pro filtraci na základě zdrojového portu transportní vrstvy + pravidlo pro filtraci na základě cílového portu transportní vrstvy,
	\item 100 nevýznamných pravidel pro filtrování zdrojové IP adresy (z jiného IP rozsahu) + pravidlo pro filtraci veškerých TCP komunikací + pravidlo pro filtraci veškerých UDP komunikací.
\end{enumerate}

U těch nástrojů, které to umožňují, by poslední test proběhl i~pro nastavení s~hlídáním stavu spojení, kdy by první pravidlo povolilo již dříve povolená spojení. Jako transportní protokol pro třetí test byl zvolen UDP, jelikož nepotřebuje sestavit spojení před přenosem
dat, což je v~této situaci výhodnější. Každé nastavení filtrace pak bylo vyzkoušeno při obou dříve zmíněných rychlostech.

Aby bylo možné sledovat správné nastavení filtrace a případné ovlivňování dalšího provozu, byl rozsah přidělených IP adres v~softwaru pro definování testů rozdělen na tři části:
\begin{itemize}
	\item \texttt{192.168.2.174} (dále označen jako rozsah1),
	\item \texttt{192.168.2.175} (dále označen jako rozsah2),
	\item \texttt{192.168.2.176-192.168.2.179} (dále označen jako rozsah3).
\end{itemize}

První dvě adresy byly použity ve filtračních pravidlech, zbylé čtyři adresy zůstaly povoleny a sloužily pro generování provozu procházejícího filtračním serverem. Díky tomuto rozdělení je možné ve výsledcích testů
odlišit jednotlivé provozy. Nakonec byl nastaven rozsah zdrojových portů, které mohl generátor použít pro transportní protokoly, na čísla 57 000 až 58 000. Tím je možné definovat přesný rozsah ve filtračních pravidlech.

\newcommand\toolname{lorem}
\newcommand\testname{lorem}

\newcommand\icmpunsucessfulpercent{lorem}
\newcommand\totaltrans{lorem}
\newcommand\totalsuccessfultrans{lorem}
\newcommand\totalunsuccessfultrans{lorem}
\newcommand\totalsucessfultranspercent{lorem}
\newcommand\totalunsucessfultranspercent{lorem}
\newcommand\mychartsname{lorem}
\newcommand\trafficmin{lorem}
\newcommand\trafficmax{lorem}
\newcommand\trafficavg{lorem}
\newcommand\packetsmin{lorem}
\newcommand\packetsmax{lorem}
\newcommand\packetsavg{lorem}

\renewcommand\mychartsname{Bitová a packetová rychlost v~závislosti na čase}

\subsection{netfilter + iptables}

\renewcommand\toolname{netfilter + \texttt{iptables}}

\subsubsection{Bez filtrace, nižší rychlost}
\renewcommand\testname{bez filtrace, nižší rychlost}

% TEST NAME:  iptables - small - no filtr
\renewcommand\icmpunsucessfulpercent{0 \%}

\renewcommand\totaltrans{10 715 202 transakcí}
\renewcommand\totalsuccessfultrans{10 715 202 transakcí}
\renewcommand\totalunsuccessfultrans{0 transakcí}
\renewcommand\totalsucessfultranspercent{100 \%}
\renewcommand\totalunsucessfultranspercent{0 \%}

\renewcommand\trafficmin{174,21 Mbit/s}
\renewcommand\trafficmax{177,59 Mbit/s}
\renewcommand\trafficavg{176,05 Mbit/s}
\renewcommand\packetsmin{331 417 packetů/s}
\renewcommand\packetsmax{338 405 packetů/s}
\renewcommand\packetsavg{335 385 packetů/s}

Jak bylo naznačeno v~předchozích odstavcích, první testy probíhaly bez filtrace. Na grafech \ref{chart:iptablessmallnofiltrsum} a \ref{chart:iptablessmallnofiltrreal} lze vidět, že test proběhl v~pořádku. Všech \totaltrans{} bylo úspěšných.

Průměrná rychlost odchozího provoz se držela kolem hodnoty \trafficavg{} a generátor vytvářel packety průměrnou rychlostí \packetsavg{}. Tyto a obdobné hodnoty jsou vypočteny z~časového úseku, kdy Spirent Avalanche 3100B generoval maximální zátěž (tedy od 30. do 60. sekundy). Stejným způsobem je to myšleno i~dále v~textu, ale již bez upozornění.




%===========================================

\subsubsection{Bez filtrace, vyšší rychlost}
\renewcommand\testname{bez filtrace, vyšší rychlost}

% TEST NAME:  iptables - big - no filtr
\renewcommand\icmpunsucessfulpercent{0 \%}

\renewcommand\totaltrans{2 583 184 transakcí}
\renewcommand\totalsuccessfultrans{2 583 184 transakcí}
\renewcommand\totalunsuccessfultrans{0 transakcí}
\renewcommand\totalsucessfultranspercent{100 \%}
\renewcommand\totalunsucessfultranspercent{0 \%}

\renewcommand\trafficmin{759,44 Mbit/s}
\renewcommand\trafficmax{810,98 Mbit/s}
\renewcommand\trafficavg{774,74 Mbit/s}
\renewcommand\packetsmin{87 574 packetů/s}
\renewcommand\packetsmax{91 980 packetů/s}
\renewcommand\packetsavg{88 370 packetů/s}

Podobně úspěšně jako test při nižší rychlosti dopadl i~tento test (viz grafy \ref{chart:iptablesbignofiltrsum} a \ref{chart:iptablesbignofiltrreal}). Z~celkových \totaltrans{} nebyla zahozena ani jedna transakce.
Průměrná přenosová rychlost činila \trafficavg{} a packetová rychlost \packetsavg{}.



%===========================================

\subsubsection{Filtrace IP adres, nižší rychlost}
\renewcommand\testname{filtrace IP adres, nižší rychlost}

Pro filtraci na základě zdrojové a cílové adresy byly provedeny tyto příkazy:

\begin{listing}{1}
# iptables -A FORWARD -m physdev --physdev-is-bridged \
    -s 192.168.2.174 -j DROP
# iptables -A FORWARD -m physdev --physdev-is-bridged \
    -s 192.168.2.175 -d 192.168.2.143 -j DROP
\end{listing}

První příkaz vytváří pravidlo pro zahození veškerého provozu se zdrojovou IP adresou \texttt{192.168.2.174}. Druhý příkaz zahazuje provoz mířící na \texttt{192.168.2.143}. Aby nebyl ovlivněn další provoz, bylo pravidlo doplněno tak,
aby filtrovalo jen provoz pocházející z~IP adresy \texttt{192.168.2.175} (aby mohl být tento provoz identifikován ve výstupu testu).

Z grafu \ref{chart:iptablessmallfiltripsum} vyplývá, že filtrace byla úspěšná -- rozsah1 byl vyfiltrován celý, z~rozsahu2 jen provoz na vybranou IP adresu a z~rozsahu3 téměř nic. K~určitým zahozením z~povolených komunikací došlo, ovšem nejedná se ani o jednotky procent.


% TEST NAME:  iptables - small - filtr ip
\renewcommand\icmpunsucessfulpercent{10,35 \%}

\renewcommand\totaltrans{3 925 696 transakcí}
\renewcommand\totalsuccessfultrans{3 466 821 transakcí}
\renewcommand\totalunsuccessfultrans{458 875 transakcí}
\renewcommand\totalsucessfultranspercent{88,31 \%}
\renewcommand\totalunsucessfultranspercent{11,69 \%}

\renewcommand\trafficmin{57,76 Mbit/s}
\renewcommand\trafficmax{62,19 Mbit/s}
\renewcommand\trafficavg{59,86 Mbit/s}
\renewcommand\packetsmin{110 000 packetů/s}
\renewcommand\packetsmax{117 066 packetů/s}
\renewcommand\packetsavg{112 537 packetů/s}

Graf \ref{chart:iptablessmallfiltripreal} ukazuje docela nízké hodnoty přenosové a packetové rychlosti. Je to z~toho důvodu, že Spirent Avalanche 3100B otevře určitý počet komunikací a další neotevírá, dokud nepřijde odpověď nebo nevyprší limitní časovače původních spojení. Při snížení časového limitu ovšem nedokázaly cílové servery tak rychle odpovídat. Z~toho důvodu bylo toto nastavení ponecháno na hodnotě, při které cílové servery dokázaly doručit odpověď v~daném limitu (zkoušeno při nastavení bez filtrace).

Packetová rychlost dosáhla maximálně \packetsmax{} (průměrně \packetsavg{}) a přenosová rychlost maximálně \trafficmax{} (průměrně \trafficavg{}).
Vyzkoušeno bylo \totaltrans{}.


%===========================================

\subsubsection{Filtrace IP adres, vyšší rychlost}
\renewcommand\testname{filtrace IP adres, vyšší rychlost}

Nastavení filtrace bylo provedeno stejně jako v~předešlém případě. Filtrace opět proběhla převážně správně -- opět došlo k menšímu počtu nechtěných zahození (viz graf \ref{chart:iptablesbigfiltripsum}).


% TEST NAME:  iptables - big - filtr ip
\renewcommand\icmpunsucessfulpercent{17,94 \%}

\renewcommand\totaltrans{1 223 483 transakcí}
\renewcommand\totalsuccessfultrans{980 204 transakcí}
\renewcommand\totalunsuccessfultrans{243 279 transakcí}
\renewcommand\totalsucessfultranspercent{80,12 \%}
\renewcommand\totalunsucessfultranspercent{19,88 \%}

\renewcommand\trafficmin{55,96 Mbit/s}
\renewcommand\trafficmax{454,49 Mbit/s}
\renewcommand\trafficavg{321,21 Mbit/s}
\renewcommand\packetsmin{7 105 packetů/s}
\renewcommand\packetsmax{52 537 packetů/s}
\renewcommand\packetsavg{40 187 packetů/s}

Graf \ref{chart:iptablesbigfiltripreal}, znázorňuje průběh testu z~pohledu datové propustnosti a rychlosti generovaných packetů. V~tomto případě dosáhla přenosová rychlost maximálně \trafficmax{}, ovšem průměrně to bylo jen \trafficavg{}. Podobně s~packetovou rychlostí -- maximum činilo \packetsmax{}, průměr pak \packetsavg{}.


%===========================================

\subsubsection{Filtrace UDP portů, nižší rychlost}
\renewcommand\testname{filtrace UDP portů, nižší rychlost}

Byly použity tyto filtrační příkazy:

\begin{listing}{1}
# iptables -A FORWARD -m physdev --physdev-is-bridged \
    -s 192.168.2.174 -p udp -m multiport --sports 57000:58000 -j DROP
# iptables -A FORWARD -m physdev --physdev-is-bridged \
    -s 192.168.2.175 -d 192.168.2.143 -p udp -m udp --dport 53 -j DROP
\end{listing}

% TEST NAME:  iptables - small - filtr udp
\renewcommand\icmpunsucessfulpercent{14,94 \%}

\renewcommand\totaltrans{4 053 272 transakcí}
\renewcommand\totalsuccessfultrans{3 423 831 transakcí}
\renewcommand\totalunsuccessfultrans{629 441 transakcí}
\renewcommand\totalsucessfultranspercent{84,47 \%}
\renewcommand\totalunsucessfultranspercent{15,53 \%}

\renewcommand\trafficmin{60,52 Mbit/s}
\renewcommand\trafficmax{71,76 Mbit/s}
\renewcommand\trafficavg{66,03~Mbit/s}
\renewcommand\packetsmin{109 190 packetů/s}
\renewcommand\packetsmax{130 840 packetů/s}
\renewcommand\packetsavg{119 810 packetů/s}

První příkaz využívá modulu \texttt{multiport} k~definování rozsahu zdrojových portů UDP. Druhý příkaz používá standardní modul \texttt{udp} k~filtraci jednoho cílového portu.
Graf \ref{chart:iptablessmallfiltrudpsum} dokazuje, že byly odfiltrovány správné komunikace, ovšem s docela masivní ztrátou HTTP komunikací (až 18 \% pro jednu komunikaci).
Bylo celkem vygenerováno \totaltrans{}.

Graf \ref{chart:iptablessmallfiltrudpreal} ukazuje, že oproti filtraci IP adres se mírně zvedla packetová rychlost (průměrně \packetsavg{}) a zvedla se i~přenosová rychlost -- na průměrných cca \trafficavg{}.


%===========================================

\subsubsection{Filtrace UDP portů, vyšší rychlost}
\renewcommand\testname{filtrace UDP portů, vyšší rychlost}


% TEST NAME:  iptables - big - filtr udp
\renewcommand\icmpunsucessfulpercent{1,62 \%}

\renewcommand\totaltrans{2 503 070 transakcí}
\renewcommand\totalsuccessfultrans{2 433 995 transakcí}
\renewcommand\totalunsuccessfultrans{69 075 transakcí}
\renewcommand\totalsucessfultranspercent{97,24 \%}
\renewcommand\totalunsucessfultranspercent{2,76 \%}

\renewcommand\trafficmin{2,99 Mbit/s}
\renewcommand\trafficmax{740,06 Mbit/s}
\renewcommand\trafficavg{645,77 Mbit/s}
\renewcommand\packetsmin{1 943 packetů/s}
\renewcommand\packetsmax{87 628 packetů/s}
\renewcommand\packetsavg{74~266 packetů/s}

Nastavení filtračních pravidel opět zůstalo (což zobrazuje graf \ref{chart:iptablesbigfiltrudpsum}), jen se změnila zátěž (což dokazuje graf \ref{chart:iptablesbigfiltrudpreal}).

Při tomto testu bylo provedeno celkem \totaltrans{}. Přenosová rychlost se držela průměrně kolem \trafficavg{}, rychlost odchozích packetů průměrně kolem \packetsavg{}.




%===========================================

\subsubsection{Filtrace TCP/UDP, nižší rychlost, bezstavová}
\renewcommand\testname{filtrace TCP/UDP, nižší rychlost, bezstavová}
\label{testaaa}

% TEST NAME:  iptables - small - filtr tcp/udp
\renewcommand\icmpunsucessfulpercent{17,31 \%}

\renewcommand\totaltrans{3~342~122 transakcí}
\renewcommand\totalsuccessfultrans{2 747 274 transakcí}
\renewcommand\totalunsuccessfultrans{594 848 transakcí}
\renewcommand\totalsucessfultranspercent{82,20 \%}
\renewcommand\totalunsucessfultranspercent{17,80 \%}

\renewcommand\trafficmin{46,63 Mbit/s}
\renewcommand\trafficmax{59,16 Mbit/s}
\renewcommand\trafficavg{52,02 Mbit/s}
\renewcommand\packetsmin{86 610 packetů/s}
\renewcommand\packetsmax{109 651 packetů/s}
\renewcommand\packetsavg{95 837 packetů/s}

Nastavení filtrovacích pravidel proběhlo pomocí následujících příkazů:

\begin{listing}{1}
# for I in {1..100}; do
#	iptables -A FORWARD -m physdev --physdev-is-bridged \
	  -s 192.168.3.$I -j DROP
# done
# iptables -A FORWARD -m physdev --physdev-is-bridged -s 192.168.2.174\
    -d 192.168.2.143 -p tcp -j DROP
# iptables -A FORWARD -m physdev --physdev-is-bridged -s 192.168.2.175\
    -d 192.168.2.153 -p udp -j DROP
\end{listing}

Počáteční cyklus \texttt{for} slouží k~vygenerování 100 bezvýznamných filtrovacích pravidel, které slouží jen k~většímu zaplnění filtrovací tabulky, a tudíž ke snížení efektivity filtrace (kvůli otestování a porovnání stavové filtrace, která bude následovat).
Další příkazy přidávají pravidla pro filtraci TCP a UDP. Nevyužívají se žádné speciální moduly, jen volba \texttt{-p}, která používá informace z~IP hlavičky.

Graf \ref{chart:iptablessmallfiltrtcpudpsum} ukazuje, že provoz byl správně odfiltrován (avšak částečně i s něčím navíc). Závislost packetové a datové rychlosti na čase je v~grafu \ref{chart:iptablessmallfiltrtcpudpreal}. Celkem bylo vyzkoušeno \totaltrans{}.
Průměrná přenosová rychlost byla \trafficavg{}, průměrná packetová rychlost \packetsavg{}. Neúspěšné transakce dosáhly k \totalunsucessfultranspercent{}.

%===========================================


\subsubsection{Filtrace TCP/UDP, vyšší rychlost, bezstavová}
\renewcommand\testname{filtrace TCP/UDP, vyšší rychlost, bezstavová}

% TEST NAME:  iptables - big - filtr tcp/udp
\renewcommand\icmpunsucessfulpercent{8,10 \%}

\renewcommand\totaltrans{2 197 419 transakcí}
\renewcommand\totalsuccessfultrans{2 010 784 transakcí}
\renewcommand\totalunsuccessfultrans{186 635 transakcí}
\renewcommand\totalsucessfultranspercent{91,51 \%}
\renewcommand\totalunsucessfultranspercent{8,49~\%}

\renewcommand\trafficmin{338,00 kbit/s}
\renewcommand\trafficmax{632,87 Mbit/s}
\renewcommand\trafficavg{558,03 Mbit/s}
\renewcommand\packetsmin{661 packetů/s}
\renewcommand\packetsmax{73 077 packetů/s}
\renewcommand\packetsavg{65~168 packetů/s}


Stejně jako v~předchozích měřeních nastavení filtrace zůstalo, jen se změnila rychlost generovaných dat. V~tomto případě se provedlo celkem \totaltrans{}, přenosová rychlost byla vyšší -- průměrně \trafficavg{} a packetová rychlost nižší -- průměrně \packetsavg{} (viz také grafy \ref{chart:iptablesbigfiltrtcpudpsum} a \ref{chart:iptablesbigfiltrtcpudpreal}).
Z celkového počtu transakcí bylo provedeno \totalunsucessfultranspercent{} neúspěšných transakcí.


%===========================================

\subsubsection{Filtrace TCP/UDP, nižší rychlost, stavová}
\renewcommand\testname{filtrace TCP/UDP, nižší rychlost, stavová}


% TEST NAME:  iptables - small - filtr tcp/udp - conntrack
\renewcommand\icmpunsucessfulpercent{17,48 \%}

\renewcommand\totaltrans{3 604 203 transakcí}
\renewcommand\totalsuccessfultrans{2 970 253 transakcí}
\renewcommand\totalunsuccessfultrans{633 950 transakcí}
\renewcommand\totalsucessfultranspercent{82,41 \%}
\renewcommand\totalunsucessfultranspercent{17,59 \%}

\renewcommand\trafficmin{618,00 kbit/s}
\renewcommand\trafficmax{68,27 Mbit/s}
\renewcommand\trafficavg{56,47 Mbit/s}
\renewcommand\packetsmin{1 159 packetů/s}
\renewcommand\packetsmax{125 361 packetů/s}
\renewcommand\packetsavg{102 839 packetů/s}


Aby mohla být vůbec filtrace s~hlídáním stavu vyzkoušena, muselo být nejdříve zajištěno to, aby filtračním serverem procházel veškerý provoz (tedy i~odpovědi od cílových serverů ke generátoru provozu). Tento požadavek vyplývá z~logiky stavové filtrace -- aby si mohl firewall zaznamenávat stav dané komunikace, musí jím procházet oba směry.

Přepínač Mikrotik-OUT z~obrázku \ref{fig:topologieexperimentalnisite} naštěstí umožňoval vložit pravidla, kterými lze provoz přesměrovávat mezi porty. Stačilo tedy přidat pravidla, aby vše, co přichází z~IP adres \texttt{192.168.2.143} a \texttt{192.168.2.153}, posílal portem na filtrační server místo optického propoje na Mikrotik-IN.

Při zkoušení stavové filtrace byl proveden tento příkaz:
\begin{listing}{1}
# iptables -A FORWARD -m physdev --physdev-is-bridged -m state \
    --state ESTABLISHED,RELATED -j ACCEPT
\end{listing}

Za ním následovaly stejné \texttt{iptables} příkazy, jako při testování bezstavové filtrace, jen doplněné o~parametry: \verb+-m state --state NEW+.

Graf \ref{chart:iptablessmallfiltrtcpudpconntracksum} zobrazuje, že došlo k víceméně správnému zahození provozu. Na grafu \ref{chart:iptablessmallfiltrtcpudpconntrackreal} to sice není příliš vidět, ale došlo i k mírnému zlepšení oproti bezstavovému testu.
Čísla to dokazují: bylo uskutečněno \totaltrans{} při průměrné přenosové rychlosti \trafficavg{} a průměrné packetové rychlosti \packetsavg{}. Tedy došlo k více transakcím a ubylo transakcí neúspěšných, kterých bylo \totalunsucessfultranspercent{}.

%===========================================

\subsubsection{Filtrace TCP/UDP, vyšší rychlost, stavová}
\renewcommand\testname{filtrace TCP/UDP, vyšší rychlost, stavová}


% TEST NAME:  iptables - big - filtr tcp/udp - conntrack
\renewcommand\icmpunsucessfulpercent{3,22 \%}

\renewcommand\totaltrans{2 471 982 transakcí}
\renewcommand\totalsuccessfultrans{2 381 405 transakcí}
\renewcommand\totalunsuccessfultrans{90 577 transakcí}
\renewcommand\totalsucessfultranspercent{96,34 \%}
\renewcommand\totalunsucessfultranspercent{3,66 \%}

\renewcommand\trafficmin{432,58 Mbit/s}
\renewcommand\trafficmax{680,45 Mbit/s}
\renewcommand\trafficavg{641,74 Mbit/s}
\renewcommand\packetsmin{51 074 packetů/s}
\renewcommand\packetsmax{76 941 packetů/s}
\renewcommand\packetsavg{73 541 packetů/s}


Stavová filtrace při vyšší přenosové rychlosti je prakticky ten samý případ jako předchozí: stavová filtrace dosáhla o něco málo lepších výsledků než filtrace bezstavová, ovšem grafy \ref{chart:iptablesbigfiltrtcpudpconntracksum} a \ref{chart:iptablesbigfiltrtcpudpconntrackreal} to příliš nedokazují.
Celkem proběhlo \totaltrans{}, z toho neúspěšných bylo \totalunsucessfultranspercent{}. Průměrná přenosová rychlost byla \trafficavg{}, průměrná packetová rychlost byla \packetsavg{}.

Pro další důkaz, že se hlídání stavu aplikovalo, je možné nahlédnout do výpisu pravidel \texttt{iptables}. Čítače dokazují, že dané stavové pravidlo bylo opravdu použito (výpis byl zkrácen):

\begin{listing}{1}
Chain FORWARD (policy ACCEPT 587K packets, 288M bytes)
 pkts bytes target     prot opt   source         destination
2204K  800M ACCEPT     all  --    0.0.0.0/0      0.0.0.0/0    \
                                              state RELATED,ESTABLISHED
    0     0 DROP       all  --    192.168.3.1    0.0.0.0/0
...
    0     0 DROP       all  --    192.168.3.100  0.0.0.0/0
 4056  178K DROP       tcp  --    192.168.2.174  192.168.2.143
 6085  335K DROP       udp  --    192.168.2.175  192.168.2.153
\end{listing}

Z uvedeného výpisu je vidět, že první pravidlo (na řádku číslo 3 a 4) akceptující již jednou povolená spojení, bylo aplikováno na 2,204 milionů packetů.
Lze tedy prohlásit, že transparentní stavová filtrace v netfilteru a \texttt{iptables} skutečně funguje.

%===========================================




\subsection{nftables}

\renewcommand\toolname{nftables}

\subsubsection{Bez filtrace, nižší rychlost}
\renewcommand\testname{bez filtrace, nižší rychlost}

% TEST NAME:  nftables - small - no filtr
\renewcommand\icmpunsucessfulpercent{0 \%}

\renewcommand\totaltrans{10 715 202 transakcí}
\renewcommand\totalsuccessfultrans{10 715 191 transakcí}
\renewcommand\totalunsuccessfultrans{11 transakcí}
\renewcommand\totalsucessfultranspercent{100 \%}
\renewcommand\totalunsucessfultranspercent{0 \%}

\renewcommand\trafficmin{174,41 Mbit/s}
\renewcommand\trafficmax{177,13 Mbit/s}
\renewcommand\trafficavg{176,03 Mbit/s}
\renewcommand\packetsmin{331 815 packetů/s}
\renewcommand\packetsmax{337 506 packetů/s}
\renewcommand\packetsavg{335 344 packetů/s}


I v~tomto případě byl proveden nejdříve test bez filtrace. Grafy \ref{chart:nftablessmallnofiltrsum} a \ref{chart:nftablessmallnofiltrreal} ukazují podobné hodnoty jako netfilter a \texttt{iptables}
(i když došlo k mírným ztrátám).
Průměrná rychlost dat ukazovala \trafficavg{}, průměrná rychlost odesílání packetů byla \packetsavg{}. Vyzkoušelo se celkem \totaltrans{}.


%===========================================

\subsubsection{Bez filtrace, vyšší rychlost}
\renewcommand\testname{bez filtrace, vyšší rychlost}

% TEST NAME:  nftables - big - no filtr
\renewcommand\icmpunsucessfulpercent{0 \%}

\renewcommand\totaltrans{2 583 184 transakcí}
\renewcommand\totalsuccessfultrans{2 583 184 transakcí}
\renewcommand\totalunsuccessfultrans{0 transakcí}
\renewcommand\totalsucessfultranspercent{100 \%}
\renewcommand\totalunsucessfultranspercent{0 \%}

\renewcommand\trafficmin{771,64 Mbit/s}
\renewcommand\trafficmax{800,01 Mbit/s}
\renewcommand\trafficavg{774,78 Mbit/s}
\renewcommand\packetsmin{88 139 packetů/s}
\renewcommand\packetsmax{90 883 packetů/s}
\renewcommand\packetsavg{88 371 packetů/s}


Grafy \ref{chart:nftablesbignofiltrsum} a \ref{chart:nftablesbignofiltrreal} se opět oproti netfilteru s~\texttt{iptables} příliš nezměnily. A~samotná čísla také ne: celkem \totaltrans{}, přenosová rychlost průměrně \trafficavg{}, packetová rychlost v průměru \packetsavg{}.



%===========================================
\subsubsection{Filtrace IP adres, nižší rychlost}
\renewcommand\testname{filtrace IP adres, nižší rychlost}


% TEST NAME:  nftables - small - filtr ip
\renewcommand\icmpunsucessfulpercent{8,79 \%}

\renewcommand\totaltrans{4 203 499 transakcí}
\renewcommand\totalsuccessfultrans{3 779 421 transakcí}
\renewcommand\totalunsuccessfultrans{424 078 transakcí}
\renewcommand\totalsucessfultranspercent{89,91 \%}
\renewcommand\totalunsucessfultranspercent{10,09 \%}

\renewcommand\trafficmin{58,79 Mbit/s}
\renewcommand\trafficmax{76,07 Mbit/s}
\renewcommand\trafficavg{68,57 Mbit/s}
\renewcommand\packetsmin{112 020 packetů/s}
\renewcommand\packetsmax{144 170 packetů/s}
\renewcommand\packetsavg{129 562 packetů/s}


Tento test byl proveden při konfiguraci filtrace pomocí příkazů:

\begin{listing}{1}
# nft add rule bridge filter forward ether type ip \
    ip saddr 192.168.2.174 drop
# nft add rule bridge filter forward ether type ip \
    ip saddr 192.168.2.175 ip daddr 192.168.2.143 drop
\end{listing}

První příkaz filtruje na základě zdrojové IP adresy (\verb+ip saddr+), druhý příkaz na základě zdrojové i~cílové IP adresy (\verb+ip daddr+).

Z grafu \ref{chart:nftablessmallfiltripsum} lze vyčíst, že filtrace proběhla správně. Graf \ref{chart:nftablessmallfiltripreal} ukazuje nízkou přenosovou rychlost i~packetovou rychlost,
ovšem vyšší než předchozí zkoušený nástroj.

Celkem proběhlo \totaltrans{} při průměrné datové propustnosti \trafficavg{} a rychlosti generování packetů \packetsavg{}. Všechna tato čísla jsou lepší, než čeho dosáhl netfilter.



%===========================================
\subsubsection{Filtrace IP adres, vyšší rychlost}
\renewcommand\testname{filtrace IP adres, vyšší rychlost}

% TEST NAME:  nftables - big - filtr ip
\renewcommand\icmpunsucessfulpercent{17,94 \%}

\renewcommand\totaltrans{1 223 915 transakcí}
\renewcommand\totalsuccessfultrans{980 557 transakcí}
\renewcommand\totalunsuccessfultrans{243 358 transakcí}
\renewcommand\totalsucessfultranspercent{80,12 \%}
\renewcommand\totalunsucessfultranspercent{19,88 \%}

\renewcommand\trafficmin{257,43 Mbit/s}
\renewcommand\trafficmax{403,00 Mbit/s}
\renewcommand\trafficavg{321,67 Mbit/s}
\renewcommand\packetsmin{30 098 packetů/s}
\renewcommand\packetsmax{49 024 packetů/s}
\renewcommand\packetsavg{40 252 packetů/s}


Nastavení zůstalo stejné, jako v~minulém případě. Jen se změnily statistické údaje a graf \ref{chart:nftablesbigfiltripreal}. Jelikož se filtrovalo to samé a k~žádnému většímu nechtěnému zahození (které by se výrazně projevilo) nedošlo, graf \ref{chart:nftablesbigfiltripsum} zůstal téměř nezměněn.

Při průměrné přenosové rychlosti \trafficavg{} a packetové rychlosti \packetsavg{} bylo provedeno \totaltrans{}. Tato čísla jsou srovnatelná s netfilterem.

%===========================================

\subsubsection{Filtrace UDP portů, nižší rychlost}
\renewcommand\testname{filtrace UDP portů, nižší rychlost}


% TEST NAME:  nftables - small - filtr udp
\renewcommand\icmpunsucessfulpercent{0 \%}

\renewcommand\totaltrans{10 714 896 transakcí}
\renewcommand\totalsuccessfultrans{10 679 880 transakcí}
\renewcommand\totalunsuccessfultrans{35 016 transakcí}
\renewcommand\totalsucessfultranspercent{99,67 \%}
\renewcommand\totalunsucessfultranspercent{0,33 \%}

\renewcommand\trafficmin{128,74 Mbit/s}
\renewcommand\trafficmax{177,45 Mbit/s}
\renewcommand\trafficavg{175,63 Mbit/s}
\renewcommand\packetsmin{242 403 packetů/s}
\renewcommand\packetsmax{337 828 packetů/s}
\renewcommand\packetsavg{334\,264\,packetů/s}


Pro filtrování UDP portů byly provedeny tyto příkazy:

\begin{listing}{1}
# nft add rule bridge filter forward ether type ip \
    ip saddr 192.168.2.174 udp sport 57000-58000 drop
# nft add rule bridge filter forward ether type ip \
    ip saddr 192.168.2.175 ip daddr 192.168.2.143 udp dport 53 drop
\end{listing}

První příkaz filtruje UDP provoz jen z~dané IP adresy a z~rozsahu zdrojových portů \verb+57000-58000+. Druhý příkaz filtruje pro vybranou dvojici IP adres (zdroj--cíl) jen cílový UDP port 53 (tedy standardně DNS provoz).

Při tomto testu bylo dosaženo průměrné rychlosti generování packetů \packetsavg{} a průměrné přenosové rychlosti \trafficavg{}. Proběhlo dohromady \totaltrans{}. Na rozdíl od netfilteru s \texttt{iptables},
nedošlo při tomto testu k žádnému nechtěnému zahození (viz graf \ref{chart:nftablessmallfiltrudpsum}) a bylo dosaženo vyšší přenosové i packetové rychlosti, což lze vidět v~grafu \ref{chart:nftablessmallfiltrudpreal}.


%===========================================

\subsubsection{Filtrace UDP portů, vyšší rychlost}
\renewcommand\testname{filtrace UDP portů, vyšší rychlost}

% TEST NAME:  nftables - big - filtr udp
\renewcommand\icmpunsucessfulpercent{0 \%}

\renewcommand\totaltrans{2 583 320}
\renewcommand\totalsuccessfultrans{2 564 324 transakcí}
\renewcommand\totalunsuccessfultrans{18 996 transakcí}
\renewcommand\totalsucessfultranspercent{99,26 \%}
\renewcommand\totalunsucessfultranspercent{0,74 \%}

\renewcommand\trafficmin{571,87 Mbit/s}
\renewcommand\trafficmax{776,76 Mbit/s}
\renewcommand\trafficavg{768,01 Mbit/s}
\renewcommand\packetsmin{69 292 packetů/s}
\renewcommand\packetsmax{89 647 packetů/s}
\renewcommand\packetsavg{88 766 packetů/s}


Srovnáme-li opět s netfilterem a \texttt{iptables}, zjistíme, že při tomto testu byly nftables opět výkonnější. Počet transakcí se příliš nezměnil (dosáhl čísla \totaltrans{}), ovšem přenosová rychlost se zvýšila na průměrnou hodnotu \trafficavg{} a packetová rychlost porostla na průměrnou hodnotu \packetsavg{}.
Grafy \ref{chart:nftablesbigfiltrudpsum} a \ref{chart:nftablesbigfiltrudpreal} výsledek jen podtrhují.



%===========================================

\subsubsection{Filtrace TCP/UDP, nižší rychlost}
\renewcommand\testname{filtrace TCP/UDP, nižší rychlost}

% TEST NAME:  nftables - small - filtr tcp/udp
\renewcommand\icmpunsucessfulpercent{21,09 \%}

\renewcommand\totaltrans{2 935 934 transakcí}
\renewcommand\totalsuccessfultrans{2 313 267 transakcí}
\renewcommand\totalunsuccessfultrans{622 667 transakcí}
\renewcommand\totalsucessfultranspercent{78,79 \%}
\renewcommand\totalunsucessfultranspercent{21,21 \%}

\renewcommand\trafficmin{39,37 Mbit/s}
\renewcommand\trafficmax{54,92 Mbit/s}
\renewcommand\trafficavg{48,20 Mbit/s}
\renewcommand\packetsmin{71 012 packetů/s}
\renewcommand\packetsmax{99 647 packetů/s}
\renewcommand\packetsavg{86 450 packetů/s}


Jelikož dle \cite{nftablesct} není aktuálně v~nftables podpora pro transparentní stavovou filtraci implementována, nelze ji vyzkoušet. Proto byla vyzkoušena jen bezstavová filtrace.

Podobně jako v~předchozích testech, byla i~v tomto měření vygenerována bezvýznamná výplňová pravidla:

\begin{listing}{1}
# for I in {1..100}; do
#	nft add rule bridge filter forward ether type ip \
	  ip saddr 192.168.3.$I drop
# done
# nft add rule bridge filter forward ether type ip \
    ip saddr 192.168.2.174 ip daddr 192.168.2.143 ip protocol tcp drop
# nft add rule bridge filter forward ether type ip \
    ip saddr 192.168.2.175 ip daddr 192.168.2.153 ip protocol udp drop
\end{listing}

Cyklus \verb+for+ tedy opět vytvoří pravidla, která se na provoz neaplikují. Druhý \texttt{nft} příkaz zakáže propuštění TCP provozu pro vybranou dvojici IP adres. Poslední příkaz zakáže pro danou dvojici IP adres provoz UDP.

Graf \ref{chart:nftablessmallfiltrtcpudpsum} ukazuje, že kromě správného provozu byl ve velké míře odfiltrován i nesprávný provoz. Graf \ref{chart:nftablessmallfiltrtcpudpreal} zase ukazuje rychlost přenosu dat, která byla průměrně \trafficavg{}, a rychlost generování packetů, která dosáhla průměru \packetsavg{}. Celkem bylo provedeno \totaltrans{}.
Uvedené hodnoty jsou horší než u netfilteru. Jde vidět, že nftables má problémy s více pravidly. V tomto případě by bylo efektivnější použít rozsah adres v jednom pravidle než 100 samostatných pravidel.


%===========================================

\subsubsection{Filtrace TCP/UDP, vyšší rychlost}
\renewcommand\testname{filtrace TCP/UDP, vyšší rychlost}

% TEST NAME:  nftables - big - filtr tcp/udp
\renewcommand\icmpunsucessfulpercent{2,60 \%}

\renewcommand\totaltrans{2 350 233 transakcí}
\renewcommand\totalsuccessfultrans{2 265 541 transakcí}
\renewcommand\totalunsuccessfultrans{84 692 transakcí}
\renewcommand\totalsucessfultranspercent{96,40 \%}
\renewcommand\totalunsucessfultranspercent{3,60 \%}

\renewcommand\trafficmin{2,01 Mbit/s}
\renewcommand\trafficmax{672,92 Mbit/s}
\renewcommand\trafficavg{594,22 Mbit/s}
\renewcommand\packetsmin{1 539 packetů/s}
\renewcommand\packetsmax{74 953 packetů/s}
\renewcommand\packetsavg{66 865 packetů/s}


Opět horší výsledek proti stejnému měření u~netfilteru + \texttt{iptables} (co se týká úspěšnosti přenosu dat, viz graf \ref{chart:nftablesbigfiltrtcpudpsum}). Na grafu \ref{chart:nftablesbigfiltrtcpudpreal} lze vidět,
že kolem 36. sekundy se odehrál nějaký problém, který se zřejmě podepsal na vysoké ztrátovosti HTTP komunikace na cílový server \texttt{192.168.2.153}. Nejspíš nějaký zádrhel na cílovém serveru,
jelikož další průběh na problémy s filtračním serverem neukazuje. Zajímavé ovšem je, že i přesto bylo dosaženo vyšší přenosové rychlosti než u netfilteru.

Celkově bylo provedeno \totaltrans{} při průměrné přenosové rychlosti \trafficavg{} a průměrné packetové rychlosti \packetsavg{}.



%===========================================


\subsection{PF\_RING}

\renewcommand\toolname{PF\_RING}


\subsubsection{Bez filtrace, nižší rychlost}
\renewcommand\testname{bez filtrace, nižší rychlost}

% TEST NAME:  pf_ring - small - no filtr
\renewcommand\icmpunsucessfulpercent{10,32 \%}

\renewcommand\totaltrans{5 720 014}
\renewcommand\totalsuccessfultrans{5 143 215 transakcí}
\renewcommand\totalunsuccessfultrans{576 799 transakcí}
\renewcommand\totalsucessfultranspercent{89,92 \%}
\renewcommand\totalunsucessfultranspercent{10,08 \%}

\renewcommand\trafficmin{80,39 Mbit/s}
\renewcommand\trafficmax{94,80 Mbit/s}
\renewcommand\trafficavg{87,60 Mbit/s}
\renewcommand\packetsmin{149 030 packetů/s}
\renewcommand\packetsmax{175 133 packetů/s}
\renewcommand\packetsavg{162 180 packetů/s}


Jako v~předchozích dvou případech, i~PF\_RING byl nejdříve otestován při dvou rychlostech datové propustnosti bez filtrace. Nejdříve nižší přenosová rychlost, ovšem vyšší packetová rychlost.
Jak lze vidět na grafu \ref{chart:pfringsmallnofiltrsum}, došlo k~nechtěným zahozením HTTP i DNS provozu.
Graf \ref{chart:pfringsmallnofiltrreal} se také odlišuje od stejných grafů předchozích nástrojů -- je vidět, že s~touto packetovou rychlostí měl PF\_RING problémy. To se kromě packetové rychlosti, která dosáhla průměru \packetsavg{},
projevilo i~na průměrné přenosové rychlosti -- \trafficavg{}, a samozřejmě také na celkovém počtu vyzkoušených transakcí -- \totaltrans{}. Celkem bylo neúspěšných cca \totalunsucessfultranspercent{} transakcí.



%===========================================

\subsubsection{Bez filtrace, vyšší rychlost}
\renewcommand\testname{bez filtrace, vyšší rychlost}

% TEST NAME:  pf_ring - big - no filtr
\renewcommand\icmpunsucessfulpercent{0,03 \%}

\renewcommand\totaltrans{2 582 916 transakcí}
\renewcommand\totalsuccessfultrans{2 581 935 transakcí}
\renewcommand\totalunsuccessfultrans{981 transakcí}
\renewcommand\totalsucessfultranspercent{99,96 \%}
\renewcommand\totalunsucessfultranspercent{0,04 \%}

\renewcommand\trafficmin{58,97 Mbit/s}
\renewcommand\trafficmax{763,57 Mbit/s}
\renewcommand\trafficavg{724,28 Mbit/s}
\renewcommand\packetsmin{9 937 packetů/s}
\renewcommand\packetsmax{87 466 packetů/s}
\renewcommand\packetsavg{82 792 packetů/s}


Při vyšší přenosové rychlosti (a s~většími packety) bylo neúspěšných jen \totalunsuccessfultrans{} (z~celkového počtu \totaltrans{}). V~relativních jednotkách se jedná o \totalunsucessfultranspercent{},
takže v~tomto testu se PF\_RING dá srovnávat s~předchozími nástroji. I když čísla jsou menší než například u nftables:
průměrná datová propustnost byla \trafficavg{}, průměrná rychlost generování packetů byla \packetsavg{}. Viz také grafy \ref{chart:pfringbignofiltrsum} a \ref{chart:pfringbignofiltrreal}.



%===========================================

\subsubsection{Filtrace IP adres, nižší rychlost}
\renewcommand\testname{filtrace IP adres, nižší rychlost}


% TEST NAME:  pf_ring - small - filtr ip
\renewcommand\icmpunsucessfulpercent{8,78 \%}

\renewcommand\totaltrans{4 202 463 transakcí}
\renewcommand\totalsuccessfultrans{3 778 528 transakcí}
\renewcommand\totalunsuccessfultrans{423 935 transakcí}
\renewcommand\totalsucessfultranspercent{89,91 \%}
\renewcommand\totalunsucessfultranspercent{10,09 \%}

\renewcommand\trafficmin{18,29 Mbit/s}
\renewcommand\trafficmax{78,84 Mbit/s}
\renewcommand\trafficavg{68,48 Mbit/s}
\renewcommand\packetsmin{33 819 packetů/s}
\renewcommand\packetsmax{150 131 packetů/s}
\renewcommand\packetsavg{129 392 packetů/s}


Filtrace podle IP adres byla provedena těmito příkazy:

\begin{listing}{1}
(term1)# ./pfbridge -a eth1 -b eth3 -f "not src host 192.168.2.174 and\
               not (src host 192.168.2.175 and dst host 192.168.2.143)"
(term2)# ./pfbridge -a eth3 -b eth1 -f "not src host 192.168.2.174 and\
               not (src host 192.168.2.175 and dst host 192.168.2.143)"
\end{listing}


Stejně jako při předchozích měřeních, byly spuštěny dvě instance \texttt{pfbridge} se stejnou filtrovací funkcí. Zde je pomocí BPF syntaxe vyfiltrována nejdříve jedna zdrojová IP adresa (\verb+not src host 192.168.2.174+)
a následně dvojice zdrojová--cílová IP adresa (\verb+not (src host 192.168.2.175 and dst host 192.168.2.143)+).

Důkaz, že filtrace proběhla správně, podává graf \ref{chart:pfringsmallfiltripsum}. Graf \ref{chart:pfringsmallfiltripreal} ukazuje průběhy packetové a bitové rychlosti, které jsou srovnatelné se stejným testem u nftables.
Bylo provedeno celkem \totaltrans{}, při průměrné packetové rychlosti \packetsavg{} a průměrné bitové rychlosti \trafficavg{}.


%===========================================

\subsubsection{Filtrace IP adres, vyšší rychlost}
\renewcommand\testname{filtrace IP adres, vyšší rychlost}

% TEST NAME:  pf_ring - big - filtr ip
\renewcommand\icmpunsucessfulpercent{17,77 \%}

\renewcommand\totaltrans{1 217 705 transakcí}
\renewcommand\totalsuccessfultrans{977 442 transakcí}
\renewcommand\totalunsuccessfultrans{240 263 transakcí}
\renewcommand\totalsucessfultranspercent{80,27 \%}
\renewcommand\totalunsucessfultranspercent{19,73 \%}

\renewcommand\trafficmin{35,79 Mbit/s}
\renewcommand\trafficmax{401,43 Mbit/s}
\renewcommand\trafficavg{311,70 Mbit/s}
\renewcommand\packetsmin{5 877 packetů/s}
\renewcommand\packetsmax{49 180 packetů/s}
\renewcommand\packetsavg{39 529 packetů/s}


Nastavení opět zůstalo. Výsledek testu lze srovnávat s~nftables (viz grafy \ref{chart:pfringbigfiltripsum} a \ref{chart:pfringbigfiltripreal}). Ačkoliv průměrná čísla jsou mírně horší:
celkem bylo vyzkoušeno \totaltrans{}. Přenosová rychlost dosáhla průměru \trafficavg{} (maximálně pak \trafficmax{}), packetová rychlost průměru \packetsavg{} (maximálně \packetsmax{}).



%===========================================

\subsubsection{Filtrace UDP portů, nižší rychlost}
\renewcommand\testname{filtrace UDP portů, nižší rychlost}

% TEST NAME:  pf_ring - small - filtr udp
\renewcommand\icmpunsucessfulpercent{16,25 \%}

\renewcommand\totaltrans{3 953 903 transakcí}
\renewcommand\totalsuccessfultrans{3 277 016 transakcí}
\renewcommand\totalunsuccessfultrans{676 887 transakcí}
\renewcommand\totalsucessfultranspercent{82,88 \%}
\renewcommand\totalunsucessfultranspercent{17,12 \%}

\renewcommand\trafficmin{572,00 kbit/s}
\renewcommand\trafficmax{94,37 Mbit/s}
\renewcommand\trafficavg{58,25 Mbit/s}
\renewcommand\packetsmin{1 115 packetů/s}
\renewcommand\packetsmax{165 998 packetů/s}
\renewcommand\packetsavg{106 302 packetů/s}

Pro vyfiltrování části UDP provozu byly použity tyto příkazy:

\begin{listing}{1}
(term1)# ./pfbridge -a eth1 -b eth3 -f "not (src host 192.168.2.174 \
               and udp src portrange 57000-58000) \
               and not (src host 192.168.2.175 \
               and dst host 192.168.2.143 and udp dst port 53)"
(term2)# ./pfbridge -a eth3 -b eth1 -f "not (src host 192.168.2.174 \
               and udp src portrange 57000-58000) \
               and not (src host 192.168.2.175 \
               and dst host 192.168.2.143 and udp dst port 53)"
\end{listing}

Příkazy provedou to, že z~adresy \texttt{192.168.2.174} vyfiltrují všechny zdrojové UDP porty z~rozsahu 57 000--58 000 a zakážou také komunikaci od zařízení \texttt{192.168.2.175} k~zařízení \texttt{192.168.2.143} na cílovém portu 53.

Že příkazy zřejmě dělají, co mají, ale PF\_RING vykazoval problémy, lze vidět na grafu \ref{chart:pfringsmallfiltrudpsum}. Je ale patrné, že nedošlo k úplnému vyfiltrování DNS komunikace na server \texttt{192.168.2.143}.
Celkově vzato měl PF\_RING s touto filtrací problémy. Graf \ref{chart:pfringsmallfiltrudpreal} ukazuje časový průběh testu z~pohledu přenosové rychlosti a packetové rychlosti, který ovšem příliš nekoresponduje
s grafy stejných měření ostatních nástrojů. Průměrná přenosová rychlost byla \trafficavg{} a průměrná packetová rychlost byla \packetsavg{}. Celkem bylo provedeno \totaltrans{}, což je proti nftables daleko horší výsledek.


%===========================================

\subsubsection{Filtrace UDP portů, vyšší rychlost}
\renewcommand\testname{filtrace UDP portů, vyšší rychlost}

% TEST NAME:  pf_ring - big - filtr udp - kpanic
\renewcommand\icmpunsucessfulpercent{0,57 \%}

\renewcommand\totaltrans{2 155 390 transakcí}
\renewcommand\totalsuccessfultrans{2 120 726 transakcí}
\renewcommand\totalunsuccessfultrans{34 664 transakcí}
\renewcommand\totalsucessfultranspercent{98,39 \%}
\renewcommand\totalunsucessfultranspercent{1,61 \%}

\renewcommand\trafficmin{28,23 Mbit/s}
\renewcommand\trafficmax{772,63 Mbit/s}
\renewcommand\trafficavg{700,26~Mbit/s}
\renewcommand\packetsmin{7 474 packetů/s}
\renewcommand\packetsmax{89 533 packetů/s}
\renewcommand\packetsavg{81 249 packetů/s}


Výsledky testu pro vyšší přenosovou rychlost jsou opět horší než u nftables. Graf \ref{chart:pfringbigfiltrudpkpanicsum} ukazuje docela velký počet nechtěných ztrát.
Graf průběhu měření \ref{chart:pfringbigfiltrudpkpanicreal} je již více podobný obdobným grafům u předchozích nástrojů, ovšem podstatný rozdíl tady je. Po 60. sekundě je vidět strmý pád
obou rychlostí. To bylo způsobeno tím, že v jádře operačního systému došlo k chybě, která vyvolala tzv. kernel panic. Ten se projevoval i při opakovaných pokusech.

Celkem proběhlo \totaltrans{} při průměrné rychlosti přenosu dat \trafficavg{} a průměrné packetové rychlosti \packetsavg{}.



%===========================================

\subsubsection{Filtrace TCP/UDP, nižší rychlost}
\renewcommand\testname{filtrace TCP/UDP, nižší rychlost}

% TEST NAME:  pf_ring - small - filtr tcp/udp
\renewcommand\icmpunsucessfulpercent{23,33 \%}

\renewcommand\totaltrans{2 654 032 transakcí}
\renewcommand\totalsuccessfultrans{2 030 358 transakcí}
\renewcommand\totalunsuccessfultrans{623 674 transakcí}
\renewcommand\totalsucessfultranspercent{76,50 \%}
\renewcommand\totalunsucessfultranspercent{23,50 \%}

\renewcommand\trafficmin{34,41 Mbit/s}
\renewcommand\trafficmax{50,38 Mbit/s}
\renewcommand\trafficavg{44,03 Mbit/s}
\renewcommand\packetsmin{61 990 packetů/s}
\renewcommand\packetsmax{92 604 packetů/s}
\renewcommand\packetsavg{78 599 packetů/s}


Jak je možné z~předchozího textu vytušit, ani PF\_RING nenabízí možnost stavové filtrace (jedná se o~jednoúčelovou utilitu, která přeposílá packety z~jednoho síťového rozhraní na druhé a při tom umožňuje nastavit pravidla, který provoz může projít a který ne). Proto ani v~tomto případě nebude stavová filtrace vyzkoušena.

Pro vyfiltrování jednoho sta zdrojových IP adres a TCP a UDP provozu pro určité zdrojové a cílové adresy, byly použity příkazy, které je možné nalézt v~příloze \ref{prikazypfringtcpudp}. Kromě bezpočtu \uv{pravidel} pro filtraci zdrojových IP adres, je na konci část, která filtruje TCP a UDP komunikace pro vybrané dvojice IP adres:

\begin{listing}{1}
  ...
  and not (src host 192.168.2.174 and dst host 192.168.2.143 \
  and ip proto \tcp) and not (src host 192.168.2.175 \
  and dst host 192.168.2.153 and ip proto \udp)"
\end{listing}

Podobně jako nftables, i PF\_RING v tomto testu příliš neobstál (vykazuje ještě horší výsledky než nftables):
v tomto případě bylo provedeno celkem \totaltrans{}. Průměr přenosové rychlosti byl \trafficavg{} a průměr packetové rychlosti byl \packetsavg{} (viz také graf \ref{chart:pfringsmallfiltrtcpudpreal}). Úspěšnost filtrace ukazuje graf \ref{chart:pfringsmallfiltrtcpudpsum}.

%===========================================

\subsubsection{Filtrace TCP/UDP, vyšší rychlost}
\renewcommand\testname{filtrace TCP/UDP, vyšší rychlost}


% TEST NAME:  pf_ring - big - filtr tcp/udp
\renewcommand\icmpunsucessfulpercent{11,20 \%}

\renewcommand\totaltrans{1 719 504 transakcí}
\renewcommand\totalsuccessfultrans{1 503 233 transakcí}
\renewcommand\totalunsuccessfultrans{216 271 transakcí}
\renewcommand\totalsucessfultranspercent{87,42 \%}
\renewcommand\totalunsucessfultranspercent{12,58 \%}

\renewcommand\trafficmin{4,49 Mbit/s}
\renewcommand\trafficmax{533,57 Mbit/s}
\renewcommand\trafficavg{415,33 Mbit/s}
\renewcommand\packetsmin{2 270 packetů/s}
\renewcommand\packetsmax{60 184 packetů/s}
\renewcommand\packetsavg{47 860 packetů/s}


Nastavení zůstalo stejné jako v~předchozím případě. Zcela nepochopitelně došlo dle grafu \ref{chart:pfringbigfiltrtcpudpsum} k úplné neúspěšnosti HTTP komunikací na cílový server \texttt{192.168.2.153},
ačkoliv tato filtrace nebyla nastavena.

Průměrná přenosová rychlost byla okolo \trafficavg{}.
Průměrná packetová rychlost pak byla \packetsavg{} (viz také graf \ref{chart:pfringbigfiltrtcpudpreal}). Celkem bylo provedeno \totaltrans{}. Každopádně i zde je výsledek horší než u nftables.



%===========================================


\subsection{netmap s vlastními ovladači NIC}

\renewcommand\toolname{netmap (vlastní ovladač)}


\subsubsection{Bez filtrace, nižší rychlost}
\renewcommand\testname{bez filtrace, nižší rychlost}

% TEST NAME:  netmap - small - no filtr
\renewcommand\icmpunsucessfulpercent{0 \%}

\renewcommand\totaltrans{10 716 426 transakcí}
\renewcommand\totalsuccessfultrans{10 716 426 transakcí}
\renewcommand\totalunsuccessfultrans{0 transakcí}
\renewcommand\totalsucessfultranspercent{100 \%}
\renewcommand\totalunsucessfultranspercent{0 \%}

\renewcommand\trafficmin{174,34 Mbit/s}
\renewcommand\trafficmax{177,10 Mbit/s}
\renewcommand\trafficavg{176,16 Mbit/s}
\renewcommand\packetsmin{331 669 packetů/s}
\renewcommand\packetsmax{337 447 packetů/s}
\renewcommand\packetsavg{335 589 packetů/s}


Na počátku testování netmapu byl opět proveden test bez filtrace. Výsledky nepřekvapí, opět jsou víceméně stejné jako u~předchozích nástrojů (s výjimkou PF\_RINGu). Celkem provedeno \totaltrans{}. Žádná transakce nebyla neúspěšná (viz také graf \ref{chart:netmapsmallnofiltrsum}).
Graf \ref{chart:netmapsmallnofiltrreal} ukazuje přenosovou a packetovou rychlost. Průměr přenosové rychlosti  dosáhl \trafficavg, průměr packetové rychlosti dosáhl \packetsavg{}.



%===========================================

\subsubsection{Bez filtrace, vyšší rychlost}
\renewcommand\testname{bez filtrace, vyšší rychlost}

% TEST NAME:  netmap - big - no filtr
\renewcommand\icmpunsucessfulpercent{0 \%}

\renewcommand\totaltrans{2 583 184 transakcí}
\renewcommand\totalsuccessfultrans{2 583 184 transakcí}
\renewcommand\totalunsuccessfultrans{0 transakcí}
\renewcommand\totalsucessfultranspercent{100 \%}
\renewcommand\totalunsucessfultranspercent{0 \%}

\renewcommand\trafficmin{757,05 Mbit/s}
\renewcommand\trafficmax{797,68 Mbit/s}
\renewcommand\trafficavg{775,23 Mbit/s}
\renewcommand\packetsmin{87 306 packetů/s}
\renewcommand\packetsmax{90 600 packetů/s}
\renewcommand\packetsavg{88 425 packetů/s}


V tomto testu také nedošlo k~zahození žádné transakce, proto je graf \ref{chart:netmapbignofiltrsum} celkem nezajímavý. Průměrná packetová rychlost
byla \packetsavg{} a průměrná přenosová rychlost se držela kolem \trafficavg{} (viz také graf \ref{chart:netmapbignofiltrreal}). Bylo vyzkoušeno celkem \totaltrans{}.



%===========================================

\subsubsection{Filtrace IP adres, nižší rychlost}
\renewcommand\testname{filtrace IP adres, nižší rychlost}


% TEST NAME:  netmap - small - filtr ip
\renewcommand\icmpunsucessfulpercent{8,79 \%}

\renewcommand\totaltrans{4 203 514 transakcí}
\renewcommand\totalsuccessfultrans{3 779 425 transakcí}
\renewcommand\totalunsuccessfultrans{424 089 transakcí}
\renewcommand\totalsucessfultranspercent{89,91 \%}
\renewcommand\totalunsucessfultranspercent{10,09 \%}

\renewcommand\trafficmin{58,64 Mbit/s}
\renewcommand\trafficmax{76,11 Mbit/s}
\renewcommand\trafficavg{68,57 Mbit/s}
\renewcommand\packetsmin{111 716 packetů/s}
\renewcommand\packetsmax{143 995 packetů/s}
\renewcommand\packetsavg{129 548 packetů/s}

Pro přidání pravidel pro filtraci IP adres byly použity příkazy:

\begin{listing}{1}
# ./ipfw add drop ip from 192.168.2.174 to any
# ./ipfw add drop ip from 192.168.2.175 to 192.168.2.143
\end{listing}

První příkaz zakáže veškerou IP komunikaci z~dané adresy (\verb+from 192.168.2.174+), druhý příkaz zakáže všechnu IP komunikaci z~vybrané adresy putující na cílový server (\verb+to 192.168.2.143+).

Stejně jako v~předchozích případech, i~zde nebylo dosaženo vysoké přenosové rychlosti (průměrně \trafficavg{}) ani packetové rychlosti (průměrně \packetsavg{}). Viz také graf \ref{chart:netmapsmallfiltripreal}.
Dle grafu \ref{chart:netmapsmallfiltripsum} ale došlo ke správnému odfiltrování provozu. Provedeno bylo celkem \totaltrans{}.


%===========================================

\subsubsection{Filtrace IP adres, vyšší rychlost}
\renewcommand\testname{filtrace IP adres, vyšší rychlost}

% TEST NAME:  netmap - big - filtr ip
\renewcommand\icmpunsucessfulpercent{17,94 \%}

\renewcommand\totaltrans{1 224 062 transakcí}
\renewcommand\totalsuccessfultrans{980 696 transakcí}
\renewcommand\totalunsuccessfultrans{243 366 transakcí}
\renewcommand\totalsucessfultranspercent{80,12 \%}
\renewcommand\totalunsucessfultranspercent{19,88 \%}

\renewcommand\trafficmin{257,99 Mbit/s}
\renewcommand\trafficmax{402,98 Mbit/s}
\renewcommand\trafficavg{321,67 Mbit/s}
\renewcommand\packetsmin{30 178 packetů/s}
\renewcommand\packetsmax{49 024 packetů/s}
\renewcommand\packetsavg{40 253 packetů/s}


I při vyšší rychlosti zůstalo stejné nastavení filtrace (viz graf \ref{chart:netmapbigfiltripsum}). Při celkovém počtu \totaltrans{} bylo dosaženo packetové rychlosti průměrně \packetsavg{} a průměrné datové propustnosti \trafficavg{} (průběh lze vidět v~grafu \ref{chart:netmapbigfiltripreal}).



%===========================================

\subsubsection{Filtrace UDP portů, nižší rychlost}
\renewcommand\testname{filtrace UDP portů, nižší rychlost}


% TEST NAME:  netmap - small - filtr udp
\renewcommand\icmpunsucessfulpercent{0 \%}

\renewcommand\totaltrans{10 716 426}
\renewcommand\totalsuccessfultrans{10 681 404 transakcí}
\renewcommand\totalunsuccessfultrans{35 022 transakcí}
\renewcommand\totalsucessfultranspercent{99,67 \%}
\renewcommand\totalunsucessfultranspercent{0,33 \%}

\renewcommand\trafficmin{130,39 Mbit/s}
\renewcommand\trafficmax{177,88 Mbit/s}
\renewcommand\trafficavg{175,75 Mbit/s}
\renewcommand\packetsmin{245 626 packetů/s}
\renewcommand\packetsmax{338 677 packetů/s}
\renewcommand\packetsavg{334 491 packetů/s}


Pro odfiltrování vybrané části UDP provozu byly použity příkazy:

\begin{listing}{1}
# ./ipfw add drop udp from 192.168.2.174 57000-58000 to any
# ./ipfw add drop udp from 192.168.2.175 to 192.168.2.143 dst-port 53
\end{listing}

Za slovem \verb+drop+ lze vidět, že vybíráme jen UDP provoz. Rozsah zdrojových portů se vkládá ihned za zdrojovou IP adresu. Cílový port se vkládá za cílovou IP adresu v~parametru \verb+dst-port+.

Jak je možné vidět v~grafu \ref{chart:netmapsmallfiltrudpsum}, byl odfiltrován správný provoz. Graf \ref{chart:netmapsmallfiltrudpreal} ukazuje časový průběh přenosové rychlosti, která byla v~průměru \trafficavg{},
a packetové rychlosti, která dosáhla průměru \packetsavg{}. Celkový počet transakcí dosáhl hodnoty \totaltrans{}.


%===========================================

\subsubsection{Filtrace UDP portů, vyšší rychlost}
\renewcommand\testname{filtrace UDP portů, vyšší rychlost}

% TEST NAME:  netmap - big - filtr udp
\renewcommand\icmpunsucessfulpercent{0 \%}

\renewcommand\totaltrans{2 583 184 provedených transakcí}
\renewcommand\totalsuccessfultrans{2 564 189 transakcí}
\renewcommand\totalunsuccessfultrans{18 995 transakcí}
\renewcommand\totalsucessfultranspercent{99,26 \%}
\renewcommand\totalunsucessfultranspercent{0,74 \%}

\renewcommand\trafficmin{579,99 Mbit/s}
\renewcommand\trafficmax{782,18 Mbit/s}
\renewcommand\trafficavg{768,38 Mbit/s}
\renewcommand\packetsmin{70 122 packetů/s}
\renewcommand\packetsmax{90 213 packetů/s}
\renewcommand\packetsavg{88 809 packetů/s}


Při průměrné přenosové rychlosti \trafficavg{} a průměrné packetové rychlosti \packetsavg{} (viz také graf \ref{chart:netmapbigfiltrudpreal}) bylo dosaženo \totaltrans{}. Podle grafu \ref{chart:netmapbigfiltrudpsum} proběhla filtrace dle předpokladu.



%===========================================

\subsubsection{Filtrace TCP/UDP, nižší rychlost, bezstavová}
\renewcommand\testname{filtrace TCP/UDP, nižší rychlost, bezstavová}


% TEST NAME:  netmap - small - filtr tcp/udp
\renewcommand\icmpunsucessfulpercent{1,88 \%}

\renewcommand\totaltrans{9 495 123 transakcí}
\renewcommand\totalsuccessfultrans{9 296 257 transakcí}
\renewcommand\totalunsuccessfultrans{198 866 transakcí}
\renewcommand\totalsucessfultranspercent{97,91 \%}
\renewcommand\totalunsucessfultranspercent{2,09 \%}

\renewcommand\trafficmin{101,42 Mbit/s}
\renewcommand\trafficmax{144,18 Mbit/s}
\renewcommand\trafficavg{138,63 Mbit/s}
\renewcommand\packetsmin{192 105 packetů/s}
\renewcommand\packetsmax{274 251 packetů/s}
\renewcommand\packetsavg{263 736 packetů/s}


Netmap ve svém firewallu \texttt{netmap-ipfw} umožňuje zadat pravidla pracující se stavem spojení, proto může být stavová filtrace vyzkoušena. Nejdříve však proběhnou testy bez stavových pravidel.

\begin{listing}{1}
# for I in {1..100}; do
#	./ipfw add drop ip from 192.168.3.$I to any
# done
# ./ipfw add drop tcp from 192.168.2.174 to 192.168.2.143
# ./ipfw add drop udp from 192.168.2.175 to 192.168.2.153
\end{listing}

Cyklus \verb+for+ opět přidá 100 jednoduchých pravidel, které se ale v~testu neaplikují. Další \texttt{ipfw} příkaz vyfiltruje TCP komunikaci mezi dvěma stanicemi a poslední příkaz vyfiltruje veškerou UDP komunikaci mezi jinými dvěma stanicemi.

Správnost filtrace dokazuje graf \ref{chart:netmapsmallfiltrtcpudpsum}. Při tomto testu se průměrná přenosová rychlost držela kolem \trafficavg{} a průměrná rychlost generování packetů kolem \packetsavg{} (průběhy lze vidět v~grafu \ref{chart:netmapsmallfiltrtcpudpreal}). Celkově bylo vygenerováno \totaltrans{}.


%===========================================

\subsubsection{Filtrace TCP/UDP, vyšší rychlost, bezstavová}
\renewcommand\testname{filtrace TCP/UDP, vyšší rychlost, bezstavová}

% TEST NAME:  netmap - big - filtr tcp/udp
\renewcommand\icmpunsucessfulpercent{0 \%}

\renewcommand\totaltrans{2 579 755 transakcí}
\renewcommand\totalsuccessfultrans{2 567 057 transakcí}
\renewcommand\totalunsuccessfultrans{12 698 transakcí}
\renewcommand\totalsucessfultranspercent{99,51 \%}
\renewcommand\totalunsucessfultranspercent{0,49 \%}

\renewcommand\trafficmin{471,29 Mbit/s}
\renewcommand\trafficmax{778,15 Mbit/s}
\renewcommand\trafficavg{744,30 Mbit/s}
\renewcommand\packetsmin{55 353 packetů/s}
\renewcommand\packetsmax{88 166 packetů/s}
\renewcommand\packetsavg{84 418 packetů/s}


Při vyšší přenosové rychlosti bylo dosaženo průměrně \trafficavg{} (viz také graf \ref{chart:netmapbigfiltrtcpudpreal}). Packetová rychlost dosáhla průměru \packetsavg{}. Že nastavení filtrace zůstalo stejné jako v~předchozím případě a že nebylo zahozeno nic navíc, zobrazuje graf \ref{chart:netmapbigfiltrtcpudpsum}.
Celkem bylo provedeno \totaltrans{}.



%===========================================

\subsubsection{Filtrace TCP/UDP, nižší rychlost, stavová}
\renewcommand\testname{filtrace TCP/UDP, nižší rychlost, stavová}

% TEST NAME:  netmap - small - filtr tcp/udp - conntrack
\renewcommand\icmpunsucessfulpercent{7,82 \%}

\renewcommand\totaltrans{6 197 999 transakcí}
\renewcommand\totalsuccessfultrans{5 698 936 transakcí}
\renewcommand\totalunsuccessfultrans{499 063 transakcí}
\renewcommand\totalsucessfultranspercent{91,95 \%}
\renewcommand\totalunsucessfultranspercent{8,05 \%}

\renewcommand\trafficmin{4,30 Mbit/s}
\renewcommand\trafficmax{112,59 Mbit/s}
\renewcommand\trafficavg{92,97 Mbit/s}
\renewcommand\packetsmin{5 559 packetů/s}
\renewcommand\packetsmax{212 430 packetů/s}
\renewcommand\packetsavg{174 608 packetů/s}


Stejně jako u netfilteru a \texttt{iptables} bylo v~tomto případě na přepínačích připojených k~filtračnímu serveru nastaveno posílání veškerého provozu přes testovací server.

Filtrování bylo provedeno tímto způsobem:

\begin{listing}{1}
# ./ipfw add check-state
# for I in {1..100}; do
#	./ipfw add drop ip from 192.168.3.$I to any
# done
# ./ipfw add drop tcp from 192.168.2.174 to 192.168.2.143
# ./ipfw add drop udp from 192.168.2.175 to 192.168.2.153
# ./ipfw add allow tcp from any to any setup keep-state
# ./ipfw add allow udp from any to any setup keep-state
\end{listing}

Příkaz na řádku 1 vloží jako první pravidlo akci \verb+check-state+, která se stará o~zkontrolování komunikace vůči seznamu již povolených spojení a jeho případné povolení. Dále následuje přidání jednoho sta bezvýznamných pravidel.
Následuje zakázání TCP a UDP komunikace pro vybrané dvojice IP adres (stejně jako při bezstavovém filtrování). A~poslední dva příkazy povolují všechny TCP a UDP komunikace, a zároveň by povolenou komunikaci měly zavést do seznamu povolených spojení (\verb+setup keep-state+).

Dle grafu \ref{chart:netmapsmallfiltrtcpudpconntracksum} došlo k~odfiltrování správné komunikace, ovšem při tom byl nepatrně zahozen i~provoz, který měl zůstat povolen (HTTP provoz z~rozsahu2 a rozsahu3 na \texttt{192.168.2.153}).
Graf \ref{chart:netmapsmallfiltrtcpudpconntrackreal} zobrazuje časovou závislost přenosové a packetové rychlosti, které v~tomto případě dosáhly průměrných hodnot \trafficavg{} a \packetsavg{}. Celkem se vygenerovalo \totaltrans{}.

Jak je z~výsledků a grafů vidět, na rozdíl od netfilteru, nebylo proti bezstavovému testu dosaženo lepšího výsledku (došlo dokonce k~mírnému zhoršení kvůli zahození i~jiného provozu, než který byl vyžadován).



%===========================================

\subsubsection{Filtrace TCP/UDP, vyšší rychlost, stavová}
\renewcommand\testname{filtrace TCP/UDP, vyšší rychlost, stavová}

% TEST NAME:  netmap - big - filtr tcp/udp - conntrack
\renewcommand\icmpunsucessfulpercent{0 \%}

\renewcommand\totaltrans{2 575 755}
\renewcommand\totalsuccessfultrans{2 562 278 transakcí}
\renewcommand\totalunsuccessfultrans{13 477 transakcí}
\renewcommand\totalsucessfultranspercent{99,48 \%}
\renewcommand\totalunsucessfultranspercent{0,52 \%}

\renewcommand\trafficmin{7,50 Mbit/s}
\renewcommand\trafficmax{804,03 Mbit/s}
\renewcommand\trafficavg{740,74 Mbit/s}
\renewcommand\packetsmin{4 392 packetů/s}
\renewcommand\packetsmax{89 566 packetů/s}
\renewcommand\packetsavg{83 931 packetů/s}


Test pro vyšší rychlost je podobný stavu pro nižší rychlost: i~zde bylo dosaženo spíše horších čísel než u~bezstavové filtrace (ačkoliv ne o moc). Průměrná přenosová rychlost byla \trafficavg{}, průměrná packetová rychlost byla \packetsavg{} (viz také graf \ref{chart:netmapbigfiltrtcpudpconntrackreal}).
I při tomto testu bylo zahozeno určité množství nechtěného provozu (dle grafu \ref{chart:netmapbigfiltrtcpudpconntracksum}). Počet provedených transakcí dosáhl počtu \totaltrans{}.

V tomto případě může vyvstat otázka, zda-li se pravidla pro kontrolu stavu a povolení spojení (případně zavedení do seznamu spojení) vůbec aplikují. Zde to opravdu vypadá, že k~hlídání stavu skutečně nedojde. Lze tak usoudit na základě výpisu pravidel s~čítači jejich použití (výpis je zkrácen):

\begin{listing}{1}
00100        0          0 check-state
00200        0          0 deny ip from 192.168.3.1 to any
...
10100        0          0 deny ip from 192.168.3.100 to any
10200     4061     178640 deny tcp from 192.168.2.174 to 192.168.2.143
10300     6078     334290 deny udp from 192.168.2.175 to 192.168.2.153
10400   140954   33085789 allow tcp from any to any setup keep-state
10500        0          0 allow udp from any to any setup keep-state
65535 40744522 2852146698 allow ip from any to any
\end{listing}

Číslo v~prvním sloupci označuje pořadové číslo pravidla. Druhé číslo označuje počet packetů, na které bylo pravidlo aplikováno. Třetí označuje počet bajtů, které daným pravidlem \uv{prošly}. Zbytek řádku ukazuje samotné pravidlo firewallu.

Jak lze vidět, pravidlo pro zkontrolování spojení a jeho případné povolení, nebylo použito vůbec. Stejně tak kupodivu nebylo aplikováno pravidlo pro povolení UDP komunikací a jejich zavedení do seznamu povolených spojení, ačkoliv stejné pravidlo pro TCP spojení aplikováno bylo.

S největší pravděpodobností tedy netmap umožňuje vložit pravidla pro stavovou filtraci, ovšem samotné hlídání stavu není ve skutečnosti implementováno. Jak bylo uvedeno v~sekci \ref{netmap}, je netmap původně vyvinut pro operační systém FreeBSD.
Je tedy docela možné, že stavová filtrace nefunguje jen Linuxu, ovšem ve FreeBSD ano.


%===========================================

\section{Agregace síťových rozhraní v experimentální síti}

Jak již bylo v~předchozích odstavcích naznačeno, díky univerzálnosti síťové infrastruktury experimentální sítě a také filtračního serveru, bylo možné jej zapojit tak, aby mohla být vyzkoušena agregace síťových linek.
Původní dvouportová síťová karta Intel byla vyměněna za čtyřportovou verzi. Dvě rozhraní pak byla připojena k~přepínači Mikrotik-IN a dvě rozhraní k~přepínači Mikrotik-OUT. Dohromady tedy vytvořily dvě linky o~přenosové kapacitě 2 Gbit/s.
Zapojení ukáže názorněji obrázek \ref{fig:experimentbonding}.

\begin{figure}[ht]
	\centering
	\includegraphics[width=0.8\textwidth,keepaspectratio=true]{linkova-agregace-experiment}
	\vspace{6mm}
	\caption{Tímto způsobem byl filtrační server připojen k~přepínačům. Čárkovaná čára znamená optické propojení, plná čára značí metalické propojení.}
	\label{fig:experimentbonding}
\end{figure}

Při zkoumání podpory vybraných filtračních nástrojů bylo zjištěno, že ani PF\_RING ani netmap neumožňují seskupování síťových rozhraní. Jedinými zástupci pro tento test tedy byly netfilter + \texttt{iptables} a nftables,
jelikož využívají standardní linuxový síťový zásobník, který tuto funkci podporuje.

\subsection{Nastavení bondingu}

Dle kapitoly \ref{linkova-agregace} lze v~Linuxu pro agregaci linek použít dvě řešení -- NIC bonding a NIC teaming. V~tomto případě byl vybrán NIC bonding, jelikož bývá standardní součástí linuxového jádra, a není tedy nutné
nic doinstalovávat.

Nejdříve je potřeba vytvořit virtuální bonding rozhraní. To můžeme provést tímto způsobem:

\begin{listing}{1}
# ip link add name bond0 type bond mode balance-xor \
      xmit_hash_policy layer3+4
# ip link add name bond1 type bond mode balance-xor \
      xmit_hash_policy layer3+4
\end{listing}

Těmito příkazy vytvoříme dvě rozhraní \texttt{bond0} a \texttt{bond1} typu \texttt{bond}. Jako mód pro vyvažování zátěže je zvolen \texttt{balance-xor}, který
rozprostírá zátěž tak, že pro každý packet vypočítá z~informací v~jeho hlavičkách hodnotu, jenž funguje jako identifikátor odchozího fyzického rozhraní. Jak samotný název
módu napovídá, pro výpočet hodnoty se používá operace XOR a také modulo. Ve výchozím stavu se hodnota počítá jako [(zdrojová MAC adresa XOR cílová MAC adresa XOR ID typu packetu) modulo počet podřízených rozhraní].
V tomto případě je však hned následujícím parametrem \texttt{xmit\_hash\_policy} výpočet upraven tak, aby se hodnota počítala z~hlaviček síťové a transportní vrstvy ISO OSI modelu. Více v~\cite{linuxbonding}.
Uvedený mód byl vybrán tak, aby co nejvíce odpovídal módu vyvažování na straně přepínačů.

Následně je potřeba přiřadit jednotlivé fyzické porty k~bonding rozhraním a tato rozhraní aktivovat:

\begin{listing}{1}
# ip link set eth1 master bond0
# ip link set eth3 master bond0
# ip link set eth0 master bond1
# ip link set eth2 master bond1
# ip link set bond0 up
# ip link set bond1 up
\end{listing}

Nakonec se vytvoří virtuální rozhraní pro síťový most, do kterého se zařadí obě bonding rozhraní:

\begin{listing}{1}
# ip link add br0 type bridge
# ip link set bond0 master br0
# ip link set bond1 master br0
# ip link set br0 up
\end{listing}

Příkazem na řádku číslo 4 se síťový most aktivuje a server by měl začít přeposílat provoz z~jednoho bonding rozhraní na druhé, a to přenosovou rychlostí až 2 Gbit/s.

\subsection{Nastavení Spirent Avalanche 3100B}

Generovaná zátěž byla nastavena ve velké míře stejně, jako zátěž pro vyšší rychlost z~předchozího testování (viz podsekci \ref{organizaceazpusobtestovani}).
Jediný rozdíl byl ten, že místo 1,4kB souboru se v~HTTP POST požadavcích posílal soubor velký 1 MB. Druhou změnou bylo použití jiné specifikace zátěže. Místo
\uv{SimUsers/second} (tedy simulovaných uživatelů za sekundu) byla zátěž definována v transakcích (viz obrázek \ref{fig:avalancheloadag}). Díky této
změně generoval Spirent Avalanche 3100B stabilnější zátěž než v případě použití simulovaných uživatelů. Jak je na obrázku vidět, časový průběh zůstal stejný.

\begin{figure}[ht]
	\centering
	\includegraphics[width=\textwidth,keepaspectratio=true]{avalanche-load}
	\vspace{4mm}
	\caption{Nastavení zátěže a časového průběhu testu při testování linkové agregace.}
	\label{fig:avalancheloadag}
\end{figure}

Při testování filtrace na agregovaných linkách byla zkoušena jen jedna rychlost, nastavená dle předchozího odstavce. Testovat na nižší rychlosti nedávalo smysl,
jelikož zkoušíme přenosovou rychlost nad 1 Gbit/s. Výše popsaným způsobem byl vygenerován tok o~velikosti v~průměru 1,4 Gbit/s, maximálně pak přibližně 1,6 Gbit/s.
Packetová rychlost dosáhla průměru zhruba 116 tisíc packetů za sekundu. Rozložení velikosti packetů ve vygenerovaném datovém toku je v~tabulce \ref{tab:rozlozenibonding}.

\begin{table}[ht]
	\centering
	\begin{tabular}{|c|c|}
	\hline
	\textbf{Velikost packetu (bajty)} & \textbf{Procentuální zastoupení (\%)}\\
	\hline
	\hline
	0--64 & 1,00 \\
	\hline
	65--128 & 0,33 \\
	\hline
	1 025--1 500 & 8,33 \\
	\hline
	1 500+ & 90,33 \\
	\hline
	\end{tabular}
	\vspace{6mm}
	\caption{Rozložení velikostí packetů v~datovém toku při testování bondingu (cca 1,4~Gbit/s). Protože bylo nastaveno posílání souboru, jehož obsah se do jednoho packetu nevejde, byly Avalanchem HTTP dotazy fragmentovány do packetů, jejichž velikost na linkové vrstvě ISO OSI modelu dosahovala 1 514 bajtů (resp. 1 518 B s kontrolním součtem).}
	\label{tab:rozlozenibonding}
\end{table}

Jelikož byly do experimentální sítě zapojeny jen gigabitová rozhraní z~Avalanche, byl pro tento test alokován další port (konkrétně port číslo 3), takže mohl být vygenerován síťový provoz
o velikosti větší než 1 Gbit/s. Adresní prostor, který byl k~dispozici, musel být rozdělen mezi porty tak, aby se nepřekrýval. Přiřazení IP adres k portům a jejich rozdělení bylo provedeno tímto způsobem:

\begin{itemize}
	\item \texttt{192.168.2.174}, port č. 4 (dále označen jako rozsah1),
	\item \texttt{192.168.2.175}, port č. 4 (dále označen jako rozsah2),
	\item \texttt{192.168.2.176}, port č. 4 (dále označen jako rozsah3),
	\item \texttt{192.168.2.177-192.168.2.179}, port č. 3 (dále označen jako rozsah4).
\end{itemize}

To jsou veškeré úpravy, které byly oproti nastavení z~předchozího testování provedeny. Nastavení filtračních nástrojů v~jednotlivých testech, a případná další nastavení, byla provedena stejně jako v~sekci \ref{testovanivexperimentalnisiti}.



\subsection{netfilter + iptables}

\renewcommand\toolname{netfilter + \texttt{iptables}}


\subsubsection{Bez filtrace}
\renewcommand\testname{bez filtrace}

% TEST NAME:  iptables - bonding - no filtr
\renewcommand\icmpunsucessfulpercent{0.06 \%}

\renewcommand\totaltrans{375 031 transakcí}
\renewcommand\totalsuccessfultrans{374 782 transakcí}
\renewcommand\totalunsuccessfultrans{249 transakcí}
\renewcommand\totalsucessfultranspercent{99,93\%}
\renewcommand\totalunsucessfultranspercent{0,07 \%}



\renewcommand\trafficmin{126,74 Mbit/s}
\renewcommand\trafficmax{1,59 Gbit/s}
\renewcommand\trafficavg{1,38 Gbit/s}
\renewcommand\packetsmin{10 668 packetů/s}
\renewcommand\packetsmax{134 362 packetů/s}
\renewcommand\packetsavg{116 531 packetů/s}


Jako první byl opět testován netfilter s~\texttt{iptables}. Nejdříve bez nastavení jakékoliv filtrace.

Při této zkoušce bylo vygenerováno \totaltrans{}, z~toho \totalunsuccessfultrans{} neúspěšných, což znamená \totalsucessfultranspercent{} úspěšnost (viz také graf \ref{chart:iptablesbondingnofiltrsum}).
Bylo dosaženo maximální přenosové rychlosti \trafficmax{} (průměrná rychlost \trafficavg{}) a průměrné packetové rychlosti \packetsavg{} (průběh je v~grafu \ref{chart:iptablesbondingnofiltrreal}).

Z výsledků a grafů vyplývá, že při použití bondingu dochází v~malé míře k~zahazování legitimního provozu.

%===========================================

\subsubsection{Filtrace IP adres}
\renewcommand\testname{filtrace IP adres}

% TEST NAME:  iptables - bonding - filtr ip
\renewcommand\icmpunsucessfulpercent{1.84 \%}

\renewcommand\totaltrans{270 793 transakcí}
\renewcommand\totalsuccessfultrans{265 052 transakcí}
\renewcommand\totalunsuccessfultrans{5 741 transakcí}
\renewcommand\totalsucessfultranspercent{97,88 \%}
\renewcommand\totalunsucessfultranspercent{2,12 \%}



\renewcommand\trafficmin{33,94 Mbit/s}
\renewcommand\trafficmax{1,29 Gbit/s}
\renewcommand\trafficavg{981,71 Mbit/s}
\renewcommand\packetsmin{2 882 packetů/s}
\renewcommand\packetsmax{109 221 packetů/s}
\renewcommand\packetsavg{83 139 packetů/s}


V tomto případě bylo provedeno celkem \totaltrans{} při průměrné rychlosti generování packetů \packetsavg{} a průměrné datové rychlosti \trafficavg{}. Více také v~grafech \ref{chart:iptablesbondingfiltripsum} a \ref{chart:iptablesbondingfiltripreal}.

I v~tomto případě došlo zahození provozu, který měl zůstat povolen. Konkrétně bylo neúspěšných až 6 \% HTTP provozu na cílový server \texttt{192.168.2.153} z~rozsahu2.



%===========================================


\subsubsection{Filtrace UDP portů}
\renewcommand\testname{filtrace UDP portů}

% TEST NAME:  iptables - bonding - filtr udp
\renewcommand\icmpunsucessfulpercent{0.05 \%}

\renewcommand\totaltrans{376 400 transakcí}
\renewcommand\totalsuccessfultrans{375 054 transakcí}
\renewcommand\totalunsuccessfultrans{1 346 transakcí}
\renewcommand\totalsucessfultranspercent{99,64 \%}
\renewcommand\totalunsucessfultranspercent{0,36 \%}



\renewcommand\trafficmin{67,66 Mbit/s}
\renewcommand\trafficmax{1,59 Gbit/s}
\renewcommand\trafficavg{1,37 Gbit/s}
\renewcommand\packetsmin{5 800 packetů/s}
\renewcommand\packetsmax{133 830 packetů/s}
\renewcommand\packetsavg{115 976 packetů/s}


Při filtraci UDP packetů bylo dosaženo podobné přenosové rychlosti, jako bez filtrace -- průměrně \trafficavg{} (většinu provozu tvořil HTTP provoz, který nebyl filtrován).
Průměrná packetová rychlost byla \packetsavg{} (viz také graf \ref{chart:iptablesbondingfiltrudpreal}). Celkově bylo provedeno \totaltrans{}.
Graf \ref{chart:iptablesbondingfiltrudpsum} ukazuje, že v~omezené míře došlo opět k~nechtěným zahozeným transakcím.



%===========================================

\subsubsection{Filtrace TCP/UDP, bezstavová}
\renewcommand\testname{filtrace TCP/UDP, bezstavová}

% TEST NAME:  iptables - bonding - filtr tcp/udp - no conntrack
\renewcommand\icmpunsucessfulpercent{0.13 \%}

\renewcommand\totaltrans{269 019 transakcí}
\renewcommand\totalsuccessfultrans{268 136 transakcí}
\renewcommand\totalunsuccessfultrans{883 transakcí}
\renewcommand\totalsucessfultranspercent{99,67 \%}
\renewcommand\totalunsucessfultranspercent{0,33 \%}



\renewcommand\trafficmin{252,09 Mbit/s}
\renewcommand\trafficmax{1,02 Gbit/s}
\renewcommand\trafficavg{921,58 Mbit/s}
\renewcommand\packetsmin{21 359 packetů/s}
\renewcommand\packetsmax{86 090 packetů/s}
\renewcommand\packetsavg{78 075 packetů/s}


Při bezstavové verzi tohoto testu bylo vyzkoušeno celkem \totaltrans{}. Průměr přenosové rychlosti dosáhl \trafficavg{} (maximum pak \trafficmax{}). Packetová rychlost byla průměrně
\packetsavg{}. Časové průběhy těchto veličin jsou k~dispozici v~příloze v~grafu \ref{chart:iptablesbondingfiltrtcpudpnoconntrackreal}.

TCP a UDP provoz byl vyfiltrován správně, ovšem částečně i~s provozem navíc (dle grafu \ref{chart:iptablesbondingfiltrtcpudpnoconntracksum}).



%===========================================

\subsubsection{Filtrace TCP/UDP, stavová}
\renewcommand\testname{filtrace TCP/UDP, stavová}

% TEST NAME:  iptables - bonding - filtr tcp/udp - conntrack
\renewcommand\icmpunsucessfulpercent{0.10 \%}

\renewcommand\totaltrans{300 377 transakcí}
\renewcommand\totalsuccessfultrans{299 477 transakcí}
\renewcommand\totalunsuccessfultrans{900 transakcí}
\renewcommand\totalsucessfultranspercent{99,70 \%}
\renewcommand\totalunsucessfultranspercent{0,30 \%}



\renewcommand\trafficmin{98,77 Mbit/s}
\renewcommand\trafficmax{1,19 Gbit/s}
\renewcommand\trafficavg{1,03 Gbit/s}
\renewcommand\packetsmin{8 250 packetů/s}
\renewcommand\packetsmax{100 613 packetů/s}
\renewcommand\packetsavg{86 904 packetů/s}

Díky tomu, že netfilter s~\texttt{iptables} podporuje stavovou filtraci, bylo možné ji i~tentokrát vyzkoušet.

Při tomto testu bylo provedeno celkově \totaltrans{}. A~to při průměrné přenosové rychlosti \trafficavg{} (maximální rychlost \trafficmax{}) a průměrné packetové rychlosti okolo \packetsavg{}.
Závislost těchto veličin na čase lze zhlédnout na grafu \ref{chart:iptablesbondingfiltrtcpudpconntrackreal}. Úspěšnost filtrace lze dohledat v~grafu \ref{chart:iptablesbondingfiltrtcpudpconntracksum}.

Ačkoliv rozdíl mezi stavovou a bezstavovou filtrací není příliš patrný, opět došlo k~mírnému zlepšení.




%===========================================

\subsection{nftables}
\renewcommand\toolname{nftables}

\subsubsection{Bez filtrace}
\renewcommand\testname{bez filtrace}

% TEST NAME:  nftables - bonding - no filtr
\renewcommand\icmpunsucessfulpercent{0.08 \%}

\renewcommand\totaltrans{380 818 transakcí}
\renewcommand\totalsuccessfultrans{380 515 transakcí}
\renewcommand\totalunsuccessfultrans{303 transakcí}
\renewcommand\totalsucessfultranspercent{99,92 \%}
\renewcommand\totalunsucessfultranspercent{0,08 \%}



\renewcommand\trafficmin{38,37 Mbit/s}
\renewcommand\trafficmax{1,58 Gbit/s}
\renewcommand\trafficavg{1,39 Gbit/s}
\renewcommand\packetsmin{3 374 packetů/s}
\renewcommand\packetsmax{133 696 packetů/s}
\renewcommand\packetsavg{117 746 packetů/s}


Při testu nftables bez filtrace bylo dosaženo mírně lepšího výsledku než u~netfilteru s~\texttt{iptables}. Bylo provedeno o~cca 5 000 transakcí více. Packetová rychlost dosáhla průměru \packetsavg{},
přenosová rychlost pak průměru \trafficavg{} a maxima \trafficmax{} (viz také graf \ref{chart:nftablesbondingnofiltrreal}).

Stejně jako v~předchozích případech, došlo k~vyfiltrování správného provozu, ovšem i~k~nechtěným zahozením (více v~grafu \ref{chart:nftablesbondingnofiltrsum}).



%===========================================

\subsubsection{Filtrace IP adres}
\renewcommand\testname{filtrace IP adres}

% TEST NAME:  nftables - bonding - filtr ip
\renewcommand\icmpunsucessfulpercent{1.89 \%}

\renewcommand\totaltrans{275 152 transakcí}
\renewcommand\totalsuccessfultrans{269 220 transakcí}
\renewcommand\totalunsuccessfultrans{5 932 transakcí}
\renewcommand\totalsucessfultranspercent{97,84 \%}
\renewcommand\totalunsucessfultranspercent{2,16 \%}



\renewcommand\trafficmin{41,45 Mbit/s}
\renewcommand\trafficmax{1,21 Gbit/s}
\renewcommand\trafficavg{1,01 Gbit/s}
\renewcommand\packetsmin{3 605 packetů/s}
\renewcommand\packetsmax{102 361 packetů/s}
\renewcommand\packetsavg{85 479 packetů/s}


I v~případě filtrace IP adres došlo k~mírnému zlepšení oproti předchozímu nástroji. Přenosová rychlost se průměrně pohybovala okolo \trafficavg{} (maximálně dosáhla \trafficmax{}). 
Generování packetů se provádělo průměrně rychlostí \packetsmax{}. Provedeno bylo celkem \totaltrans{}.

Úspěšnost filtrace ukazuje graf \ref{chart:nftablesbondingfiltripsum}. Časové průběhy rychlostí jsou k~dispozici v~grafu \ref{chart:nftablesbondingfiltripreal}.



%===========================================

\subsubsection{Filtrace UDP portů}
\renewcommand\testname{filtrace UDP portů}

% TEST NAME:  nftables - bonding - filtr udp
\renewcommand\icmpunsucessfulpercent{0.05 \%}

\renewcommand\totaltrans{370 753 transakcí}
\renewcommand\totalsuccessfultrans{369 463 transakcí}
\renewcommand\totalunsuccessfultrans{1 290 transakcí}
\renewcommand\totalsucessfultranspercent{99,65 \%}
\renewcommand\totalunsucessfultranspercent{0,35 \%}



\renewcommand\trafficmin{68,94 Mbit/s}
\renewcommand\trafficmax{1,59 Gbit/s}
\renewcommand\trafficavg{1,35 Gbit/s}
\renewcommand\packetsmin{5 977 packetů/s}
\renewcommand\packetsmax{134 057 packetů/s}
\renewcommand\packetsavg{114 582 packetů/s}


Při filtraci UDP portů bylo tentokrát dosaženo mírně horšího výsledku než u~netfilteru a \texttt{iptables}. Bylo vyzkoušeno méně transakcí (přesně \totaltrans{}, což je o~cca 6 000 transakcí méně).
Průměrná přenosová rychlost byla \trafficavg{} a packetová rychlost se průměrně pohybovala okolo \packetsavg{}. Časové průběhy ukazuje graf \ref{chart:nftablesbondingfiltrudpreal}.

Opět došlo k~mírnému zahození provozu, který měl projít bez větších problémů (viz graf \ref{chart:nftablesbondingfiltrudpsum}).



%===========================================

\subsubsection{Filtrace TCP/UDP}
\renewcommand\testname{filtrace TCP/UDP}

% TEST NAME:  nftables - bonding - filtr tcp/udp
\renewcommand\icmpunsucessfulpercent{0.16 \%}

\renewcommand\totaltrans{235 699 transakcích}
\renewcommand\totalsuccessfultrans{234 816 transakcí}
\renewcommand\totalunsuccessfultrans{883 transakcí}
\renewcommand\totalsucessfultranspercent{99,63 \%}
\renewcommand\totalunsucessfultranspercent{0,37 \%}



\renewcommand\trafficmin{240,10 Mbit/s}
\renewcommand\trafficmax{844,44 Mbit/s}
\renewcommand\trafficavg{803,32 Mbit/s}
\renewcommand\packetsmin{20 347 packetů/s}
\renewcommand\packetsmax{70 991 packetů/s}
\renewcommand\packetsavg{68 043 packetů/s}

V případě filtrace TCP a UDP provozu a zaplnění filtrovací tabulky jedním stem bezvýznamných pravidel, nebylo dosaženo lepších nebo stejných hodnot jako u~předchozího filtračního nástroje.
Při celkově vyzkoušených \totaltrans{} se držela přenosová rychlost průměrně okolo \trafficavg{} (maximum bylo \trafficmax{}) a packetová rychlost okolo \packetsavg{}.

Výsledek úspěšnosti filtrace shrnuje graf \ref{chart:nftablesbondingfiltrtcpudpsum}. K~dipozici je také graf \ref{chart:nftablesbondingfiltrtcpudpreal} zobrazující přenosovou a packetovou rychlost v~čase.


%===========================================


\vspace{4mm}

\section{Vyhodnocení výsledků z experimentálního pracoviště}

Z uvedeného je zřejmé, že většina nástrojů filtruje správně podle nastavených pravidel (jen při jednom testu PF\_RINGu prošlo pár nechtěných packetů, což je zvláštní, ale tak to vyhodnotil Spirent Avalanche 3100B).
K zahazování ostatního provozu docházelo u~všech testovaných firewallů -- u některých méně, u některých více. Pro lepší porovnání zkoušených nástrojů, bude rozumné si data z jednotlivých grafů zobrazit
do jednoho srovnávacího grafu.

Chceme-li porovnat výkonnost filtrů vůči sobě, dostaneme jedny z nejzajímavějších informací z testu, kdy bylo použito 100 bezvýznamných pravidel + filtrace TCP a UDP komunikací pro vybrané dvojice IP adres.
Graf \ref{chart:srovnanirychlostifiltracetcpudp} ukazuje srovnání přenosových rychlostí při zmíněném (bezstavovém) testu při vyšší rychlosti. Je vidět, že netmap potvrdil svůj dobrý výkon z předešlých testů,
a při této zkoušce dosáhl nejlepšího výsledku. Ačkoliv u nftables došlo v jednu chvíli k razantnímu poklesu přenosové rychlosti, přesto se jim podařilo dosáhnout druhé nejvyšší přenosové rychlosti.
Netfilter s \texttt{iptables} si také nevedl špatně, rozdíl proti nftables není tak velký. Nejhůře se v tomto testu projevil PF\_RING, který nedokázal netmapu konkurovat. Zajímavé je, že pořadí
nástrojů odpovídá pořadí začátků přenášení dat jednotlivými firewally. Netmap začal přenášet data ihned po 30. sekundě, kdežto PF\_RING až o několik sekund později. Netmap také jako jediný kopíroval
průběh generování dat, který byl nastaven na Avalanchi. Ostatní nástroje pokračovaly v přenášení dat i po 60. sekundě. Nejspíš je to z toho důvodu, že simulovaní uživatelé zanikaly pomaleji (protože
se data přenášely pomaleji), ovšem vytváření simulovaných uživatelů probíhalo podle předem daného průběhu. To by vysvětlovalo i pozvolný nárůst přenosových rychlostí v grafu.

\begin{chart}[ht]
	\begin{tikzpicture}
		\begin{axis}[trafficGraphSrov]
			\addplot[mark=+,color=red] coordinates {
(1,0)(2,0)(3,0)(4,0)(5,0)(6,0)(7,0)(8,0)(9,0)(10,0)(11,0)(12,0)(13,0)(14,0)(15,0)(16,0)(17,0)(18,0)(19,0)(20,0)(21,0)(22,0)(23,0)(24,0)(25,0)(26,0)(27,0)(28,0)(29,0)(30,0)(31,338)(32,628)(33,323649)(34,569849)(35,591767)(36,610034)(37,606152)(38,597690)(39,597522)(40,597626)(41,594984)(42,593531)(43,597583)(44,597714)(45,595811)(46,602800)(47,604124)(48,605805)(49,608440)(50,608532)(51,616426)(52,616892)(53,619349)(54,618167)(55,622923)(56,624042)(57,626931)(58,627371)(59,631451)(60,632866)(61,637589)(62,643913)(63,653355)(64,663127)(65,675924)(66,681491)(67,683833)
			};
			\addplot[mark=+,color=blue] coordinates {
(1,0)(2,0)(3,0)(4,0)(5,0)(6,0)(7,0)(8,0)(9,0)(10,0)(11,0)(12,0)(13,0)(14,0)(15,0)(16,0)(17,0)(18,0)(19,0)(20,0)(21,0)(22,0)(23,0)(24,0)(25,0)(26,0)(27,0)(28,0)(29,0)(30,0)(31,2013)(32,556814)(33,637325)(34,621928)(35,616383)(36,368419)(37,294167)(38,282431)(39,645323)(40,640639)(41,639938)(42,641196)(43,644658)(44,647067)(45,650134)(46,661075)(47,663580)(48,648201)(49,650558)(50,653254)(51,659698)(52,662217)(53,662216)(54,664245)(55,664240)(56,670556)(57,667431)(58,667665)(59,670212)(60,672916)(61,677586)(62,690122)(63,697013)(64,688063)(65,697826)(66,712146)(67,710254)
			};
			\addplot[mark=+,color=black] coordinates {
(1,0)(2,0)(3,0)(4,0)(5,0)(6,0)(7,0)(8,0)(9,0)(10,0)(11,0)(12,0)(13,0)(14,0)(15,0)(16,0)(17,0)(18,0)(19,0)(20,0)(21,0)(22,0)(23,0)(24,0)(25,0)(26,0)(27,0)(28,0)(29,0)(30,0)(31,4488)(32,8473)(33,7244)(34,9020)(35,68092)(36,459629)(37,451564)(38,459775)(39,463859)(40,466463)(41,469031)(42,475426)(43,474403)(44,481354)(45,485015)(46,488333)(47,492306)(48,496566)(49,498664)(50,503832)(51,504056)(52,509835)(53,512276)(54,515911)(55,517882)(56,524475)(57,523171)(58,526622)(59,528489)(60,533568)(61,536688)(62,545000)(63,548892)(64,557821)(65,565537)(66,574493)(67,578259)
			};
			\addplot[mark=+,color=orange] coordinates {
(1,0)(2,0)(3,0)(4,0)(5,0)(6,0)(7,0)(8,0)(9,0)(10,0)(11,0)(12,0)(13,0)(14,0)(15,0)(16,0)(17,0)(18,0)(19,0)(20,0)(21,0)(22,0)(23,0)(24,0)(25,0)(26,0)(27,0)(28,0)(29,0)(30,0)(31,471287)(32,516405)(33,516184)(34,778149)(35,768055)(36,772642)(37,770318)(38,772818)(39,770612)(40,770232)(41,770269)(42,771368)(43,771483)(44,772928)(45,768870)(46,771504)(47,772489)(48,771156)(49,772475)(50,768373)(51,772518)(52,771184)(53,771513)(54,772005)(55,767744)(56,771656)(57,771859)(58,771675)(59,772430)(60,768907)(61,722432)(62,640812)(63,557639)(64,431109)(65,269778)(66,145180)(67,94769)
			};
			\legend{{netfilter + \texttt{iptables}},nftables,PF\_RING,netmap}
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Srovnání přenosových rychlostí při bezstavovém testu \uv{Filtrace TCP/UDP} při vyšší přenosové rychlosti.}
	\label{chart:srovnanirychlostifiltracetcpudp}
\end{chart}

Také tabulka \ref{tab:tabulkafiltracetcpudp}, srovnávající naměřené hodnoty při uvedeném testu nástrojů, dokazuje výkonnostní pořadí z grafu \ref{chart:srovnanirychlostifiltracetcpudp}. Dobře
je to vidět například na procentuálním vyjádření neúspěšných transakcí -- zatímco při zkoušení netmapu bylo zahozeno jen 0,49 \% transakcí, u nftables to bylo už 3,60 \%, netfilter zahodil 8,49 \%
a při testování PF\_RINGu došlo dokonce k~12,58\% neúspěšnosti.

\vspace{2mm}

\begin{table}[ht]
	\centering
	\begin{tabular}{l|l||c|c|c|c}
		\multicolumn{2}{l||}{Název údaje} & \shortstack[l]{netfilter\\+ \texttt{iptables}} & nftables & PF\_RING & netmap \\
		\hline
		\hline
		\multicolumn{2}{l||}{Celkem vyzkoušených transakcí} & 2 197 419 & 2 350 233 & 1 719 504 & 2 579 755 \\
		\hline
		\multicolumn{2}{l||}{Úspěšných transakcí} & 2 010 784 & 2 265 541 & 1 503 233 & 2 567 057 \\
		\multicolumn{2}{l||}{Neúspěšných transakcí} & 186 635 & 84 692 & 216 271 & 12 698 \\
		\multicolumn{2}{l||}{Podíl úspěšných transakcí (\%)} & 91,51 & 96,40 & 87,42 & 99,51 \\
		\multicolumn{2}{l||}{Podíl neúspěšných transakcí (\%)} & 8,49 & 3,60 & 12,58 & 0,49 \\
		\hline
		\multirow{3}{*}{\shortstack[c]{Přenosová rychlost\\(Mbit/s)}} & minimální & 0,338  & 2,01  & 4,49  & 471,29  \\
		& maximální & 632,87  & 672,92  & 533,57  & 778,15  \\
		& průměrná  & 558,03  & 594,22  & 415,33  & 744,30  \\
		\hline
		\multirow{3}{*}{\shortstack[c]{Packetová rychlost\\(packet/s)}} & minimální & 661 & 1 539 & 2 270 & 55 353 \\
		& maximální & 73 077 & 74 953 & 60 184 & 88 166 \\
		& průměrná  & 65 168 & 66 865 & 47 860 & 84 418 \\
	\end{tabular}
	\vspace{6mm}
	\caption{Srovnávací tabulka statistických údajů pro graf \ref{chart:srovnanirychlostifiltracetcpudp}. Jedná se o měření s~filtrací, proto je určitý počet neúspěšných transakcí v pořádku. Informace jsou počítány z~hodnot od 30. do 60. sekundy.}
	\label{tab:tabulkafiltracetcpudp}
\end{table}

\vspace{2mm}

Agregace síťových rozhraní není ve speciálních filtračních nástrojích příliš podporována. Firewally, které využívají síťového zásobníku linuxového jádra, nemusejí tuto funkcionalitu zvlášť implementovat,
protože pro Linux již řešení umožňující seskupovat síťová rozhraní existují. V~opačném případě je nutné, aby byla tato funkce speciálně implementována, což se ale spíše neděje.

Stejně jako v předchozím případě, i pro srovnání testů při linkové agregaci je nejzajímavější porovnání grafů při bezstavovém měření \uv{Filtrace TCP/UDP} při vyšší přenosové rychlosti.
Z grafu \ref{chart:srovnanibonding} vyplývá, že při agregaci nejsou nftables tak výkonné jako netfilter s \texttt{iptables}. Netfilter dosáhl průměrně o cca 200 Mbit/s více než nftables.


\begin{chart}[ht]
	\begin{tikzpicture}
		\begin{axis}[trafficGraphSrov]
			\addplot[mark=+,color=red] coordinates {
(1,0)(2,0)(3,0)(4,0)(5,0)(6,0)(7,0)(8,0)(9,0)(10,0)(11,0)(12,0)(13,0)(14,0)(15,0)(16,0)(17,0)(18,0)(19,0)(20,0)(21,0)(22,0)(23,0)(24,0)(25,0)(26,0)(27,0)(28,0)(29,0)(30,0)(31,552109)(32,985314)(33,978437)(34,976742)(35,955870)(36,940681)(37,951418)(38,946571)(39,984843)(40,977984)(41,1014431)(42,1009297)(43,988631)(44,1015372)(45,978406)(46,983139)(47,982662)(48,990156)(49,977621)(50,975543)(51,986161)(52,967936)(53,990527)(54,972363)(55,994545)(56,984306)(57,979204)(58,959029)(59,994453)(60,976340)(61,900964)(62,807050)(63,798544)(64,808224)(65,775306)(66,786113)(67,252087)
			};
			\addplot[mark=+,color=blue] coordinates {
(1,0)(2,0)(3,0)(4,0)(5,0)(6,0)(7,0)(8,0)(9,0)(10,0)(11,0)(12,0)(13,0)(14,0)(15,0)(16,0)(17,0)(18,0)(19,0)(20,0)(21,0)(22,0)(23,0)(24,0)(25,0)(26,0)(27,0)(28,0)(29,0)(30,0)(31,844438)(32,838547)(33,828949)(34,824300)(35,831753)(36,814549)(37,815398)(38,818289)(39,811019)(40,831310)(41,830359)(42,828343)(43,820092)(44,824423)(45,819174)(46,826038)(47,832914)(48,817094)(49,822826)(50,826722)(51,818072)(52,820775)(53,812927)(54,819247)(55,819574)(56,817600)(57,821833)(58,818619)(59,817500)(60,824801)(61,801084)(62,791087)(63,796876)(64,794528)(65,792998)(66,808572)(67,240101)
			};
			\legend{netfilter,nftables}
		\end{axis}
	\end{tikzpicture}
	\vspace{6mm}
	\caption{Srovnání přenosových rychlostí při bezstavovém testu \uv{Filtrace TCP/UDP} při vyšší přenosové rychlosti s agregovanými linkami.}
	\label{chart:srovnanibonding}
\end{chart}

V tabulce \ref{tab:tabulkafiltracetcpudp2} jsou shrnuty různé statistické hodnoty, získané při výše uvedeném měření s agregací linek. Jak je vidět na většině hodnot, vedl si netfilter v tomto případě opravdu lépe --
pro příklad lze uvést, že při zkoušení netfilteru bylo vyzkoušeno o cca 65 000 transakcí více než v~případě nftables.

\begin{table}[ht]
	\centering
	\begin{tabular}{l|l||c|c}
		\multicolumn{2}{l||}{Název údaje} & \shortstack[l]{netfilter\\+ \texttt{iptables}} & nftables \\
		\hline
		\hline
		\multicolumn{2}{l||}{Celkem vyzkoušených transakcí} & 300 377 & 235 699 \\
		\hline
		\multicolumn{2}{l||}{Úspěšných transakcí} & 299 477 & 234 816 \\
		\multicolumn{2}{l||}{Neúspěšných transakcí} & 900 & 883 \\
		\multicolumn{2}{l||}{Podíl úspěšných transakcí (\%)} & 99,70 & 99,63 \\
		\multicolumn{2}{l||}{Podíl neúspěšných transakcí (\%)} & 0,30 & 0,37 \\
		\hline
		\multirow{3}{*}{\shortstack[c]{Přenosová rychlost\\(Mbit/s)}} & minimální & 98,77 & 240,10 \\
		& maximální & 1 190,00 & 844,44 \\
		& průměrná & 1 030,00 & 803,32 \\
		\hline
		\multirow{3}{*}{\shortstack[c]{Packetová rychlost\\(packet/s)}} & minimální & 8 250 & 20 347 \\
		& maximální & 100 613 & 70 991 \\
		& průměrná & 86 904 & 68 043 \\
	\end{tabular}
	\vspace{6mm}
	\caption{Srovnávací tabulka statistických údajů pro graf \ref{chart:srovnanibonding}.}
	\label{tab:tabulkafiltracetcpudp2}
\end{table}


\section{Celkové zhodnocení}

Jak je možné ze všech předchozích odstavců a výsledků vytušit, univerzální a dokonalý nástroj pro vysokorychlostní filtrování síťového provozu na běžně dostupném hardwaru a softwaru zřejmě neexistuje.
Každý ze zkoušených nástrojů má svá pro a proti, a pro každý jednotlivý případ použití je v~současné době potřeba vyhodnotit, který nástroj bude vhodnější použít. Netfilter s~\texttt{iptables} například implementují
velké množství funkcí včetně stavové filtrace a agregace síťových rozhraní. Ovšem jak bylo ukázáno v~předchozím textu, při vyšších přenosových rychlostech se již projevuje menší výkonnost oproti speciálním
nástrojům jako je netmap (s upravenými ovladači NIC). Ten ovšem zase nepodporuje funkce, které by mohly být v~určitých situacích přínosné, a je možné jej využít víceméně pouze k~bezstavové filtraci a tvarování provozu.
Určitým kompromisem mohou být nftables, které sice také (zřejmě zatím) nepodporují hlídání stavu spojení, ovšem díky podpoře linuxového jádra, umožňují alespoň agregaci síťových rozhraní. Také bylo ukázáno, že jsou nftables
výkonnější než netfilter s~\texttt{iptables} a do budoucna rozhodně perspektivnější. Ukázková aplikace PF\_RINGu, umožňující přemostění dvou rozhraní a filtraci, je opravdu spíše na ukázku možností frameworku PF\_RING než na seriózní použití,
a proto se nedá očekávat bohatá funkcionalita. Tabulka \ref{tab:tabulkafunkci} obsahuje shrnutí vlastností a funkcí, které byly o~filtrovacích nástrojích zjištěny v~průběhu zpracovávání této práce.

{\renewcommand{\arraystretch}{1.3}
\begin{table}[H]
	\centering
	\begin{tabular}{l||c|c|c|c}
		Funkce, vlastnost & \rot{\shortstack[l]{netfilter\\+ \texttt{iptables}}} & \rot{nftables} & \rot{PF\_RING} & \rot{netmap} \\
		\hline
		\hline
		Bezstavová filtrace & \OK & \OK & \OK & \OK \\
		\hline
		Stavová filtrace & \OK & \NOK & \NOK & \NOK\footnotemark[1] \\
		\hline
		Podpora 10 Gbit/s & \NOK & \NOK & \NOK\footnotemark[4] & \OK \\
		\hline
		Změna pravidel za běhu & \OK & \OK & \NOK & \OK \\
		\hline
		Agregace síťových rozhraní & \OK & \OK & \NOK & \NOK \\
		\hline
		Podpora IPv6\footnotemark[3] & \OK & \OK & \OK & \NOK\footnotemark[2] \\
		\hline
		Tvarování provozu\footnotemark[3] & \OK & \OK & \NOK & \OK \\
	\end{tabular}
	\vspace{6mm}
	\caption{Tabulka vlastností a funkcí zkoušených nástrojů.}
	\label{tab:tabulkafunkci}
\end{table}}

\footnotetext[1]{Nástroj umožňuje použít příkaz s~touto funkcí, ovšem funkce se na provoz neaplikuje.}
\footnotetext[2]{Nápověda nástroje tuto funkci obsahuje, ovšem po zadání příkazu se vypíše chyba.}
\footnotetext[3]{Netestováno na procházejícím provozu.}
\footnotetext[4]{Testovaná nelicencovaná verze.}

