Compare commits

...

10 Commits

Author SHA1 Message Date
c9015084a2 Vizuální úprava 2024-11-27 10:36:46 +01:00
d27ddc6e3d Oprava překlepů 2024-11-27 10:22:01 +01:00
048dc7aaff vyber softwaru pro sitove prvky 2024-11-27 10:00:29 +01:00
305ee0c918 add 802.1X 2024-11-26 13:29:32 +01:00
9baab5be9d pridani sekcí 2024-11-26 09:37:56 +01:00
ea43037ec3 Přidání subsekce kompilace 2024-11-14 02:07:33 +01:00
0c15643108 update ucidefaults.sh 2024-11-13 04:34:22 +01:00
cb3fd8f157 vymazani nepotrebnych souboru 2024-01-20 05:09:09 +01:00
ff6d641073 Přidána struktura práce v úvodu 2024-01-19 22:32:21 +01:00
9798b06ab7 Přidán abstrakt 2024-01-19 22:31:32 +01:00
30 changed files with 1259 additions and 98 deletions

View File

@@ -3,7 +3,7 @@ PRACE=prace.tex
all: vlna pdf
pdf:
latexmk -pdflua $(PRACE)
latexmk -pdflua -halt-on-error $(PRACE)
#latexmk -pdf $(PRACE)
clean:

Binary file not shown.

View File

@@ -4,7 +4,7 @@
{\Large\bfseries Abstrakt}
Text abstraktu napsán v~češtině.
Tato bakalářská práce se zabývá automatizovaným nasazením, správou a monitoringem rozsáhlých Wi-Fi sítí. Uvádí základní pojmy z~počítačových sítí v~kontextu autorizace uživatelů a přístupových Wi-Fi síťí. Popisuje sadu standardů Wi-Fi, jednotlivé standardy a autorizační metody. Následně je pomocí vybraného open-source softwaru implementována modelová přístupová Wi-Fi síť na základě deklarovaných požadavků. Tato modelová implementace je v~závěru vyhodnocena.
\vspace{4mm}
@@ -18,7 +18,7 @@ Klíčová, slova, oddělená, čárkou
{\Large\bfseries Abstract}
Abstract written in English.
This bachelor thesis deals with automated deployment, management and monitoring of large-scale Wi-Fi networks. It introduces basic concepts from computer networks in the context of user authorization and Wi-Fi access networks. It describes a set of Wi-Fi standards, individual standards and authorization methods. Subsequently, a model Wi-Fi access network is implemented using selected open-source software based on the declared requirements. This model implementation is evaluated at the end.
\vspace{4mm}

28
ansibleTree.txt Normal file
View File

@@ -0,0 +1,28 @@
$ tree -L 2 --dirsfirst apEduroam
.
+-- group_vars
|   +-- accessPoints.yml
|   +-- dsa.yml
|   +-- openwrt.yml
|   \-- swconfig.yml
+-- host_vars
|   +-- ap_0c806307e88a.yml
|   +-- ap_107c61992bd8.yml
|   +-- ap_b04e26bbc7e3.yml
|   +-- ap_c47154391634.yml
|   \-- ap_c47154393f26.yml
+-- include
|   \-- createHostVars.yml
+-- roles
|   +-- gekmihesg.openwrt
|   +-- network
|   +-- system
|   \-- wireless
+-- templates
|   \-- host_vars.j2
+-- addNewAPs.yml
+-- ansible.cfg
+-- debug.yml
+-- inventory.yml
+-- reboot.yml
\-- setupAPs.yml

View File

@@ -5,3 +5,207 @@
title = "CommonMark Spec",
year = "2019"
}
@book{Peterson_Davie_2022,
place={Cambridge, MA},
title={Computer Networks: A Systems Approach},
publisher={Morgan Kaufmann Publishers, an imprint of Elsevier, ISBN: 978-0-1238-5059-1},
author={Peterson, Larry L. and Davie, Bruce S.},
year={2022}
}
@book{Nemeth_Evi_2008,
place={Brno},
title={Linux : kompletní příručka administrátora },
publisher={Computer Press, ISBN: 978-80-251-2410-9},
author={Nemeth Evi, Snyder Garth, Hein Trent R.},
year={2008}
}
@book{Nemeth_Evi_2018,
place={Boston},
title={Unix and Linux system administration handbook},
publisher={Addison-Wesley, ISBN: 978-01-342-7755-4 },
author={Nemeth Evi, Snyder Garth, Hein Trent R.},
year={2018}
}
@online{mozttfb,
author = "Hoffman, Billy",
date = "2013-09-26",
url = "https://moz.com/blog/improving-search-rank-by-optimizing-your-time-to-first-byte",
cited = "2020-02-12",
title = "Improving Search Rank by Optimizing Your Time to First Byte",
year = "2013"
}
@misc{Zak_El_Kom,
author = "Česko",
title = "§ 97 odst. 3 zákona č. 127/2005 Sb., o elektronických komunikacích a o změně některých souvisejících zákonů (zákon o elektronických komunikacích) - znění od~1.~1.~2024.",
url = "https://www.zakonyprolidi.cz/cs/2005-127#p97-3",
}
@online{OpenWrtDocFAQ,
author = {Project OpenWrt},
title = {FAQ before installing OpenWrt},
year = {2021},
url = {https://openwrt.org/docs/guide-user/installation/before.installation#what_is_the_difference_between_the_different_image_formats},
urldate = {2024-07-03}
}
@online{OpenWrtDoc8021X,
author = {Project OpenWrt},
title = {Introduction to 802.1X},
year = {2024},
url = {https://openwrt.org/docs/guide-user/network/wifi/wireless.security.8021x},
urldate = {2024-11-10}
}
@online{LinuxDSA,
author = {kernel.org},
title = {Distributed Switch Architecture (DSA)},
url = {https://docs.kernel.org/networking/dsa/dsa.html},
urldate = {2024-10-09}
}
@online{leanDeliveryIaC,
author = {Aliaksei Maiseyeu},
title = {Dawn of the Infrastructure as Code},
url = {https://lean-delivery.com/2019/12/infrastructure_as_code.html},
year={2019}
}
@online{JetPatch,
author = {Ali Raza},
title = {Puppet vs Chef vs Ansible vs SaltStack},
url = {https://jetpatch.com/blog/agent-management/puppet-vs-chef-vs-ansible-vs-saltstack/},
year={2016}
}
@book{HeapAnsible,
place={Berkley, CA},
title={Ansible: From beginner to pro},
publisher={Apress, ISBN: 978-1-4842-1659-0},
author={Michael Heap},
year={2016}
}
@online{ZenofAnsible,
author = {Timothy Appnel},
title = {The Zen of Ansible},
url = {https://www.ansible.com/blog/the-zen-of-ansible/},
year = {2023}
}
@online{RamsTech,
author = {Ram},
title = {Monitoring and Visualization Options for OpenWRT},
url = {https://nramkumar.org/tech/blog/2024/06/21/monitoring-and-visualization-options-for-openwrt/},
year = {2024}
}
@report{Hofstede2014,
author = {R. Hofstede and P. Čeleda and B. Trammell and I. Drago and R. Sadre and A. Sperotto and A. Pras},
title = {Flow monitoring explained: from packet capture to data analysis with NetFlow and IPFIX, doi: 10.1109/COMST.2014.2321898},
institution = {IEEE communications surveys & tutorials},
year = {2014},
doi = {10.1109/COMST.2014.2321898}
}
@misc{openwrtAPK,
title = {Major Change Notice: New Package Manager},
date = {2024-11-15},
author = {Sherman},
url = {https://forum.openwrt.org/t/major-change-notice-new-package-manager/215682},
year = {2024}
}
@online{peterka_tcpip,
author = {Jiří Peterka},
title = {Síťový model TCP/IP},
url = {https://www.earchiv.cz/a92/a231c110.php3},
year = {1992}
}
@online{wiki_tcpip,
author = {Wikipedie},
title = {TCP/IP},
url = {https://cs.wikipedia.org/wiki/TCP/IP},
year = {2008}
}
@online{samuraj_csma,
author = {Petr Bouška},
title = {Ethernet - CSMA/CD, kolizní doména, duplex},
url = {https://www.samuraj-cz.com/clanek/ethernet-csma-cd-kolizni-domena-duplex/},
year = {2007}
}
@online{samuraj_ethernet,
author = {Petr Bouška},
title = {TCP/IP a ethernet - cesta v síti, aktivní síťové prvky},
url = {https://www.samuraj-cz.com/clanek/tcp-ip-a-ethernet-cesta-v-siti-aktivni-sitove-prvky/},
year = {2007}
}
@online{samuraj_vlan,
author = {Petr Bouška},
title = {VLAN - Virtual Local Area Network},
url = {https://www.samuraj-cz.com/clanek/vlan-virtual-local-area-network/},
year = {2007}
}
@online{freeccna_vlan,
author = {FreeCCNAStudyGuide.com},
title = {7-4 VLAN Trunking: ISL and 802.1Q},
url = {https://www.freeccnastudyguide.com/study-guides/ccna/ch7/7-4-vlan-trunking-isl-802-1q/},
urldate = {2024-9-21}
}
@online{ieee_8023,
author = {IEEE},
title = {802.3-2018 - IEEE Standard for Ethernet},
url = {https://ieeexplore.ieee.org/document/8457469},
year = {2018}
}
@online{ijs2_ethernet,
title = {Ethernet},
url = {http://ijs2.8u.cz/index.php?option=com_content&view=article&id=20&Itemid=125},
urldate = {2024-9-21}
}
@online{fair_vlan,
author = {Gorry Fairhurst},
title = {Advanced VLANs},
url = {https://erg.abdn.ac.uk/users/gorry/course/lan-pages/vlan-advanced.html},
year = {2012}
}
@online{stankus_8021x,
author = {Martin Stankuš},
title = {Autentizace, autorizace a accounting v prostředí IEEE 802.1X},
url = {http://www.cs.vsb.cz/grygarek/SPS/projekty0607/RADIUS-Stankus.pdf},
year = {2007}
}
@online{networkencyclopedia_eap,
author = {networkencyclopedia.com},
title = {Decoding EAP Protocol: A Guide to Extensible Authentication},
url = {https://networkencyclopedia.com/decoding-eap-protocol-a-guide-to-extensible-authentication/},
year = {2024}
}
@online{eduroam_realm,
author = {eduroam.cz},
title = {Realm},
url = {https://www.eduroam.cz/cs/spravce/pripojovani/realm},
year = {2019}
}
@online{eduroam_certifikaty,
author = {eduroam.cz},
title = {Certifikaty},
url = {https://www.eduroam.cz/cs/spravce/pripojovani/serverove_certifikaty},
year = {2024}
}
@online{cuhel_8021x,
author = {Radim Čuhel},
title = {Řízení přístupu k lokální síti pomocí protokolu IEEE 802.1x},
url = {https://www.vut.cz/www_base/zav_prace_soubor_verejne.php?file_id=210204},
year = {2020}
}
@online{lesek_8021x,
author = {Vladimír Lešek},
title = {Autentizace v lokálních sítích pomocí IEEE 802.1x},
url = {https://dspace.cvut.cz/bitstream/handle/10467/82727/F3-BP-2019-Lesek-Vladimir-Autentizace%20v%20lokalnich%20sitich%20pomoci%20IEEE%20802.1x.pdf?sequence=-1&isAllowed=y},
year = {2019}
}
@online{crowder_firmwarecomp,
author = {Crystal Crowder},
title = {DD-WRT vs. Tomato vs. OpenWRT: Which Router Firmware Is the Best?},
url = {https://www.maketecheasier.com/dd-wrt-vs-tomato-vs-openwrt-router-firmware/},
year = {2023}
}
@online{twain_compare,
author = {Kurt Twain},
title = {DD-WRT vs OpenWrt: The Better Router Firmware in 2024?},
url = {https://www.homeowner.com/connectivity/routers/dd-wrt-vs-openwrt},
year = {2024}
}

View File

@@ -1,6 +1,10 @@
\chapter{Dostupný hardware}
\chapter{Dostupný hardware pro Wi-Fi sítě}
...
Na trhu je nepřeberné množství různých Wi-Fi zařízení. Pro budování wi-fi sítě se používají zařízení s~označením Wi-Fi router nebo Wi-Fi access point (přístupový bod). Wi-fi access point je zařízení jednodužší, slouží k~převodu signálu kabelového média na signál bezdrátový, vysílá a příjíma radiofrekvenční signál a vytváří tak Wi-Fi síť pro připojení bezdrátových zařízení. Pracuje s~vrstvou L2 modelu TCP/IP a předává tak rámce mezi kabelovou sítí a bezdrátovou.
slouží Jedná se o~zařízení kombinující vícero funkcí. Tyto wifi routery v~principu obsahují velice podobné součástky. tyto wifi routery naplňují specifikace Von Neumannova schématu.
Konkrétněji lze demonstrovat hardware na příkladu routeru, který navrhl openwrt ke svému 20 vyročí.... tento hardware obsahuje procesor archytektury, paměť, wifi radio, switch chip
\subsection{Požadavky na hardware}

View File

@@ -1,19 +1,331 @@
\chapter{Implementace modelové přístupové Wi-Fi sítě}
\label{ch:implemetace}
Sekce popisuje konfiguraci síťových zařízení a dalších softwarových komponent nutných pro fungování modelové implementace dle definovaných požadavků.
Zejména se zaměřuje na konfiguraci přístupových bodů (access pointů) sítě a možnosti získání potřebných dat pro monitoring. Dále popisuje konfiguraci centrální autentizace a autorizace s~integrací do sítě eduroam.
% ==================================================================================================================
\section{Síťové prostředí}
\label{sec:sitoveProstredi}
% ==================================================================================================================
\section{Výběr softwaru pro síťové prvky}
Na trhu je omezené množství přístupových bodů, které používají open-source systémy. Přesto je většina přístupových bodů různých výrobců postavena na standardním hardwaru, pro který jde zkompilovat operační systém Linux. Tento fakt umožňuje využití existujících open-source projektů, které nabízejí operační systémy fungující na těchto typech zařízení.
Pro zajištění co největší kompatibility s~přístupovými body různých výrobců je v~modelové implementaci nezbytné nahradit jejich proprietární systém open-source alternativou. Tento přístup rovněž odpovídá cílům práce, která si klade za úkol implementovat přístupovou Wi-Fi síť výhradně s~využitím open-source technologií.
Open-source systém má i své výhody. Open-source systém je zejména podporován komunitou i po ukončení oficiální podpory výrobce zařízení, což zvyšuje bezpečnost a odolnost vůči novým zranitelnostm. Také mnohdy rozšiřuje funkce zařízení nad rámec toho, co je běžně poskytováno výrobcem. \citep{crowder_firmwarecomp}
Nejznámnější projekty:
\begin{itemize}
\item \textbf{DD-WRT}: Nabízí kompatibilitu s~mnoha zařízeními - obsahuje velké množství ovladačů. Je dobře optimalizovaný a poskytuje mnoho pokročilých funkcí. Aktualizace nevycházejí tak často.
\item \textbf{OpenWrt}: Nabízí velké množství rozšíření v~podobě balíčků. Podporuje velké množství zařízení. Má velkou komunitu vývojářu - pravidelně vycházejí aktualizace. Kromě webového rozhraní nabízí i příkazový systém \verb|uci| pro síťovou konfiguraci pomocí příkazové řádky. Nabízí pouze free a open-source síťové ovladače a má složitější webové rozhraní. \citep{twain_compare}
\item \textbf{Tomato}: - Jednoduchý stabilní systém pro zařízení s~wifi chipy od firmy Broadcom - podporuje méně modelů. Má velmi přehledné webové rozhraní. Nenabízí velké možnosti přizpůsobení. Má menší komunitu vývojářů - aktualizace nevycházejí příliš často.
\end{itemize}
Z~vybraných systémů jsem zvolil systém \textbf{OpenWrt} pro jeho širokou komunitu vývojářů, obsáhlé repozitáře doplňkového softwaru, flexibilitě konfigurace a možnosti konfigurace pomocí nástroj \verb|uci|.
% ==================================================================================================================
\section{Příprava zařízení}
Přístupový bod od výroby obsahuje proprietární operační systém výrobce zřízení. Tento operační systém je nutné nahradit vybraným operačním systémem OpenWrt. Náhrada probíhá přepsáním původního obsahu paměti zařízení systémem OpenWrt.
% ------------------------------------------------------------------------------------------------------------------
\subsection{Kompilace a sestavenení OpenWrt}
\label{subsec:kompilace}
Vývojáři systému openwrt nabízejí dvě možností jak získat obraz systému, který se nahraje do paměti zařízení.
První možností je stáhnout již předkompilovaný a sestavený obraz systému openwrt pro dané zařízení. Tento předkompilovaný a sestavený systém obsahuje software pro provoz síťového zařízení v~režimu routeru/Wi-Fi routeru (obsahuje firewall a dhcp servery). Tato možnost je pro uživatele jednoduchou cestou jak získat openwrt pro své zařízení, neumožňuje však úpravy samotného systému a změny nastavení, které by se aplikovali před prvním spuštěním.
Jedním z~požadavků modelové implementace je centrální management síťových prvků. K~naplnění tohoto cíle je nutné mít nové zařízení po prvním zapnutí již integrované do existující sítě, tak aby bylo možné k~němu přistoupit a provést dodatečnou konfiguraci pomocí nástroje pro hromadnou správu zařízení.
Z~tohoto důvodu je vhodné zvolit druhou možnost jak získat systém OpenWrt a to zkompilovat a sestavit svůj vlastní obraz systému OpenWrt. Takto lze zakomponovat úpravy systému do obrazu systému a poté je nahrát do paměti zařízení i s~požadovanou inicializační konfigurací. Další výhodou je to, že můžeme systém OpenWrt sestavit bez zbytného softwaru pro účely přístupového bodu a ušetřit tím místo v~paměti zařízení.
Zkompilovat a sestavit vlastní obraz systému openwrt je možné na lokálním počítači po naklonování repozitáře OpenWrt nebo si lze nechat zkompilovat a sestavit obraz OpenWrt na serverech samotného projetku. Pro účely této práce využijeme možnosti sestavení systému na serverech OpenWrt. Tato možnost umožňuje provést potřebné úpravy před sestavením obrazu systému. Vyhneme se tak potřebě vytvoření prostředí pro křížovou\footnote{též cross kompilace - proces vytvoření spustitelného kódu pro jinou instrukční sadu procesoru než na jaké se kód kompiluje} kompilaci a sestavení obrazu OpenWrt na vlastním počítači.
Webová aplikace \url{https://firmware-selector.openwrt.org/} umožnuje získat již předkompilované obrazy systému OpenWrt i možnost vytvořit si obraz vlastní.
Obrazy systému OpenWrt jsou pro různé zařízení unikátní, protože různé zařízení využívají různé procesorové architektury, mají různé rozložení paměti a obsahují různé periferie pro které je nutné mít adekvátní ovladače. V~první části je nutné vybrat model zařízení pro který chceme získat obraz systému OpenWrt. Následně vybereme verzi systému OpenWrt, kterou chceme získat.
Aplikace standardně ve spodní části stránky nabízí ke stažení tři druhy předkompilovaných obrazů. První je samotné jádro operačního systému - kernel. Další možnosti jsou factory obraz a sysupgrade obraz. Oba obrazy obsahují stejný systém s~tím rozdílem, že factory obraz je doplněný o~hlavičky a scripty pro interakci s~továrním softwarem zařízení, tak aby tento obraz akceptovaly proprietární nástroje výrobce zařízení pro upgrade firmwaru (zapsání obrazu do paměti zařízení). Factory obraze je tedy úrčený pro prvnotní insalaci OpenWrt, sysupgrade obraz slouží k~aktualizaci systému z~již funkčního systému OpenWrt.\citep{OpenWrtDocFAQ}
Po rozkliknutí sekce \verb|Customize installed packages and/or first boot script| můžeme definovat jaké balíčky budou zakomponovány do vytvořeného obrazu systému a jaká se provede inicializační konfigurace. Tlačítkem \verb|Request build| zahájíme sestavení vlastního obrazu OpenWrt, který si následně stáhneme.
Ve vstupu \verb|Installed Packages| jsou předvyplněny softwarové balíčky pro konkrétní zařízení, se kterými se sestaví systém OpenWrt. V~tomto seznamu jsou zahrnuty i balíčky nepotřebné pro funkci zařízení v~režimu přístupového bodu. Systém sestavíme bez těchto balíčků.
Seznam balíků, které nejsou potřeba pro provoz zařízení v~režimu přístupového bodu:
\begin{itemize}
\item \verb|dnsmasq| - DNS a DHCPv4 server,
\item \verb|firewall4| - překladač uci pravidel firewallu na nftables pravidla,
\item \verb|kmod-nft-offload| - kernel modul pro podporu harwarové akcelerace routování a NATu,
\item \verb|luci| - webové rozhraní pro konfiguraci zařízení,
\item \verb|nftables| - framework pro filtrování paketů a další práci se síťovým provozem,
\item \verb|odhcpd-ipv6only| - démon pro správu IPv6 v~síti,
\item \verb|ppp| - podpora Point-to-Point protokolu,
\item \verb|ppp-mod-pppoe| - rozšíření o~podporu PPPoE funkcionality.
\end{itemize}
Protože budeme dle definovaných požadavků v~kapitole \ref{ch:pozadavky} používat k~autentizaci a autorizaci WPA enterprise nahradíme balík \verb|wpad-basic-mbedtls| za jeho plnohodnotnou alternativu \verb|wpad-mbedtls|, který mimo jiné implementuje WPA-enterprise metody pro autorizaci a autentizací clientů.
Balíky lze odebrat připsáním názvů balíků s~prefixem \verb|-|. Tedy: \texttt{-dnsmasq -firewall4 -kmod-nft-offload -luci -nftables -odhcpd-ipv6only -ppp -ppp-mod-pppoe -wpad-basic-mbedtls wpad-mbedtls}
Do vstupu \verb|Script to run on first boot (uci-defaults)| zadáme ash unix shell script, který provede konfiguraci systému při prvním spuštění.
\lstinputlisting[caption={Script spouštěný při prvním bootu (uci-defaults.sh)}, language=bash,]{ucidefaults.sh}
Tento script odstraní výchozí síťové nastavení systému OpenWrt. Ze souboru \verb|/etc/board.json| (popis výchozí konfigurace pro dané zařízení) zjistí původní WAN port zařízení a nad ním vytvoří nové síťové rozhraní s~vlan tagem \verb|99| pro příchozí i odchozí provoz. DHCP client na tomto novém rozhraní požádá o~přidělení IP adresy. Toto síťové rozhraní bude jediné síťové rozhraní kterému bude přidělena IP adresa. Bude sloužit pro management přístupového bodu.
Script detekuje, zda dané zařízení obsahuje switch a rozpozná jestli je spravován pomocí DSA nebo nástrojem \verb|swconfig|. DSA nebo-li Distributed Switch Architecture je subsystém Linuxového jádra pro unifikovanou správu specifických embedded switchů. Vytváří virtuální síťová rozhraní pro každý port switche, což umožňuje jejich správu standardními Linuxovými nástroji. \citep{LinuxDSA} U~DSA switche si s~nastavením VLAN tagování provozu poradí OpenWrt při vytváření síťového rozhraní pro management, zatímco switch spravovaný nástrojem \verb|swconfig| je nutné ještě nakonfigurovat tak, aby na původním WAN portu switche přijímal a odesílal rámce s~VLAN tagem 99 a tyto rámce přeposílal z~portu a na port switche připojený na ethernetové rozhraní CPU přístupového bodu také s~VLAN tagem 99.
Script dále provede změnu root hesla, které je definováno na začátku scriptu v~proměnné \verb|root_password| a bezpečnostní nastavení SSH démona s~přidáním SSH klíče z~proměnné \verb|ssh_key_rsa|. SSH démon není pro některé architektůry kompilován s~podporou novějších typů klíčů, proto doporučuji preferovat klíč typu RSA.
% ------------------------------------------------------------------------------------------------------------------
\subsection{Nahrání systému do paměti zařízení}
Proces nahrání obrazu systému OpenWrt je u~různých výrobců zařízení různý. Na většinu zařízení lze nahrát factory obraz systému OpenWrt bez potíží pomocí nástroje pro upgrade firmwaru přes webové rozhraní továrního systému. Některé zařízení mohou vyžadovat složitější postup. Je doporučeno seznámit se s~posupem instalace OpenWrt v~dokumentaci k~danému zařízení na stránkách projektu OpenWrt.
Tímto jsme získali přístupový bod s~opensource systémem OpenWrt se síťovým přístupem připravený pro následnou konfiguraci dalšími nástroji.
% ==================================================================================================================
\section{Konfigurace a správa přístupových bodů}
Tabulka \ref{tab:DevOpsTools} poskytuje přehled a porovnává vybrané nástroje pro správu konfigurace.
Výběr nástroje pro správu konfigurace přístupových bodů sekce se musí řídit jejich možnostmi.
Přístupové body jsou limitovýny svými hardwarovými prostředky, proto je vhodné preferovat nástroje, které nevyžadují instalaci agenta, aby nedocházelo k~využívání omezeného interního uložiště a operační paměti.
Dalším zohledněným kritériem pro výběr nástroje je jazyk zápisu konfigurace. Zde preferuji zápis konfigurace v~jazyce YAML pro jeho jednoduchost oproti specifické syntaxi nástroje Puppet. Jazykem YAMl se zapisují strukturované data podobně jako v~JSONu. Jazyk YAML je obecně známý pro svou dobrou čitelnot a intuitivní zápis, což zjednodušuje čtení i úpravy konfigurací.
Zbylé nástroje Ansible a SaltStack využívají pro zápis konfigurace jazyk YAML a konfigurují zařízení pomocí SSH. Přesto, že fungují bez potřeby agenta většina jejich modulů vyžaduje instalaci pythonu\footnote{\url{https://docs.saltproject.io/en/latest/topics/ssh/index.html}}\footnote{\url{https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html\#managed-node-requirements}} na spravovaných zařízeních, což může být opět problematické pro přístupové body vzhledem k~jejichi omezené interní paměti (instalace Python se svými závislostmi může na systému Openwrt vyžadovat přes 9 MiB interní paměti). Z~tohoto důvodu musím vybrat nástroj \textbf{Ansible} pro jeho širokou komunitní podporu a zejména existenci projektu \verb|ansible-openwrt|\footnote{\url{https://github.com/gekmihesg/ansible-openwrt}}, jenž přepisuje příkazy některých modulů Ansiblu vyžadující python interpreter za jejich alternativy interpretované v~unixovém příkazovém procesoru a obsahuje modul uci pro konfiguraci OpenWrt.
\textbf{Ansible} je nástroj pro automatizaci konfigurace, správy a nasazení aplikací. Pro zápis požadované konfigurace lze kombinovat imperativní i deklarativní způsob. Možnosti deklarativní konfigurace jsou omezeny schopnostmi ansiblu. Je doporučeno upřednosťnovat deklarativní způsob zápisu konfigurace a k~imperativnímu přistoupit až v~momentu kdy jsme omezeni schopnostmi ansiblu. \citep{ZenofAnsible}
\textbf{Ansible} se skládá z~těchto komponent:
\begin{itemize}
\item \textbf{Playbook}: Soubor, který obsahuje definice úkolů, které mají být vykonány na cílových zařízeních, nebo skupinách cílových zařízení. Mohou obsahovat podmínky, či volání jiných playbooků. Playbook je napsán v~YAML formátu.
\item \textbf{Inventory}: Seznam spravovaných zařízení Ansiblem. Inventory může být statický nebo dynamický(generovaný) a umožňuje seskupovat jednotlivé zařízení do skupin podle jejich vlastnostní nebo umístění.
\item \textbf{Moduly}: Předpřipravené funkce, které Ansible používá k~provádění úkolů. Příkladem může být modul \verb|apt| pro instalaci balíčků, nebo \verb|filesystem| pro správu filesystémů. Kromě široké sady vestavěných modulů v~Ansible lze vytvořit i vlastní moduly.
\item \textbf{Role} jsou strukturované jednotky obsahující playbooky, proměnné, šablony a soubory tak, aby byly znovupoužitelné na různých systémech či v~jiných kontextech.
\item \textbf{Proměnné} se v~Ansiblu používají k~ukládání hodnot využitelných v~playboocích, šablonách nebo modulech. V~Ansiblu lze definovat specifické hodnoty proměnných pro konkrétní zařízení, pro skupiny zařízení nebo pro danný playbook.
\item \textbf{Templates (šablony)} slouží pro generování konfiguračních souborů na základě proměnných a logiky. Zapisují se v~jazyce Jinja2.
\item \textbf{Handlers} jsou speciální úkoly, které jsou spuštěny pouze tehdy, dojde-li ke změně na konfigurovaném zařízení. Používají se například pro restart služby při změně konfigurace.
\item \textbf{Facts (fakta)} jsou shromážděné informace o~konfigurovaném zařízení, které lze dále použít v~playboocích ke konfiguraci cílových zařízení.
\end{itemize}
Ke správě konfigurace přístupových bodů jsem vytvořil adresář, který dodržuje standartní adresářovou strukturu Ansible.
\lstinputlisting[caption={Adresářová struktura Ansible}, language=bash,]{ansibleTree.txt}
V~adresáři \verb|roles/gekmihesg.openwrt| je naklonován repozitář \verb|ansible-openwrt|\footnote{\url{https://github.com/gekmihesg/ansible-openwrt}}, který přidává roli pro konfiguraci zářízení OpenWrt. Pro použití modulů této role je potřeba umístit spravovaná zařízení do skupiny \verb|openwrt| v~inventory Ansiblu a použít roli \verb|gekmihesg.openwrt| v~direktivě \verb|roles:| v~playbooku.
\pagebreak
% ------------------------------------------------------------------------------------------------------------------
\subsection{Nasazení nových přístupových bodů}
Pro nasazení nových přístupových bodů slouží playbook \verb|addNewAPs.yml|.
\lstinputlisting[caption={Obsah playbooku addNewAPs.yml},]{../apLukov/addNewAPs.yml}
V~úvodu prvního úkolu playbooku jsou v~proměnné \verb|subnets| definovávy podsítě, které budou proskanovány programem \verb|ping|. Proskenován je adresní rozsah DHCP serveru, kde jsou hledány dynamicky přidělené nové IP adresy nově připojených přístupových bodů a taky adresní rozsah mimo DHCP server, aby byly zjištěny volné IP adresy, ze kterých bude novým přístupovým bodům přidělena statická IP adresa. Nalezená nová zařízení jsou přidána do dynamického inventáře se kterým se pracuje v~dalším úkolu. Volné IP adresy jsou uloženy do proměnné.
Další úkol playbooku získá fakta o~nalezeném zařízení a vyextrahuje z~něj MAC adresu, která bude sloužit jako unikátní identifikátor zařízení. Je vytvořen seznam nalezených zařízení indexovaný jejich hostnamem, který je vytvořený z~MAC adresy a prefixu \verb|ap_|.
Ve třetím úkolu playbooku je vytvořen prostřednictvím playbooku \\ \verb|include/createHostVars.yml| soubor pro definici specifických proměnných pro dané zařízení v~adresáři \verb|host_vars| podle šablony \verb|templates/host_vars.j2|. Název souboru a hostname zařízení používaný vrámci Ansible je získán v~předchozím kroku. Při vytváření souboru je pro dané zařízení přiřazena do proměnné \verb|device_ip_address| IP adresa z~rozsahu volných IP adres. Nalezené zařízení je s~přiřazenou IP adresou přidáno do \verb|invetory.yml|.
V~posledním úkolu playbooku je prostřednictvím role \verb|network| na nalezených nových zařízeních nastavena statická adresa zapsána v~předchozím kroku do proměnné \verb|device_ip_address| a provedeno další síťové nastavení.
Playbook se spouští příkazem \verb|$ansible-playbook addNewAPs.yml|
% ------------------------------------------------------------------------------------------------------------------
\subsection{Konfigurace přístupových bodů}
Výchozí situace před finálním nakonfigurováním je taková, že všechny přístupové body jsou přidány do souboru \verb|inventory.yml| a mají nastavenou statickou IP adresu. Zařízení jsou v~\verb|inventory.yml| rozdělena do skupin podle toho zda používají DSA\footnote{Distributed switch Architecture} nebo nástroj \verb|swconfig| pro konfiguraci switche, protože switch je nutno pro oba případy konfigurovat odlišně. Princip DSA je popsán v~závěru sekce \ref{subsec:kompilace}. Skupiny \verb|dsa| a \verb|swcofig| jsou v~metaskupině \verb|accessPoints|, která je v~další metaskupine \verb|openwrt| pro správnou funkci role \verb|gekmihesg.openwrt|.
\lstinputlisting[caption={Příklad inventory.yml},]{../apLukov/inventory.yml}
\pagebreak
% ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' '
\subsubsection{Zápis globální systémové konfigurace}
Konfigurace je zapsána především deklarativním způsobem v~souborech\\\verb|group_vars/openwrt.yml| a \verb|group_vars/accessPoints.yml|. Tato konfigurace se aplikuje na všechny přístupové body, je zde tedy zapsána konfigurace, která bude na všech přístupových bodech stejná. Jedná se o~nastavení systému, softwarových bridgů, síťových rozhraní a Wi-Fi rozhraní.
\lstinputlisting[caption={Ukázka group\_vars/openwrt.yml},]{../apLukov/group_vars/openwrt.yml}
Sekce \verb|System| YAML souboru slouží pro konfiguraci systému openwrt (především časového pásma) a systémových nástrojů (nastavení logování). Sekce ovlivňuje konfiguraci v~\verb|/etc/config/system|\footnote{\url{https://openwrt.org/docs/guide-user/base-system/system_configuration}} na systému OpenWrt. Konfigurace systému je provedena Ansible rolí \verb|system|.
% ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' '
\subsubsection{Role k~provedení sytémové konfigurace}
\lstinputlisting[caption={Ukázka roles/system/tasks/main.yml},]{../apLukov/roles/system/tasks/main.yml}
Role \verb|system| pomocí modulu \verb|uci| nastaví sekci system systému OpenWrt udělá commit\footnote{uložení změn} a pokud proběhnou změny restartuje modulem \verb|ansible.builtin.service| systémovou službu pomocí handeru v~\verb|roles/system/handlers/main.yml|.
% ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' '
\subsubsection{Zápis globální síťové konfigurace}
\lstinputlisting[caption={Ukázka group\_vars/accessPoints.yml},]{../apLukov/group_vars/accessPoints.yml}
Konfigurací v~\verb|group_vars/accessPoints.yml| jsou ovlivněny konfigurační soubory \verb|/etc/config/network|\footnote{\url{https://openwrt.org/docs/guide-user/network/network_configuration}} a \verb|/etc/config/wireless|\footnote{\url{https://openwrt.org/docs/guide-user/network/wifi/basic}} systému OpenWrt.
V~úvodu se z~Ansible faktů zjistní logické identifikátory 5Ghz a 2,4GHz Wi-Fi rádií a uloží se do proměnných \verb|device_2g_radio| a \verb|device_5g_radio|. Tyto proměnné slouží k~individuální konfiguraci přístupového bodu, kdy pomocí těchto proměnných lze omezit vybrané Wi-Fi síťě pouze na danné rádia.
Sekce \verb|network_devices| definuje jaká síťová zařízení budou vytvořena. V~tomto případě budou podle kapitoly \ref{sec:sitoveProstredi} vytvořena čtyři síťová zařízení typu bridge. Bridge v~OpenWrt je logické síťové zařízení, které spojuje více fyzických nebo virtuálních rozhraní do jednoho síťového segmentu. V~tomto případě budou vytvořeny síťové bridge pro propojení ethernetového portu s~VLAN a adekvátní Wi-Fi síťě.
Sekce \verb|network_interfaces| definuje čtyři nová síťová rozhraní, která budou vytvořena nad vytvořenými síťovými bridgy.
Sekcí \verb|wireless_device_default| jsou nastaveny výchozí hodnoty pro všechna Wi-Fi rádia zařízení. V~tomto případě je nastaveno, že rádio bude ve výchozím stavu zapnuto a bude nastaven country code CZ. Toto nastavení zajišťuje dodržování právních předpisů týkajících se používání elektromagnetického spektra definovaných ve všeobecného oprávnění ČTÚ\footnote{Český telekomunikační úřad}. Zejména se jedná o~omezení počtu kanálů a maximálního vysílacího výkonu.
V~poslední sekci \verb|wireless_interfaces| jsou definovány dvě Wi-Fi sítě podle požadavků v~kapitole \ref{ch:pozadavky}. První síť má SSID \verb|eduroam| a k~zabezpečení využívá WPA2 Enterprise. Adresa autentizačního a autorizačního serveru je definovaná v~proměnné \verb|auth_server|, heslo je uloženo v~proměnné \verb|auth_secret|. Je zde umožněn roaming dle 802.1r. Jedním z~požadavků na modelovou implementaci je dynamické přidělování uživatelů do příslušných VLAN, tohoto je docíleno pomocí parametrů v~proměných \verb|dynamic_vlan|, \verb|vlan_tagged_interface|, \verb|vlan_bridge| a \verb|vlan_naming|, které ovlivňují chování démona \verb|hostapd|.
\verb|Hostapd| je nástroj určený ke správě a vytváření Wi-Fi sítí. Kromě toho zajišťuje autorizaci zařízení a funguje jako 802.1X autentizátor, tedy zprostředkovává autentizaci mezi klientským zařízením a autetizačním serverem. V~OpenWrt je součástí balíčku \verb|wpad-mbedtls|, který jsme nainstalovali ve své plnohodnotné verzi při kompilaci.
Parametr \verb|dynamic_vlan| \verb|hostapd| definuje zda je clientské zařízení dynamicky přidělováno do vlan. Jsou definovány tři stavy. 0 - neprobíhá dynamické přiřazování vlan, 1 - VLAN není požadováno, použije se výchozí síťové rozhraní, 2 - VLAN je od RADIUS serveru požadována jinak clientské zařízení nepřipojí.
Pokud je dynamické přidělování zapnuto \verb|hostapd| Wi-Fi clienty přiřazuje do adekvátních bridgů. K~tomu potřebuje znát prefix bridge, který je definovaný v~\verb|hostapd| parametru \verb|vlan_bridge|. \verb|vlan_naming| s~hodnotou 1 říká, že do bridge bude přirazeno ethernetové rozhraní ve formátu \verb|<vlan_tagged_interface>.<VLANtag>|, v~případě hodnoty 0 je přiřazeno rozhraní s~názvem \verb|vlan<vlantag>|. V~parametru \verb|vlan_tagged_interface| je tedy uvedeno ethernetové rozhraní propojující přístupový bod a router sítě. \citep{OpenWrtDoc8021X}
Druhou definovanou Wi-Fi síťí je \verb|free wifi| která nevyžaduje žádnou autentizaci a je přiřazena k~síťovému rozhraní \verb|free_wifi|.
Obě dvě Wi-Fi sítě jsou ve výchozím nastavení spuštěny na všech Wi-Fi rádiích zařízení. V~promněnné \verb|isolated| je nastaveno blokování komunikace clientů vrámci Wi-Fi sítě.
% ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' '
\subsubsection{Zápis unikátní konfigurace pro jednotlivé zařízení}
Specifická konfigurace zařízení je zapsána v~\verb|host_vars/ap_<mac_adresa>.yml|. Tato konfigurace slouží k~nastavování IP adresy zařízení, hostname zařízení a nastavení switche. Zde je nutné nastavit jednotlivé VLANy a jejich porty. Na jednotlivých přístupových bodech je pomocí této konfigurace také možné nastavovat kanál Wi-Fi rádií, vysílací výkon nebo které Wi-Fi sítě se mají vysílat na kterých rádiích.
\lstinputlisting[caption={Ukázka specifické konfigurace přístupového bodu s~DSA switchem},]{../apLukov/host_vars/ap_107c61992bd8.yml}
U~přístupových bodů implementující DSA se nejdíve definuje v~sekci \verb|network_devices_append| nový bridge k~vytvoření, který obsahuje fyzické ethernetové porty zařízení. V~sekci \verb|network_bridge_vlan_filtering| se definují čísla VLAN a ethernetové porty, na kterých budou tyto VLAN aktivní. Dále se určí, které porty budou označeny tagem a které nikoli.
Sekce \verb|wireless_devices| slouží k~nastavení kanálů a vysílacích výkonů jednotlivých rádií. Výkon se zapisuje v~dBm a je nutné se podívat do dokumentace k~danému zařízení jaké výkony umožňuje nastavit. Stejně tomu je i u~kanálu. Některá zařízení mají omezené možnosti nastavení kanálu, zejména v~pásmu 5GHz.
Sekcí \verb|wireless_interfaces_override| lze omezit danou Wi-Fi síť pouze na určité rádio.
\lstinputlisting[caption={Ukázka specifické konfigurace přístupového bodu s~swconfig switchem},]{../apLukov/host_vars/ap_b04e26bbc7e3.yml}
U~zařízení, kde se switch spravuje nástrojem \verb|swconfig| se tato konfigurace provádí sekcí \verb|network_swconfig|. Je zde opět uvedeno číslo VLAN a ethernetový port. V~případě \verb|swconfig| switche je potřeba nahlédnou do dokumentace k~zařízení, protože jednotlivé porty jsou na každém zařízení číslovány jinak.
% ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' '
\subsubsection{Role k~provedení síťové konfigurace}
\lstinputlisting[caption={Role network},]{../apLukov/roles/network/tasks/main.yml}
Role \verb|network| nejdříve iteruje sekcí \verb|network_swconfig| a konfiguruje prostřednictvím playbooku \verb|swconfig.yml| switch u~zařízení kde je tato sekce definována. Dále jsou playbookem \verb|device.yml| nastaveny síťové bridge opět iterací přes sekci \verb|network_devices| doplněnou o~VLAN filtrující bridge z~proměnné \verb|network_devices_append| u~zařízení implemntujících DSA. Ve třetím kroku jsou nakonfigurovány VLANy v~případě DSA zařízení pomocí playbooku \verb|vlan_filtering.vlan|. V~posledním kroku jsou vytvořeny síťové rozhraní playbookem \verb|interface.yml|, provedené změny jsou aplikovány a je restarováno síťování na přístupovém bodu. Pro případ změny IP adresy zařízení jsou na konci úkoly měnící IP zařízení v~inventory běžícího playbooku.
\lstinputlisting[caption={Ukázka swconfig.yml},label={lst:swconfig.yml}]{../apLukov/roles/network/tasks/swconfig.yml}
\lstinputlisting[caption={Ukázka device.yml},label={lst:device.yml}]{../apLukov/roles/network/tasks/device.yml}
\lstinputlisting[caption={Ukázka vlan\_filtering.yml},label={lst:vlan_filtering.yml}]{../apLukov/roles/network/tasks/vlan_filtering.yml}
\lstinputlisting[caption={Ukázka interface.yml},label={lst:interface.yml}]{../apLukov/roles/network/tasks/interface.yml}
Ukázky \ref{lst:device.yml}, \ref{lst:vlan_filtering.yml} a \ref{lst:interface.yml} jsou zkráceny o~začátek souboru, který je téměř totožný se začátkem v~\ref{lst:swconfig.yml}. Ve všech případek je použit pro konfigurace přístupových bodů modul \verb|uci| z~role \verb|gekmihesg.openwrt|.
Role \verb|wireless| provádí konfigurací Wi-Fi rádií a jejich síťí. Role iteruje všemi dostupnými rádiemi zařízení a nastavuje jejich výchozí hodnoty z~proměnné \verb|wireless_devices_default| a kanály s~vysílacími výkony, tak jak jsou definovány u~konkrétních zařízení. Toto je provedeno v~playbooku role \verb|device.yml|
Následně vytváří wifi sítě tak jak jsou definovány v~\verb|group_vars/accessPoints.yml| pomocí playbooku role \verb|interface.yml|. Při vytváření se zohleďnují individuální nastavení pro jednotlivé přístupové body v~sekci YAML konfigurace \verb|wireless_interfaces_override|.
\lstinputlisting[caption={Role wireless},]{../apLukov/roles/wireless/tasks/main.yml}
\lstinputlisting[caption={Ukázka devices.yml},]{../apLukov/roles/wireless/tasks/device.yml}
\lstinputlisting[caption={Ukázka interface.yml},]{../apLukov/roles/wireless/tasks/interface.yml}
Samotná konfigurace opět probíhá module \verb|uci|.
% ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' '
\subsubsection{Playbook k~provedení finální konfigurace}
\lstinputlisting[caption={Ukázka setupAPs.yml},]{../apLukov/setupAPs.yml}
Playbook využívá role \verb|system|, \verb|network| a \verb|wireless|, které provedou konfiguraci podle nastavení v~proměnných v~adresářích \verb|group_vars| a \verb|host_vars|. Po nastavení zařízení jsou spuštěny další úkoly v~sekci \verb|post_tasts|. Pomocí modulu \verb|opkg| jsou na všechny přístupové body nainstalován balíčky \verb|prometheus-node-exporter-lua| a \verb|prometheus-node-exporter-lua-hostapd_station|. Tyto balíčky jsou modulem \verb|uci| nakonfigurovány a všechna zařízení jsou restartována.
Playbook se spouští příkazem \verb|$ ansible-playbook -i inventory.yml setupAPs.yml|. Timto je dokončena finální konfigurace všech přístupových bodů infrastruktury.
% ==================================================================================================================
\section{Nastavení antentizačního serveru}
Národní operátor sítě eduroam v~české republice CESNET z. s. p. o. nabízí Ansible role pro konfiguraci autentizačního serveru freeRADIUS.
Tyto role jsou dostupné v~repozitáři \url{https://github.com/CESNET/ansible-freeradius}. Naklonováním repozitáře přidám role do adresáře \verb|roles/| adresářové struktury Ansible. Budou využity při konfiguraci freeRADIUS serveru v~této modelové implementaci.
Role provádějí kompletní instalaci a konfiguraci freeRADIUS serveru. Předpokládají požití jednoho z~linuxových systémů založených na distribuci Debian (s~balíčkovacím systémem \verb|apt|) nebo CentOS/RHEL (s~balíčkovacím systémem \verb|dnf|) Na autentizačním serveru se musí nakonfigurovat SSH server a přidat autentizační klíče pro přístup Ansible.
Po naklonování role repozitáře je nutné definovat konfiguraci v~adresářích \verb|group_vars|, \verb|host_vars| a přidat certifikáty.
Role je distribuována s~příklady konfigurace. Modelová implementace předpokládá použití lokálních identit uživatelů. Tomu odpovídá příklad konfigurace \verb|semik-dev.cesnet.cz-IdPSP.yml| z~adresáře role \verb|examles/|. Tento příklad nakopirujeme do \verb|host_vars/<realm>.yml|.
V~sekce \verb|ldap| této konfigurace se definuje LDAP server kde budou uloženy identity lokálních uživatelů. V~sekci eduroam se konfigurují parametry pro integraci freeRADUS serveru do federace eduroam a paramety pro fungování ověřování identit uživatelů.
\subsection{LDAP}
...
\subsection{Výběr systému pro správu zařízení}
\subsection{Certifikáty}
...
freeRADIUS pro zajištění různých typů komunikace potřebu certifikáty. Ty vytváření bezpečnou komunikaci při komunikaci se suplikanty, jinými RADIUS servery nebo LDAP serverem.
\subsection{Příprava zařízení pro integraci do sítě}
\begin{figure}
\centering
\includegraphics[width=1\textwidth]{images/radius_certifikaty.png}
\caption{Porovnání modelu ISO OSI a TCP/IP. \citep{eduroam_certifikaty}}
\label{fig:radius_certifikaty}
\end{figure}
...
\subsection{Přístupové body}
Přístup přístupových bodů (autentifikátorů) k~freeRADIUS serveru se spravuje v~sekci \verb|radius.NAS|. Zde je definováno heslo použité v~proměnné \verb|auth_secret| v~konfiguraci přístupových bodů. V~modelové implementaci jsou přístupové body na dvou lokacích, přístupové body jsou v~každé lokaci jiné síti, proto jsou zde uvedeny záznamy pro dvě sítě.
\begin{lstlisting}[numbers=none]
radius:
NAS:
- ipaddr: 10.11.99.1/24
secret: Jednokolka123
shortname: SiteA
- ipaddr: 10.22.99.1/24
secret: Jednokolka123
shortname: SiteB
\end{lstlisting}
\subsection{Nastavení management sítě a zřízení přístupu}
% ==================================================================================================================
\section{Monitoring a logování}
...
Pro získání komplexního přehledu o~přístupových bodech a síťi je potřeba shromáždit infromace ze samotných přístupových bodů, z~RADIUS serveru a z~gatewaye (routeru).
\subsection{Monitoring a centrální logování}
% ------------------------------------------------------------------------------------------------------------------
\subsection{Systémový log}
Systémové logy hrají zásadní roli při monitorování stavu zařízení. Poskytují důležité informace o~bezpečnostních incidentech, hardwarových a softwarových problémech nebo jiných událostech, které vyžadují pozornost. Aby byla tato data užitečná doporučuje se logy uchovávat alespoň jeden měsíc. Důvodem je skutečnost, že odhalení bezpečnostního incidentu může také zabrat určtitý čas. \citep{Nemeth_Evi_2008}
...
Systém OpenWrt používá nástroj \verb|logd| z~projektu ubox\footnote{\url{https://git.openwrt.org/?p=project/ubox.git}} k~řízení systémového logování. Tento nástroj sbírá logovací zprávy od všech programů běžících na systému OpenWrt a ukládá je do centrálního systémového logu. Ve výchozí konfiguraci je tento log uložen do cyklické vyrovnávací paměti umístěné v~operační paměti (RAM). Tento přístup minimalizuje zápisy do trvalé paměti zařízení, což je důležité zejména u~zařízení s~NAND pamětí, která by mohla nadměrnými zápisy degradovat.
Kvůli omezené kapacitě cyklické vyrovnávací paměti v~RAM je vhodné logy z~přístupových bodů přesměrovat na centrální logovací server přes síť.
Nástroj \verb|logd| tuto funkci podporuje a modelová implementace výše tuto konfiguraci zahrnuje.
Na centrálním serveru mohou být logy dále zpracovávány a analyzovány pomocí dalších nástrojů.
% ------------------------------------------------------------------------------------------------------------------
\subsection{Log RADIUS serveru}
Pro získání detailnějších informací o~lokálních autentizovaných klientech, zejména prostřednictvím sítě eduroam je potřeba provést úpravy serveru.
Logování na FreeRADIUS serveru zajišťuje modul linelog, který umožňuje zapisovat záznamy do systémového logu.
\lstinputlisting[caption={Soubor mods-available/linelog},]{linelog.txt}
Konfigurace\footnote{\url{https://wiki.freeradius.org/guide/eduroam}} dostupná na webu freeradius.com ukazuje příklad s~několika instancemi modulu \verb|linelog|, které slouží k~logování příchozích RADIUS požadavků nebo odpovědi. Tyto instance jsou následně volány v~hlavním konfiguračním souboru FreeRADIUS \verb|sites-available/default| na příslušných místech v~rámci zpracování RADIUS požadavků. Zalogovány jsou lokální požadavky na autorizaci, odpovědi na autentizační požadavky, odpovědi na požadavky přijaté od jiných institucí a odeslané proxy požadavky směrem k~jiným institucím.
\lstinputlisting[caption={Nastavení logování v~sites-available/default},]{default.txt}
Výsledkem této konfigurace je detailnější log, včetně například atributů NAS-IP-Address, Operator-Name, Calling-Station-Id, tedy IP adresy autentizátoru, název instituce, ze které přišel nebo kam se odesílá požadavek/odpověď a MAC adresa zařízení. Tyto záznamy je nutné dle Technických požadavků a doporučení
pro členy federace eduroam.cz\footnote{\url{https://www.eduroam.cz/_media/cs/technicke_pozadavky_eduroam.pdf}} archivovat alespoň 6 měsíců.
Ze systémového logu RADIUS serveru lze tyto záznamy opět přeposlat na centrální logovací server.
% ------------------------------------------------------------------------------------------------------------------
\subsection{Monitoring systému a hardwarových prostředků}
Kromě systémového logu mohou historické záznamy o~stavu systému a hardwarových prostředcích sloužit ke zpětné analýze příčin vzniklých problémů, což usnadňuje jejich diagnostiku a řešení. Monitoring také umožňuje včas identifikovat potenciální problémy, jako je vyčerpání operační paměti nebo nedostatek výpočetní kapacity CPU, a tím zabránit výpadkům.
V~modelové implementaci jsou shromážděné informace předávány na centrální server, kde jsou uloženy a mohou být vizualizovány.
Systém OpenWrt ve svých repozitářích nabízí tyto open-source nástroje pro shromaždování informací o~systému a jejich předání dále: \verb|zabbix-agentd|, \verb|collectd|, \verb|prometheus-node-exporter-lua| \verb|snmpd| a \verb|telegraf|. \citep{RamsTech}
Z~těchto nástrojů jsem zvolil nástroj \verb|prometheus-node-exporter-lua| pro jeho jednoduchý princip předávání dat a existenci jeho rozšíření \verb|prometheus-node-exporter-lua-hostapd_stations|, díky kterému lze získat podrobné informace o~připojených klientech k~jednotlivých Wi-Fi sítím z~démona hostapd.
\verb|prometheus-node-exporter| shromážděné data o~systému publikuje v~textovém formátu na vlastním http serveru. Prometheus server tato data pravidelně dotazuje, ukládá je do své databáze časových řad a umožňuje jejich další zpracování. Pro vizualizaci dat lze využít nástroj Grafana, který umožňuje vytvářet přehledné grady a dashboardy z~dat uložených v~Prometheu.
% ------------------------------------------------------------------------------------------------------------------
\subsection{Síťové toky}
Z~důvodu použití překladu IP adres NAT na gatewayi je třeba zaznamenávat provozní údaje veřejných komunikačních sítí, aby byly splněny zákonné požadavky i pravidla federace eduroam.cz. Podobně jako u~logů RADIUS serveru musí být tyto údaje uchovávány alespoň 6 měsíců
Provozní údaje jsou zákonem definovány jako \textit{údaje vedoucí k~dohledání a identifikaci zdroje a adresáta, dále údaje vedoucí ke zjištění data, času, způsobu a doby trvání komunikace.} \citep{Zak_El_Kom} V~kontextu TCP/IP síťí to jsou IP adresy a použité porty zdroje a cíle, MAC adresa zdroje, druh provozu (UDP, TCP, ICMP), čas zahájení komunikace a doba trvání komunikace.
NetFlow je protokol pro předávání informací o~síťových tocích, které vznikají agregací síťových paketů na základě údajů z~jejich hlaviček.
Na routeru předávajícím síťové pakety z~rozhraní na rozhraní je naistalován software, který provádí agregaci těchto paketů do flow dat. Pakety mohou být pro snížení náročnosti dalšího zpracování samplovány\footnote{je vybrán každý n-tý paket}, aniž by byla výrazně narušena kvalita zaznamenaných síťových toků.
Tyto flow data jsou následně poslána na server k~jejich uložení a případně dalšímu zpracování/analýze.
Tvorba dat o~síťových tocích snižuje náročnost na výpočetní výkon a šetří šířku pásma pro přenost dat, protože místo přenosu jednotlivých paketů se odesílají pouze informace o~toku. Agregací síťových toků se zvyšuje soukromí uživatelů, protože místo podrobných záznamů o~každém paketu jsou uchovávány pouze sumarizované informace o~jejich toku. \citep{Hofstede2014} Pro získání MAC adres zařízení je nutné použít netflow ve verzi V9 nebo IPFIX.
Většina systémů enterprise routerů nabízí možnost nastavení zaznamenávání síťových toků a jejich následné zaslání na server k~uložení/dalšímu zpracování. V~open-source systému OPNsense má tvorba\footnote{\url{https://docs.opnsense.org/manual/netflow.html}} netflow dat podporu přímo v~jádru operačního systému FreeBSD. Díky tomu je zatížení systému při tvorbě netflow minimální v~porovnání se softwarovou implementací \verb|softflowd| dostupnou například na systému OpenWrt.
Pro jednoduché ukládání a zobrazení netflow dat bez náročných analytických možností lze zvolit nástroj \verb|nfcapd|, který přijaké data uloží v~binárním formátu. Tyto data lze poté prohlížet \verb|nfdump|.
V~případě požadavku na sdělení provozních a lokalizačních údajů nejčastěji ze strany orgánů veřejné moci lze pomocí toho příkazu listovat a filtrovat netflow data na základě cílové IP adresy a zdrojového portu:
\lstinputlisting[]{nfdump}

View File

@@ -1,3 +1,14 @@
\chapter{Deklarace požadavků na modelovou Wi-Fi síť}
\label{ch:pozadavky}
...
Implementace rozsáhlé Wi-Fi síťě bude vycházet z~potřeb modelového školského zařízení. Školská zařízení jsou většinou rozsáhlejší objekty. Modelová implementace bude tedy obsahovat množství přístupových bodů Wi-Fi včetně přístupových bodů na jednom detašovaných pracovištích.
Přístupové body budou nabízet připojení v~pásmu 5 GHz a 2,4 GHz pro kompatibilitu se staršími clientskými zařízeními. V~každém pásmu budou k~dispozici dvě Wi-Fi sítě.
První Wi-Fi síť bude určena pro studenty a pracovníky školy. Tato síť bude součástí projektu eduroam, bude tedy vyžadovat autentizaci a autorizaci uživatelů vůči autorizačnímu serveru. Síť bude zprostředkovávat přístup do veřejné sítě Internet a podle role uživatele bude uživatel přiřazen do určité VLAN s~danými oprávněními k~lokálním službám.
Další Wi-Fi síť bude veřejná síť bez jakékoli autorizace přístupu na úrovni Wi-Fi.
Klíčovým požadavkem je spravovat přístupové body Wi-Fi centrálně.
V~neposlední řadě je nutné zajistit monitoring přístupových bodů a provozních údajů jednak z~důvodu zvýšení spolehlivosti sítě tak i z~důvodu legislativních požadavků vyplývajících ze zákona o~elektronických komunikacích, který říká, že právnická osoba zajišťující veřejnou komunikační síť je povinna uchovávat po dobu 6 měsíců provozní a lokalizační údaje, které jsou vytvářeny nebo zpracovávány při zajišťování jejích veřejných komunikačních sítí. \citep{Zak_El_Kom} Obdobný požadavek klade i český koordinátor sítě eduroam ve svých technických požadavcích a doporučeních pro členy federace eduroam.cz.

View File

@@ -1,3 +1,209 @@
\chapter{Počítačové sítě}
...
V~širším pojetí jsou počítačové sítě multidisciplinárním oborem zaměřujícím se na návrh, implementaci, správu a propojení technických prostředků umožňující navázání spojení a předávání dat mezi počítači a dalšími zařízeními.
V~užším pojetí je počítačová síť tvořena vzájemně propojenými počítači za účelem sdílení dat a zdrojů.
\textit{Nejdůležitější vlastností počítačových sítí je jejích obecné použití. Počítačové sítě jsou primárně budovány z~univerzálního programovatelného hardwaru a nejsou optimalizovány pro konkrétní aplikaci, jako je telefonování nebo přenos televizního signálu} \citep{Peterson_Davie_2022}
na rozdíl od telekomunikačních sítí (pevná telefonní síť nebo telegrafní síť), které jsou pevně spjaty se službou, kterou poskytují.
Počítačové sítě dokáží přenášet širokou škálu dat včetně textu, obrazu, hlasu, videa, různých souborů a dalších dat. Toto umožuje počítačových síťím podporovat mnoho aplikací a služeb.
Jedním z~požadavků na počítačové sítě je možnost dynamického navázání spojení a předávání dat s~jinými zařízeními. K~tomu se uplatňuje princip přepínané sítě. Existují dva základní principy přepínané sítě. Přepínané sítě založeny na principu \textbf{přepojování okruhů} a sítě založeny na principu \textbf{přepojování paketů}. První z~jmenovaných principů je starší a běžný pro tradiční telefonní síť, kdy je na začátku spojení vytvořen přenosový okruh mezi zdrojovým a cílovým uzlem. Tento okruh má garantované přenosové pásmo a je rozpojen na konci spojení.
Princip \textbf{přepojování paketů} vymysleli nezávisle na sobě vědci Paul Baran a Donald Davies. Přenášená data se rozdělí na bloky o~určité délce. Každý blok se doplní o~informace o~zdroji, cíli, případně o~další informace potřebné pro přenos. Takový blok se nazývá paket a je odesílán po síti. Síťové prvky každý jeden paket na základě cílové adresy směrují k~dalšímu síťovému prvku nebo koncovému zařízení. Takto může každý každý paket cestovat po síti jinou cestou k~cíli v~závislosti na aktuálním stavu sítě. Na cílovém zařízení dojde k~příjmu a seřazení paketů do původního pořadí, následně jsou z~jednotlivých paketů sestavena původní data.
Koncové zařízení je zařízení vybavené komunikačním rozhraním (síťovým adaptérem), které využívá síťové služby a může poskytovat síťové služby jiným zařízením. Mezi typické koncové zařízaní patří počítač, síťové tiskárny, mobilní zařízení, herní konzole, IoT zařízení.
% ==================================================================================================================
\section{Síťová architektura}
V~době vývoje počítačových sítí (v~70. letech 20. století) byly vyvinuty různé síťové technologie, které však nebyly vzájemně kompatibliní. Toto stěžovalo komunikaci mezi koncovými zařízeními různých výrobců. Snaha o~propojení různých sítí a požadavek na kompatibilitu koncových zařízení různých výrobců vyvolávala potřebu standardizace.
\begin{figure}
\centering
\includegraphics[width=0.7\textwidth]{images/osi-tcpip.jpg}
\caption{Porovnání modelu ISO OSI a TCP/IP. \citep{peterka_tcpip}}
\label{fig:rozdilmodelu}
\end{figure}
V~reakci na tuto situaci organizace ISO\footnote{International Organization for Standardization - Mezinárodní organizace pro normalizaci} vyvinula teoretický model koncepce počítačových síťí, známý jako model OSI (Open System Interconnection). Tento obecný model fungování počítačových sítí rozděluje jednotlivé funkce sítě do sedmi vrstev (pravá část obrázku \ref{fig:rozdilmodelu}). Každá vrstva má svůj specifický úkol. Existence modelu usnadnila vývoj síťových prvků a zvýšila interoperabilitu mezi různými technologiemi a výrobci.
V~praxi se pro komunikaci počítačů ujala sada protokolů TCP/IP, která vznikla v~70. letech 20. století pro projekt ARPANET, který byl předchůdcem dnešního internetu a definovala jak mezi sebou mají komunikovat jednotlivé zařízení. Jedná se tedy o~praktickou implementaci síťové komunikace, zatímco OSI zůstává referenčním modelem. V~souvislosti s~modelováním síťové komunikace se lze setkat s~modelem TCP/IP, který fungování těchto protokolů organizuje do vrstev podle modelu ISO/OSI. Oproti modelu ISO/OSI má model TCP/IP vrstevy pouze čtyři, protože jsou některé vrstvy zkombinovány. Porovnání obou modelů je znázorněno na obrázku \ref{fig:rozdilmodelu}.
Vrstvy modelu TCP/IP:
\begin{itemize}
\item \textbf{Vrstva síťového rozhraní}: Jedná se o~nejnižší vrstu modelu TCP/IP. Zajišťuje rámcování dat (rozdělení dat na menší bloky), které jsou přenášeny přes přenosové médium a řídí přístup k~tomuto médiu. Má na starosti příjímat a odesílat jednotlivé bity prostřednictvím přenosového média a zároveň detekovat a opravovat případné chyby, ke kterým mohlo dojít při přenosu dat. Vrstva síťového rozhraní může používat libovolnou přenosovou technologií (Ethernet, Wi-Fi, DSL, optická vlákna), pro kterou musí přizpůsobit přenášená data.
\item \textbf{Síťová vrstva}: Hlavním úkolem síťové vrstvy je zajistit přenost dat mezi odesílatelem a příjemcem v~různých síťích, kteří nejsou přímo spojeni. K~tomu využívá adresaci, směrování a fragmentaci (rozdělení dat na menší bloky pro přenos přes různé typy síťí). Síťová vrstva pracuje s~protokoly IP (Internet Protokol) pro adresaci a směrování a ICMP (Internet Control Message Protocol) pro diagnostiku.
\item \textbf{Transportní vrstva}: Tato vrstva také rozděluje data z~aplikační vrstvy na menší bloky (segmenty) a na straně příjemce je znovu skládá do původní podoby. Slouží k~zajištění přenosu dat mezi aplikacemi běžícími na různých zařízeních v~síťi. \textit{Podle jejich nároků a požadavků může transportní vrstva regulovat tok dat oběma směry, zajišťovat spolehlivost přenosu, měnit nespojovaný charakter přenosu (v~síťové vrstvě) na spojovaný} \citep{peterka_tcpip}, kontrolovat chyby v~přijatých datech a řídit pořadí doručených dat. Nejznámější protokoly pracující na transportní vrstvě jsou TCP pro spojovaný (vytváří iluzi nepřerušovaného spojení), spolehlivý přenost dat a UDP pro nespolehlivý přenos dat bez spojení.
\item \textbf{Aplikační vrstva}: Nejvyžší vrstva TCP/IP modelu slouží jako rozhraní mezi aplikacemi a síťovou infrastrukturou.
\end{itemize}
\begin{figure}
\centering
\includegraphics[width=1\textwidth]{images/tcpip_zapouzdreni.png}
\caption{Schéma zapouzdření aplikačních dat na vrstvách TCP/IP. \citep{wiki_tcpip}}
\label{fig:zapouzdreni}
\end{figure}
Oprázek \ref{fig:zapouzdreni} ilustruje spolupráci jednotlivých vrstev síťového modelu TCP/IP. Vrsvy sítě plní své specifické úkoly a využívají služeb bezprostředně nižší vrstvy.
Data jsou předány od aplikací transportní vrsvě, která data rozdělí na menší bloky~-~segmenty\footnote{u UDP též datagramy} a opatří každý segment hlavičkou podle druhu spojení. Obsah Transportní vrstvy je předán vrsvě síťové, která ho zabalí do IP paketů. Každý IP paket obsahuje hlavičku s~IP adresami odesílatele a příjemce, což umožňuje směrování dat přes různé sítě. Síťová vrstva předá IP pakety vrstvě síťového rozhraní, která pakety zabalí do rámců. Rámce jsou opatřeny potřebnými infromacemi pro přenos dat na fyzické vrstvě.
Při příjmu dat probíhá tento proces opačně, hlavičky jsou odebírány. Rámce jsou rozbaleny na IP pakety a IP pakety na segmenty, které jsou složeny do původních dat, která jsou předána aplikaci. Každá vrstva zpracovává svou vlastní hlavičku.
\begin{figure}
\centering
\includegraphics[width=0.8\textwidth]{images/tcpip_komunikace.png}
\caption{Schéma komunikace napříč sítěmi v~TCP/IP. \citep{wiki_tcpip}}
\label{fig:prenos}
\end{figure}
Obrázek \ref{fig:prenos} znázorňuje, jak probíhá přenos dat prostřednictvím tří propojených sítí, kde jsou data směrována routery. Odesílací a přijímací zařízení se nachází v~různých síťích, a proto nejsou přímo propojena. Přenos dat je zajištěn prostřednictvím síťové vrstvy, která směruje pakety přes jednotlivé sítě. Přenos je na vrstvě síťového rozhraní realizován různými technologiemi.
% ==================================================================================================================
\section{Ethernet}
Ethernet je řada drátových síťových technologií, která je standardizována v~IEEE\footnote{Institute of Electrical and Electronics Engineers}~802.3. Ethernet umožňuje komunikaci zařízení v~lokální síťi pomocí MAC adres. Díky své jednoduchosti a nízké ceně se jedná o~nejrozšířenější technologii používanou v~lokálních síťích (LAN). \citep{ijs2_ethernet}
V~kontextu síťového modelu ISO/OSI pracuje na linkové vrstvě a fyzické vrstvě.
Na linkové vrstvě specifikuje formát rámců, detekci chyb a způsob adresování. Dříve ethernet využíval sdílené přenosové média, ke kterým linková vrstva řídila přístup (předcházela koliz9m a detekovala je). Dnešní ethernet je přepínaný (používají se přepínače) a v~přístupových síťích se používá topologie sítě strom. \citep{samuraj_ethernet} Vymizelo sdílení přenosového média, to má za výhodu odstranění kolizí a zvýšení rychlosti. \citep{samuraj_csma}
Na fyzické vrstvě IEEE 802.3 specifikuje typy přenosových médií (koaxiální kabel, kroudená dvojlinka, optické vlákno), použité konektory, přenosové rychlosti a signálové kódování.
\begin{figure}
\centering
\includegraphics[width=1\textwidth]{images/8021q.png}
\caption{Standartní ethernetový rámec a rozšířený rámec o~802.1Q. \citep{freeccna_vlan}}
\label{fig:ethernetframe}
\end{figure}
\pagebreak
V~horní části na obrázku \ref{fig:ethernetframe} je zobrazen znázorněn standardní ethernetový rámec. Je složen z:
\begin{itemize}
\item \textbf{Preambule}: Prvních 48 bitů slouží k~rozpoznání příchozího rámce na straně přijímacího zařízení. Obsahuje tuto sekvenci:\\\verb|10101010 10101010 10101010 10101010|\\\verb|10101010 10101010 10101010 10101011|. \citep{ieee_8023}
\item \textbf{SFD}: 8 bitů označuje konec preambule nebo také začátek samotného rámce.\\Obsahuje: \verb|10101011|. \citep{ieee_8023}
\item \textbf{Cílová adresa}: MAC adresa cílového zařízení.
\item \textbf{Zdrojová adresa}: MAC adresa odesílajícího zařízení.
\item \textbf{Délka/Typ}: Pokud je hodnota v~decimální soustavě měnší než 1500 označuje délku přenášených dat, pokud je větší neš 1500 označuje jaký protokol je přenášen na vyšší vrstvě. Seznam hodnot a protokolů spravuje IEEE.
\item \textbf{Data}: Obsahuje data z~vyšší síťové vrstvy.
\item \textbf{FCS}: Kontrolní CRC součet k~ověření správnosti přenosu rámce. Poškozené rámce jsou zahozeny.
\end{itemize}
\subsection{IEEE 802.1Q VLAN}
VLAN, neboli Virtual LAN slouží k~logickému rozdělení fyzické sítě. To zjednodušuje správu sítě. Díky možnosti vytvářet směrovací politiky pro různé skupiny zařízení a možnosti oddělení speciálního provozu (management sítě) se zvyšuje bezpečnost sítě. \citep{samuraj_vlan} VLAN je u~Ethernetu umožněno prostřednictvím standardu IEEE 802.1Q, který rozšiřuje standardní Ethernetový rámec o~další hodnoty.
V~dolní části obrázku \ref{fig:ethernetframe} je znázorněn ethernetový rámec dle IEEE 802.1Q rozšířený v~hlavičce o~32 bitů. Za zdrojovou adresu jsou vloženy následující hodnoty:
\begin{itemize}
\item \textbf{TPID}: Identifikátor použítého VLAN protokolu - v~případě IEEE~802.1Q obsahuje \verb|0x8100|. Je na stejné pozici jako Délka/Typ u~standartního rámce.
\item \textbf{PCP}: Označuje prioritu rámce podle IEEE 802.1P.
\item \textbf{CFI}: Říká jakým způsobem je přenášen rámec. Bud od bitu s~nejnižší hodnotou k~bitu s~nejvyšší nebo naopak. Pro ethernet \verb|0|. \citep{fair_vlan}
\item \textbf{VID}: Identifikátor (tag) konkrétní VLAN.
\end{itemize}
Aby bylo možné jednotlivé zařízení přiřazovat do různých logických sítí je nutné, aby IEEE~802.1Q podporovala zařízení ke terým jsou připojeny. Na zařízeních s~podporou IEEE~802.1Q lze nakonfigurovat do které logické sítě konkrétní port spadá a zda na daném portu má být použít tag či nikoli. Přepínače bez podbory IEEE~802.1Q přistupují k~tagovanému provozu stejně jako k~běžným rámcům. V~tomto kontextu může port zahňovat fyzický port i logické rozhraní, například síť Wi-Fi nebo konkrétní Wi-Fi klienty.
\textbf{Trunk port} je port, prostřednictvím kterého je přenášeno více logických síťí. Takto bývají propojeny směrovače s~přepínači, přepínače mezi sebou nebo přístupové body nabízejí-li více Wi-Fi síťí.
\textbf{Access port}\footnote{přístupová port} je port sloužící k~připojení jednotlivých zařízení. Provoz je bez IEEE~802.1Q tagu, tag bývá odchozímu provozu přiřazen na přepínači.
Vlán portu muže být přidělena staticky, podle MAC adresy zařízení, podle IP adresy zařízení nebo z~autorizačního serveru. \citep{samuraj_vlan}
\iffalse
\section{Taxonomie počítačových sítí}
Protože, je pojem počítačové sítě zcela obecný (síť lze realizovat libovolnou technologií), lze počítačové sítě děli na základě celé řady aspektů.
\subsection{Podle způsobu přepojování}
\begin{itemize}
\item Přepojování okruhů
\item Přepojování packetů
\end{itemize}
\subsection{Podle rozsahu sítě}
\begin{itemize}
\item PAN - Personal area network
jedná se o~osobní síť malého rozsahu (až v~řádech nízkých desítek metrů), slouží pro potřeby uživatele. Jaké PAN se označují sítě především tvořené nositelnou elektronikou. Bluetooth - přenost zvuku, dat
\item LAN - Local area network
Jedná se o~lokální sítě
\item MAN - metropolitan area network
\item WAN - wide area network
\end{itemize}
\fi
% ==================================================================================================================
\section{Základní síťové prvky}
Počítačové sítě jsou tvořeny technickými prostředky (síťovými prvky). \textbf{Pasivní síťové prvky} nemanipulují s~přenášenými daty a nezasahují do přenášených dat. Nevyžadují externí napájení. Aktivní síťové prvky vyžadují externí napájení a manipulují s~přenášenými daty a mohou do nich i zasahovat. \textbf{Aktivní síťové prvky} nabízejí různou funkcionalitu, podle které se dále rozlišují.
\textbf{Aktivní síťové prvky:}
\begin{itemize}
\item síťový adaptér,
\item přepínač (switch),
\item přístupový bod (access point),
\item směrovač (router).
\end{itemize}
Mezi dnes již málo používané aktivní síťové prvky lze zařadit:
\begin{itemize}
\item opakovač (repeater),
\item most (bridge).
\end{itemize}
\textbf{Pasivní síťové prvky:}
\begin{itemize}
\item kabeláž,
\item spojky,
\item pasivní rozdělovače,
\item konektory,
\item filtry.
\end{itemize}
% ==================================================================================================================
\section{802.1X}
802.1X je standard vydaný organizací IEEE\footnote{Institute of Electrical and Electronics Engineers} pro zabezpečení přístupu do sítě. Tento standard zvyšuje bezpečnost tím, že zajišťuje autorizaci uživatelů sítě. Přístup je kontrolován na linkové vrstvě ISO/OSI modelu.
\begin{figure}
\centering
\includegraphics[width=0.8\textwidth]{images/radius.png}
\caption{Průběh 802.1X / RADIUS autentizace. \citep{stankus_8021x}}
\label{fig:radius}
\end{figure}
V~architektůře autentizace pomocí IEEE 802.1X jsou tři hlavní prvky. Prvním je samotný klient (tzv. suplikant), druhý je switch/přístupový bod (autentizátor) a třetím je autentizační server.
Suplikant komunikuje s~autentizačním serverem pomocí EAP (Extensible Authentication Protocol) zpráv, které jsou specifikovány RFC 2284. Pro přenos EAP v~prostředí Ethernetu slouží EAPoE (EAP over Ethernet), kde EAP rámce používají EtherType \verb|0x888E|. Komunikace mezi Suplikantem a autentizátorem probíhá pouze na L2 vrstvě ISO/OSI modelu. autentizátor EAP zprávy od klienta (suplikanta) neinterpretuje, zabalí je do dalšího protokolu a přepošle je autentizačnímu serveru přes IP síť.
Autentizátor komunikuje s~autentizačním serverem pomocí jednoho z~AAA\footnote{Authentication, Authorization, Accounting - autentizace, autorizace, účtování} protokolů. Tyto protokoly se \textit{používájí pro zajištění zabezpečení síťové infrastruktury} \citep{lesek_8021x}. Mezi nejvíce používané patří RADIUS, TACACS, TACACS+, KERBEROS a DIAMETER. \citep{stankus_8021x}. Autentizační server ověřuje EAP zprávy a odpovídá autentizátoru, který na základě těchto odpovědí upravuje přístupk suplikanta k~síti a přeposílá příslušné EAP odpovědi suplikantovi. Komunikace mezi Autentizátorem a autentizačním serverem probíhá na úrovní aplikační vrstvy.
Proces autorizace klienta pomocí RADIUS serveru je znázorněn na obrázku \ref{fig:radius}.Po připojení klienta (suplikanta) do sítě je veškerý síťový provoz na portu blokován, dokud není dokončena autentizace Autentizátor akceptuje pouze EAPoL zprávy. Klient (suplikant) zahájí komunikaci s~autentizátorem \textbf{EAPoL-Start}, kterou zahájí autentizační proces. Autentizátor vyzve klienta (suplikant) zprávou \textbf{EAP-Request/Identity} ke sdělení identity. Klient odpoví zprávou \textbf{EAP-Response/Identity}, která obsahuje jeho identifikaci (například uživatelské jméno). Tuto zprávu autentizátor předá autentizačnímu serveru jako \textbf{RADIUS Access-Request}. V~tomto protokolu je zapouzdřena EAP zpráva. \citep{cuhel_8021x}
Autentizační server může odpovědět výzvou k~zadání dalšího ověření (hesla) pomocí \textbf{RADIUS Access-Challenge}, tento proces pokračuje dokud server neověří klientovu identitu. Po úspěšném ověření identity server odpoví zprávou \textbf{RADIUS Access-Challenge}, kterou autentizátor předá jako \textbf{EAP-Success} a povolí klientovi přístup k~síti. \citep{lesek_8021x}
Identita uživatele je uložena v~databázi autentizačního serveru, v~externí databázi, v~systému pro správu identit, nebo na jiném autentizačním serveru.
EAP nezajišťuje šifrování ani ochranu přenášených dat. Toto mají na starosti konkrétní autentizační metody. Mezi nejrozšířenější metody patří:
\begin{itemize}
\item \textbf{EAP-TLS}: používá pro vzájemnou autentizaci certifikáty klienta a serveru.
\item \textbf{PEAP}: Vytváří šifrovaný tunel TLS, uvnitř tunelu probíhá sekundární autentizace npř. pomocí MS-CHAPv2. Vyžaduje certifikát pouze na straně serveru.
\item \textbf{EAP-TTLS}: Funguje podobně jako PEAP, nabízí více možností sekundární autentizace (PAP, CHAP, nebo MS-CHAPv2). \citep{networkencyclopedia_eap}
\end{itemize}
% ------------------------------------------------------------------------------------------------------------------
\subsection{eduroam}
eduroam je mezinárodní projekt s~cílem umožnit studentům a pracovníkům vzdělávacích a výzkumných institucí jednoduchý, bezpečný a spolehlivý přístup k~veřejné síti Internet v~parcipiující institucích kdekoli na světě. Parcipiující instituce využívají jednotný identifikátor Wi-Fi sítě \verb|eduroam|. Přístup k~internetu je zařízením umožněň pomocí Wi-Fi nebo ethernetového rozhraní. eduroam využívá specifikace 802.1X pro udělení či zamítnutí přístupu.
\begin{figure}
\centering
\includegraphics[width=0.5\textwidth]{images/hierachicka_infrastruktura.png}
\caption{Hierachické uspořádání autentizačních serverů. \citep{eduroam_realm}}
\label{fig:eduroam}
\end{figure}
K~tomu využívá hierachické uspořádání auntetizačních serverů RADIUS (obrázek \ref{fig:eduroam}), kde každá instituce spravující své identity provozuje svůj autentizační server.
Tímto se snaží napodobit roaming (přepnutí ze síťě jednoho operátora do sítě jiného operátora) v~celulárních síťích.

View File

@@ -1,7 +1,42 @@
\chapter{Hromadná správa zařízení}
\chapter{Automatizace konfigurace}
...
Konfigurační management, jakožto obor systémového inženýrství, byl vyvinut již v~50. letech 20. století ministerstvem obrany Spojených států. Sloužil jako metoda pro sledování změn v~komplexních systémech jako jsou zbraňové systémy nebo vojenská vozidla. Každá změna v~systému musela být zaznamenána včetně dokumentace, která uváděla, kdo změnu provedl a z~jakého důvodu. Cílem bylo zajistit, že stav systému bude v~kterémkoli okamžiku známý a zpětně dohledatelný. Stejná praxe byla aplikována i na počítačové systémy. Původně se dokumentovaly změny provedené v~čase. Nové softwarové nástroje umožnily přejít od dokumentace provedených změn k~definování požadovaného stavu systému. \citep{HeapAnsible}
\subsection{Přístupy}
S~narůstajícím využíváním virtualizace, kontejnerizace a komplexností počítačových systémů, tedy s~narůstajícím počtem zařízení vyžadující určitou konfiguraci implementovaly tyto nástroje i automatizaci konfigurace spravované infrastruktury. Tento přístup se nazývá \textbf{Infrastructure as Code} (IaC), tedy infrastruktura jako kód. V~tomto modelu je požadovaná konfigurace infrastruktury zapsána ve strojově čitelném formátu v~souboru, podle kterého následně softwarové nástroje automaticky konfigurují jednotlivé prvky infrastruktury.
Díky zápisu požadované konfigurace se eliminuje lidská chyba při konfiguraci více zařízení a zvýší se homogennost konfigurace napříč infrastrukturou. S~použitím verzovacího systému lze umožnit verzování infrastruktury, týmovou spolupráci nad konfigurací s~důrazem na auditovatelnost konfigurace a dohledatelnost historických změn. Toto zvyšuje bezpečnost.
Automatizace konfigurace rozsáhlé infrastruktury zvýší efektivitu, ušetří čas a umožní snadnou škálovatelnost. \citep{leanDeliveryIaC}
...
\pagebreak
Existuje několik známých open-source nástrojů pro správu infrastruktury jako kódu, každý se svými specifiky a způsob správy. Mezi nejpoužívanější opensource nástroje patří \textbf{Ansible\footnote{\url{https://www.ansible.com/}}}, \textbf{Chef\footnote{\url{https://www.chef.io/}}}, \textbf{Puppet\footnote{\url{https://www.puppet.com/}}} a \textbf{SaltStack\footnote{\url{https://saltproject.io/}}} \citep[p.~841]{Nemeth_Evi_2018}.
\begin{longtable}[c]{|p{3.5cm}|p{2.5cm}|p{2.5cm}|p{2.5cm}|p{2.5cm}|}
\caption{Nástroje pro automatizaci správy infrastruktury}
\label{tab:DevOpsTools}\\
\hline
\multicolumn{1}{|c|}{} &
\multicolumn{1}{c|}{\textbf{Ansible}} &
\multicolumn{1}{c|}{\textbf{Chef}} &
\multicolumn{1}{c|}{\textbf{Puppet}} &
\multicolumn{1}{c|}{\textbf{SaltStack}} \\ \hline
\endfirsthead
%
\endhead
%
Programovací jazyk nástroje & Python & Ruby & C++, Clojure & Python \\ \hline
Jazyk pro konfiguraci & YAML, JSON & Ruby & Vlastní jazyk & YAML \\ \hline
Způsob zápisu konfigurace & Procedurální/Deklarativní & Procedurální & Deklarativní & Deklarativní \\ \hline
Architektura & Agentless\footnote{nevyžaduje speciální software na spravovaném zařízení} & Server/client & Server/client, Agentless\footnote{\url{https://www.puppet.com/community/open-source/bolt}} & Server/client, Agentless\footnote{\url{https://docs.saltproject.io/salt/user-guide/en/latest/topics/salt-ssh.html}} \\ \hline
Model získání konfigurace & Push\footnote{konfigurace je na zařízení zaslána} & Pull\footnote{zařízení stahuje konfiguraci ze serveru} & Pull / Push & Push \\ \hline
Způsob přenosu konfigurace & SSH & HTTP(S) & MCollective, HTTPS & ZeroMQ \\ \hline
\end{longtable}
\section{Přístupy k~zápisu konfigurace}
Existují dvě základní paradigmata zápisu konfigurace.
\textbf{Imperativní (procedurální)} zápis definuje jednotlivé kroky, které mají být provedeny v~přesném pořadí, pro dosažení požadovaného stavu infrastruktury.
\textbf{Deklarativní} zápis popisuje požadovaný stav infrastruktury, tedy jaký má být cílený stav. Jedná se deklarativní abstrakci kdy dosažení cílové konfigurace je implementovány imperativně. Nástroj pro automatizaci konfigurace vyhodnotí aktuální stav a provede pouze nezbytné kroky k~dosažení cílového stavu.

View File

@@ -1,6 +1,8 @@
\chapter{Sada standardů Wi-Fi}
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc et pharetra dui. Morbi nec leo vulputate, suscipit sem quis, ultrices purus. Vestibulum eget ultricies sem. Cras mattis dapibus ipsum, at pulvinar leo blandit a. Integer posuere semper mi vehicula rhoncus. Fusce lacinia neque vel ipsum sagittis semper. Nulla cursus enim eu purus dignissim, vitae posuere diam tincidunt. Nulla at magna ultrices, ultrices justo tincidunt, iaculis erat. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Fusce et odio lobortis, lacinia orci quis, placerat augue. Proin posuere ante in quam hendrerit lacinia eu sed nunc. Sed varius libero fermentum magna facilisis, sed porta felis suscipit. \citep{commonmark}
S~masivním rozvojem technologií, s~rozvojem a dostupností nositelné elektroniky pro běžné uživatele vznikla poptávka po bezdrátovém přenosu dat.
IEEE v~roce ... zveřejnila RFC xxx jako reakci na potřebu uživatelů přenášet ethernetové rámce bezdrátově. Následně vznikla organizace wi-fi aliance, která začala zařízení implemntující tuto sadu standardů testovat a certifikovat. Odtud pochází název, který se pro příslušné standardy celosvětově uchytil. Tyto standardy řeší samotné mechanismy přenosu dat, autentifikaci a další podpůrné funkce npř. roaming.
\subsection{Historický vývoj}
@@ -12,8 +14,12 @@ Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc et pharetra dui. M
\subsection{Modulace, kódování, přístupové medody}
...
Technologie Wi-Fi využívá ke svému fungování elektromagnetické spektrum. Data přijata z~vyžší vrstvy jsou kódována a následně je provedena modulace -> převod na analogový signál. a odvysílána rádiem.
Protože je elektromagnetické spektrum sdílené médium, je nutné zamezit vysílání více zařízení v~jeden moment. Souboru těchto technik se říká přístupové metody.
\subsection{Autentifikační metody a bezpečnost}
Curabitur mollis metus a risus finibus, et tincidunt leo facilisis. Nulla vitae hendrerit ligula, a venenatis neque. Proin malesuada, nulla id laoreet tempor, orci turpis convallis arcu, id hendrerit purus nunc in neque. Nullam congue dui magna, vitae maximus velit pulvinar at. Pellentesque tempor ligula a magna fermentum, in facilisis turpis rutrum. Morbi mattis massa ligula, quis porta sapien convallis vel. Curabitur eros lorem, imperdiet sed leo vitae, egestas tempus dolor. Vestibulum dignissim id metus et venenatis.
z~důvodu využití sdíleného média je vhodné ve wi-fi sítích řešit šifrování přenášených dat.
V~dokumentu RFC xxx jsou definovány metody pro šifrování samotného přenosu.

View File

@@ -1,11 +1,18 @@
\chapter{Zhodnocení modelové implementace}
...
V~této kapitole je zhodnocena modelová implementace sítě z~kapitoly \ref{ch:implemetace}.
Správa infrastruktury přístupových bodů pomocí nástroje Asible se při modelové implementaci na testovacích síťových prvcích ukázala jako plnohodnoťně funkční. Síťoví administrátoři ocení úsporu času při konfiguraci (zejména při pridávání nových přístupvých bodů) a konzistentní konfiguraci napříč infrastrukturou. Ansible je flexibilní nástroj pro konfiguraci, což může být nevýhodnou pro administrátory, kteří tento nástroj neznají, protože zápis konfigurace není tak uživatelsky přívětivý jako konfigurace pomocí GUI.
\subsection{Funkce sítě}
Logování nevyužívá žádné pokročilé analytické nástroje, ale všechny podstatné inforamce o~infrastruktuře jsou uloženy a jsou dohledatelné.
...
Učitou výhodou může být i to, že obě klíčové komponenty eduroam sítě (přístupové body a RADIUS server) je možné konfigurovat deklarativním způsobem pomocí Ansible.
\subsection{Komparace s~dostupnými proprietárními řešeními}
% \section{Komparace s~dostupnými proprietárními řešeními}
...
\section{Návrhy na vylepšení systému}
Jedním z~klíčových navrhovaných vylepšení je automatizace procesu aktualizace firmwaru přístupových bodů. Tento proces se musí v~modelové implementaci provádět manuálně, což může představovat bezpečnostní riziko. Toto lze vyřešit přidáním role do Ansible, která provede lokální kompilaci systému OpenWrt pro jednotlivé modely přístupových bodů v~síti. Sestavený systém lze potom pomocí Ansible nahrát do paměti zařízení.
Dalším nutným vylepšením pro následující provoz infrastruktury je přidání modulu pro instalaci balíčků pomocí správce balíků \verb|apk|\footnote{\url{https://docs.alpinelinux.org/user-handbook/0.1a/Working/apk.html}} z~projektu Alpine linux. Na správce balíků \verb|apk| bude systém OpenWrt v~příštím vydání přecházet. \verb|opkg| byl označek za zastaralý.\citep{openwrtAPK} Buď na tuto změnu zareaguje správce projektu ansible-openwrt\footnote{\url{https://github.com/flyoverhead/ansible-openwrt}} nebo bude nutné tento projekt
Tyto Vylepšení zajistí dlouhodobou urdžitelnost a bezpečnost sítě.

44
default.txt Normal file
View File

@@ -0,0 +1,44 @@
...
authorize {
# Zalogování požadavku, před jakoukoli změnou
linelog_recv_request
...
post-auth {
...
# Zalogování úspěšné autentizace
linelog_send_accept
Post-Auth-Type REJECT {
...
# Zalogování neúspěšné autentizace
linelog_send_reject
}
...
}
...
pre-proxy {
...
# Zalogování požadavku do jiné instituce
linelog_send_proxy_request
}
post-proxy {
...
# Zalogování požadavku přijatého z jiné instituce
linelog_recv_proxy_response
}
}

BIN
images/8021q.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 42 KiB

BIN
images/osi-tcpip.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 88 KiB

BIN
images/radius.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 74 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 260 KiB

BIN
images/tcpip_komunikace.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 100 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 142 KiB

View File

@@ -1,28 +0,0 @@
\relax
\providecommand\hyper@newdestlabel[2]{}
\@setckpt{chapters/ipsum}{
\setcounter{page}{2}
\setcounter{equation}{0}
\setcounter{enumi}{0}
\setcounter{enumii}{0}
\setcounter{enumiii}{0}
\setcounter{enumiv}{0}
\setcounter{footnote}{0}
\setcounter{mpfootnote}{0}
\setcounter{part}{0}
\setcounter{chapter}{0}
\setcounter{section}{0}
\setcounter{subsection}{0}
\setcounter{subsubsection}{0}
\setcounter{paragraph}{0}
\setcounter{subparagraph}{0}
\setcounter{figure}{0}
\setcounter{table}{0}
\setcounter{Item}{0}
\setcounter{Hfootnote}{0}
\setcounter{bookmark@seq@number}{0}
\setcounter{parentequation}{0}
\setcounter{NAT@ctr}{0}
\setcounter{@todonotes@numberoftodonotes}{0}
\setcounter{section@level}{0}
}

39
linelog.txt Normal file
View File

@@ -0,0 +1,39 @@
linelog linelog_recv_request {
filename = syslog
syslog_facility = local0
syslog_severity = debug
format = "action = Recv-Request, %{pairs:request:}"
}
linelog linelog_send_accept {
filename = syslog
syslog_facility = local0
syslog_severity = debug
format = "action = Send-Accept, %{pairs:request:}"
}
linelog linelog_send_reject {
filename = syslog
syslog_facility = local0
syslog_severity = debug
format = "action = Send-Reject, %{pairs:request:}"
}
linelog linelog_send_proxy_request {
filename = syslog
syslog_facility = local0
syslog_severity = debug
format = "action = Send-Proxy-Request, %{pairs:proxy-request:}"
}
linelog linelog_recv_proxy_response {
filename = syslog
syslog_facility = local0
syslog_severity = debug
reference = "messages.%{proxy-reply:Response-Packet-Type}"
messages {
Access-Accept = "action = Recv-Proxy-Accept, User-Name = %{User-Name}, Calling-Station-Id = %{Calling-Station-Id}, %{pairs:proxy-reply:}"
Access-Reject = "action = Recv-Proxy-Reject, User-Name = %{User-Name}, Calling-Station-Id = %{Calling-Station-Id}, %{pairs:proxy-reply:}"
Access-Challenge = "action = Recv-Proxy-Challenge, User-Name = %{User-Name}, Calling-Station-ID = %{Calling-Station-Id}, %{pairs:proxy-reply:}"
}
}

View File

@@ -1,28 +0,0 @@
\relax
\providecommand\hyper@newdestlabel[2]{}
\@setckpt{chapters/lorem}{
\setcounter{page}{2}
\setcounter{equation}{0}
\setcounter{enumi}{0}
\setcounter{enumii}{0}
\setcounter{enumiii}{0}
\setcounter{enumiv}{0}
\setcounter{footnote}{0}
\setcounter{mpfootnote}{0}
\setcounter{part}{0}
\setcounter{chapter}{0}
\setcounter{section}{0}
\setcounter{subsection}{0}
\setcounter{subsubsection}{0}
\setcounter{paragraph}{0}
\setcounter{subparagraph}{0}
\setcounter{figure}{0}
\setcounter{table}{0}
\setcounter{Item}{0}
\setcounter{Hfootnote}{0}
\setcounter{bookmark@seq@number}{0}
\setcounter{parentequation}{0}
\setcounter{NAT@ctr}{0}
\setcounter{@todonotes@numberoftodonotes}{0}
\setcounter{section@level}{0}
}

3
nfdump Normal file
View File

@@ -0,0 +1,3 @@
$ nfdump -R flows/ -t "2024/11/11.20:00:00-infinity" \
-o "fmt:%ts %td %pr %sap -> %dap %pkt %byt %ismc -> %odmc %idmc -> %osmc" \
"dst ip <cílová IP adresa> and src port <zdrojový port>"

View File

@@ -73,15 +73,15 @@
</rdf:Description>
<rdf:Description rdf:about="" xmlns:xmp="http://ns.adobe.com/xap/1.0/">
<xmp:CreatorTool>LaTeX with hyperref</xmp:CreatorTool>
<xmp:ModifyDate>2024-01-19T00:53:22+01:00</xmp:ModifyDate>
<xmp:CreateDate>2024-01-19T00:53:22+01:00</xmp:CreateDate>
<xmp:MetadataDate>2024-01-19T00:53:22+01:00</xmp:MetadataDate>
<xmp:ModifyDate>2024-11-27T10:23:40+01:00</xmp:ModifyDate>
<xmp:CreateDate>2024-11-27T10:23:40+01:00</xmp:CreateDate>
<xmp:MetadataDate>2024-11-27T10:23:40+01:00</xmp:MetadataDate>
</rdf:Description>
<rdf:Description rdf:about="" xmlns:xmpRights = "http://ns.adobe.com/xap/1.0/rights/">
</rdf:Description>
<rdf:Description rdf:about="" xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/">
<xmpMM:DocumentID>uuid:E471EDA9-0143-B4EC-2929-27CBFE26697B</xmpMM:DocumentID>
<xmpMM:InstanceID>uuid:C682FD51-F28C-9C86-49D6-D877457AC376</xmpMM:InstanceID>
<xmpMM:InstanceID>uuid:666EEE3A-6688-736A-1BA1-1F68FF4A39E4</xmpMM:InstanceID>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>

View File

@@ -1,6 +1,8 @@
\vglue 0pt plus 1fill
Poděkování
Děkuji především svému vedoucímu PhDr. Martinu Stejskalovi za vstřícnost a trpělivost během zpracování této práce.
Zároveň děkuji bc. Emilovi Milerovi za náměty, vylepšení, korekturu a také svému otci za nekonečnou podporu během psaní této práce.
\vspace{20mm}
\newpage

191
prace.bbl
View File

@@ -1,13 +1,194 @@
\begin{thebibliography}{1}
\begin{thebibliography}{30}
\providecommand{\natexlab}[1]{#1}
\providecommand{\url}[1]{\texttt{#1}}
\expandafter\ifx\csname urlstyle\endcsname\relax
\providecommand{\doi}[1]{doi: #1}\else
\providecommand{\doi}{doi: \begingroup \urlstyle{rm}\Url}\fi
\bibitem[MacFarlane(2019)]{commonmark}
{\sc MacFarlane}, J.
\newblock \emph{CommonMark Spec} [online]. 2019. [cit.~2020-03-22].
\newblock Dostupn{\'{e}}~z: \url{{https://spec.commonmark.org/}}.
\bibitem[ijs()]{ijs2_ethernet}
\emph{Ethernet} [online].
\newblock Dostupn{\'{e}}~z:
\url{{http://ijs2.8u.cz/index.php?option=com_content&view=article&id=20&Itemid=125}}.
\bibitem[Appnel(2023)]{ZenofAnsible}
{\sc Appnel}, T.
\newblock \emph{The Zen of Ansible} [online]. 2023.
\newblock Dostupn{\'{e}}~z:
\url{{https://www.ansible.com/blog/the-zen-of-ansible/}}.
\bibitem[Bouška(2007{\natexlab{a}})]{samuraj_csma}
{\sc Bouška}, P.
\newblock \emph{Ethernet - CSMA/CD, kolizní doména, duplex} [online].
2007{\natexlab{a}}.
\newblock Dostupn{\'{e}}~z:
\url{{https://www.samuraj-cz.com/clanek/ethernet-csma-cd-kolizni-domena-duplex/}}.
\bibitem[Bouška(2007{\natexlab{b}})]{samuraj_ethernet}
{\sc Bouška}, P.
\newblock \emph{TCP/IP a ethernet - cesta v síti, aktivní síťové prvky}
[online]. 2007{\natexlab{b}}.
\newblock Dostupn{\'{e}}~z:
\url{{https://www.samuraj-cz.com/clanek/tcp-ip-a-ethernet-cesta-v-siti-aktivni-sitove-prvky/}}.
\bibitem[Bouška(2007{\natexlab{c}})]{samuraj_vlan}
{\sc Bouška}, P.
\newblock \emph{VLAN - Virtual Local Area Network} [online].
2007{\natexlab{c}}.
\newblock Dostupn{\'{e}}~z:
\url{{https://www.samuraj-cz.com/clanek/vlan-virtual-local-area-network/}}.
\bibitem[Crowder(2023)]{crowder_firmwarecomp}
{\sc Crowder}, C.
\newblock \emph{DD-WRT vs. Tomato vs. OpenWRT: Which Router Firmware Is the
Best?} [online]. 2023.
\newblock Dostupn{\'{e}}~z:
\url{{https://www.maketecheasier.com/dd-wrt-vs-tomato-vs-openwrt-router-firmware/}}.
\bibitem[eduroam.cz(2024)]{eduroam_certifikaty}
{\sc eduroam.cz}.
\newblock \emph{Certifikaty} [online]. 2024.
\newblock Dostupn{\'{e}}~z:
\url{{https://www.eduroam.cz/cs/spravce/pripojovani/serverove_certifikaty}}.
\bibitem[eduroam.cz(2019)]{eduroam_realm}
{\sc eduroam.cz}.
\newblock \emph{Realm} [online]. 2019.
\newblock Dostupn{\'{e}}~z:
\url{{https://www.eduroam.cz/cs/spravce/pripojovani/realm}}.
\bibitem[Fairhurst(2012)]{fair_vlan}
{\sc Fairhurst}, G.
\newblock \emph{Advanced VLANs} [online]. 2012.
\newblock Dostupn{\'{e}}~z:
\url{{https://erg.abdn.ac.uk/users/gorry/course/lan-pages/vlan-advanced.html}}.
\bibitem[FreeCCNAStudyGuide.com()]{freeccna_vlan}
{\sc FreeCCNAStudyGuide.com}.
\newblock \emph{7-4 VLAN Trunking: ISL and 802.1Q} [online].
\newblock Dostupn{\'{e}}~z:
\url{{https://www.freeccnastudyguide.com/study-guides/ccna/ch7/7-4-vlan-trunking-isl-802-1q/}}.
\bibitem[Heap(2016)]{HeapAnsible}
{\sc Heap}, M.
\newblock \emph{Ansible: From beginner to pro}.
\newblock Apress, ISBN: 978-1-4842-1659-0, 2016.
\bibitem[Hofstede et~al.(2014)Hofstede, Čeleda, Trammell, Drago, Sadre,
Sperotto,, Pras]{Hofstede2014}
{\sc Hofstede}, R. et~al.
\newblock Flow monitoring explained: from packet capture to data analysis with
NetFlow and IPFIX, doi: 10.1109/COMST.2014.2321898, 2014.
\bibitem[IEEE(2018)]{ieee_8023}
{\sc IEEE}.
\newblock \emph{802.3-2018 - IEEE Standard for Ethernet} [online]. 2018.
\newblock Dostupn{\'{e}}~z:
\url{{https://ieeexplore.ieee.org/document/8457469}}.
\bibitem[kernel.org()]{LinuxDSA}
{\sc kernel.org}.
\newblock \emph{Distributed Switch Architecture (DSA)} [online].
\newblock Dostupn{\'{e}}~z:
\url{{https://docs.kernel.org/networking/dsa/dsa.html}}.
\bibitem[Lešek(2019)]{lesek_8021x}
{\sc Lešek}, V.
\newblock \emph{Autentizace v lokálních sítích pomocí IEEE 802.1x}
[online]. 2019.
\newblock Dostupn{\'{e}}~z:
\url{{https://dspace.cvut.cz/bitstream/handle/10467/82727/F3-BP-2019-Lesek-Vladimir-Autentizace%20v%20lokalnich%20sitich%20pomoci%20IEEE%20802.1x.pdf?sequence=-1&isAllowed=y}}.
\bibitem[Maiseyeu(2019)]{leanDeliveryIaC}
{\sc Maiseyeu}, A.
\newblock \emph{Dawn of the Infrastructure as Code} [online]. 2019.
\newblock Dostupn{\'{e}}~z:
\url{{https://lean-delivery.com/2019/12/infrastructure_as_code.html}}.
\bibitem[Nemeth~Evi(2008)]{Nemeth_Evi_2008}
{\sc Nemeth~Evi}, H. T.~R.~S.~G.
\newblock \emph{Linux : kompletní příručka administrátora}.
\newblock Computer Press, ISBN: 978-80-251-2410-9, 2008.
\bibitem[Nemeth~Evi(2018)]{Nemeth_Evi_2018}
{\sc Nemeth~Evi}, H. T.~R.~S.~G.
\newblock \emph{Unix and Linux system administration handbook}.
\newblock Addison-Wesley, ISBN: 978-01-342-7755-4, 2018.
\bibitem[networkencyclopedia.com(2024)]{networkencyclopedia_eap}
{\sc networkencyclopedia.com}.
\newblock \emph{Decoding EAP Protocol: A Guide to Extensible Authentication}
[online]. 2024.
\newblock Dostupn{\'{e}}~z:
\url{{https://networkencyclopedia.com/decoding-eap-protocol-a-guide-to-extensible-authentication/}}.
\bibitem[OpenWrt(2024)]{OpenWrtDoc8021X}
{\sc OpenWrt}, P.
\newblock \emph{Introduction to 802.1X} [online]. 2024.
\newblock Dostupn{\'{e}}~z:
\url{{https://openwrt.org/docs/guide-user/network/wifi/wireless.security.8021x}}.
\bibitem[OpenWrt(2021)]{OpenWrtDocFAQ}
{\sc OpenWrt}, P.
\newblock \emph{FAQ before installing OpenWrt} [online]. 2021.
\newblock Dostupn{\'{e}}~z:
\url{{https://openwrt.org/docs/guide-user/installation/before.installation#what_is_the_difference_between_the_different_image_formats}}.
\bibitem[Peterka(1992)]{peterka_tcpip}
{\sc Peterka}, J.
\newblock \emph{Síťový model TCP/IP} [online]. 1992.
\newblock Dostupn{\'{e}}~z: \url{{https://www.earchiv.cz/a92/a231c110.php3}}.
\bibitem[Peterson -- Davie(2022)Peterson, Davie]{Peterson_Davie_2022}
{\sc Peterson}, L.~L. -- {\sc Davie}, B.~S.
\newblock \emph{Computer Networks: A Systems Approach}.
\newblock Morgan Kaufmann Publishers, an imprint of Elsevier, ISBN:
978-0-1238-5059-1, 2022.
\bibitem[Ram(2024)]{RamsTech}
{\sc Ram}.
\newblock \emph{Monitoring and Visualization Options for OpenWRT} [online].
2024.
\newblock Dostupn{\'{e}}~z:
\url{{https://nramkumar.org/tech/blog/2024/06/21/monitoring-and-visualization-options-for-openwrt/}}.
\bibitem[Sherman(2024)]{openwrtAPK}
{\sc Sherman}.
\newblock Major Change Notice: New Package Manager, 2024.
\newblock Dostupn{\'{e}}~z:
\url{{https://forum.openwrt.org/t/major-change-notice-new-package-manager/215682}}.
\bibitem[Stankuš(2007)]{stankus_8021x}
{\sc Stankuš}, M.
\newblock \emph{Autentizace, autorizace a accounting v prostředí IEEE 802.1X}
[online]. 2007.
\newblock Dostupn{\'{e}}~z:
\url{{http://www.cs.vsb.cz/grygarek/SPS/projekty0607/RADIUS-Stankus.pdf}}.
\bibitem[Twain(2024)]{twain_compare}
{\sc Twain}, K.
\newblock \emph{DD-WRT vs OpenWrt: The Better Router Firmware in 2024?}
[online]. 2024.
\newblock Dostupn{\'{e}}~z:
\url{{https://www.homeowner.com/connectivity/routers/dd-wrt-vs-openwrt}}.
\bibitem[Wikipedie(2008)]{wiki_tcpip}
{\sc Wikipedie}.
\newblock \emph{TCP/IP} [online]. 2008.
\newblock Dostupn{\'{e}}~z: \url{{https://cs.wikipedia.org/wiki/TCP/IP}}.
\bibitem[Česko()]{Zak_El_Kom}
{\sc Česko}.
\newblock § 97 odst. 3 zákona č. 127/2005 Sb., o elektronických
komunikacích a o změně některých souvisejících zákonů (zákon o
elektronických komunikacích) - znění od~1.~1.~2024.
\newblock Dostupn{\'{e}}~z:
\url{{https://www.zakonyprolidi.cz/cs/2005-127#p97-3}}.
\bibitem[Čuhel(2020)]{cuhel_8021x}
{\sc Čuhel}, R.
\newblock \emph{Řízení přístupu k lokální síti pomocí protokolu IEEE
802.1x} [online]. 2020.
\newblock Dostupn{\'{e}}~z:
\url{{https://www.vut.cz/www_base/zav_prace_soubor_verejne.php?file_id=210204}}.
\end{thebibliography}

View File

@@ -16,6 +16,17 @@
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{xcolor}
\usepackage{listings}
\renewcommand{\lstlistingname}{Kód}
\lstset{basicstyle=\footnotesize,
numbers=left,
numberstyle=\tiny,
captionpos=b,
frame=single,
breaklines=true,
postbreak=\mbox{{$\hookrightarrow$}\space}
}
\usepackage{longtable}
% Typography
\setlength{\parindent}{0pt}
@@ -42,9 +53,17 @@
\deffootnote[1em]{3em}{1em}{\textsuperscript{\thefootnotemark}}
\setlength{\footnotesep}{0.5cm}
\renewcommand{\footnoterule}{\vfill\kern -3pt \hrule width 0.4\columnwidth \kern 2.6pt}
\let\oldFootnote\footnote
\newcommand\nextToken\relax
\renewcommand\footnote[1]{%
\oldFootnote{#1}\futurelet\nextToken\isFootnote}
\newcommand\isFootnote{%
\ifx\footnote\nextToken\textsuperscript{,}\fi}
\def\Title{Nasazení, správa a monitoring rozsáhlých přístupových Wi-Fi sítí s~využitím open-source technlogií}
\def\Title{Nasazení, správa a monitoring rozsáhlých přístupových Wi-Fi sítí s~využitím open-source technologií}
\def\TitleEN{Deployment, management and monitoring of large-scale access Wi-Fi networks using open-source technologies}
\def\Author{David Zálešák}
\def\Study{Specializace v~pedagogice}
@@ -63,9 +82,8 @@
\tableofcontents
\include{uvod}
\input{chapters/wifi}
\input{chapters/site}
\input{chapters/hardware}
\input{chapters/wifi}
\input{chapters/sprava}
\input{chapters/pozadavky}
\input{chapters/implementace}

105
ucidefaults.sh Normal file
View File

@@ -0,0 +1,105 @@
#!/bin/sh
root_password="Jednokolka"
ssh_key_rsa="ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILQqqspfQuf2aNIbu6riGMTU3g5ZRcKgnRUqDSHe3/VU pixx@desktop"
. /lib/functions.sh
. /usr/share/libubox/jshn.sh
delete_wireless() {
local name="$1"
uci -q del wireless."$name"
}
delete_network() {
local name="$1"
if [[ $name != "loopback" ]]; then
uci -q del network."$name"
fi
}
# log potential errors
exec >/tmp/setup.log 2>&1
#odstraneni vychozi konfigurace
config_load wireless
config_foreach delete_wireless wifi-iface
config_load network
config_foreach delete_network interface
config_foreach delete_network device
#ziskani puvodniho wan rozhrani
json_load_file /etc/board.json
json_select "network"
if json_is_a "wan" object; then
json_select "wan"
else
json_select "lan"
fi
json_get_var wan_device "device"
#ziskani nastaveni switche
json_select ..
json_select ..
if json_is_a "switch" object; then
echo "not DSA"
json_get_keys keys switch
json_select "switch"
for key in $keys; do
json_select $key
json_select "roles"
idx=1
while json_is_a $idx object
do
json_select $idx
json_get_var device "device"
if [[ $device == $wan_device ]]; then
json_get_var ports "ports"
ports=$(echo $ports | sed -r 's/\b([0-9]+)\b/\1t/g')
switchid=$key
fi
idx=$(( idx + 1 ))
json_select ..
done
done
else
echo "is DSA"
fi
wan_device=$(echo $wan_device | sed -r 's/\..*$|$/\.99/g')
#nastavení switche
if [ ! -z ${ports+x} ]; then
config_foreach delete_network switch_vlan
uci add network switch_vlan
uci set network.@switch_vlan[-1].device="${switchid}"
uci set network.@switch_vlan[-1].vlan='99'
uci set network.@switch_vlan[-1].ports="${ports}"
uci set network.@switch_vlan[-1].vid='99'
uci set network.@switch_vlan[-1].description='mgmnt'
fi
#vytvoreni sitoveho rozhrani pro management
uci set network.mgmnt=interface
uci set network.mgmnt.proto='dhcp'
uci set network.mgmnt.device=${wan_device}
#nastaveni root hesla
if [ -n "$root_password" ]; then
(echo "$root_password"; sleep 1; echo "$root_password") | passwd > /dev/null
fi
#nastaveni ssh
uci -q set dropbear.@dropbear[0].PasswordAuth='off'
uci -q set dropbear.@dropbear[0].RootPasswordAuth='off'
if [ -n "$ssh_key_rsa" ]; then
echo $ssh_key_rsa >> /etc/dropbear/authorized_keys
fi
uci commit network
uci commit wireless
uci commit dropbear
echo "All done!"

View File

@@ -2,7 +2,11 @@
\addcontentsline{toc}{chapter}{Úvod}
\pagestyle{plain}
Lorem Ipsum
S~rosoucím počtem mobilních zařízení a jejich integrací do každodenního života jsou kladeny stále větší nároky na přístupové Wi-Fi sítě. Uživatelé požadují nejen rychlé a stabilní připojení, ale také široké pokrytí a vysokou úroveň zabezpečení.
Větší pokrytí vyžaduje větší počet přístupových bodů, což představuje nové výzvy pro správu síťí. Administrátoři musí čelit stále většímu objemu práce při správě těchto zařízení a i přes rosoucí počet připojených zařízení musí garantovat bezpečnost síťě. Správa sítě se tímto stáva stále složitější, roste potřeba automatizace a získání přehledu nad infrastrukturou.
Tyto rostoucí požadavky a výzvy kladou důraz na moderní přístupy k~ověřování uživatelů sítě, automatizaci a efektivitě správy síťové infrastruktury.
\subsection*{Cíle práce}
@@ -10,4 +14,12 @@ Lorem Ipsum
\subsection*{Struktura práce}
...
Práce je členěna do šesti částí.
První část práce se věnuje počítačovým síťím, základním principům počítačových síťí, popisuje síťovou architekturu a fungování dnešních počítačových sítí. Představuje technologie použité v~modelové implementaci.
Druhá část seznamuje se sadou standardů Wi-Fi, principům jejich fungování a zabezpečením ve Wi-Fi sítích.
Třetí část je věnována automatizaci konfigurace, historickému kontextu, výhodám a porovnání vybraných open-source nástrojů pro automatizaci.
Ve čtvrté části jsou deklarovány požadavky na modelovou implemntaci rozsáhlé Wi-Fi sítě projektu eduroam.
V~další části je tato Wi-Fi síť implementována. Tato část obsahuje ukázky konfiguračních souborů, popisuje kroky implementace modelové Wi-Fi sítě a ukazuje přístup k~monitoringu a získání přehledu nad infrastrukturou.
Poslední část se věnuje zhodnocení modelové implementace Wi-Fi sítě a navrhuje možná vylepšeni.