|
|
|
|
@@ -1,21 +1,26 @@
|
|
|
|
|
\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 konfiguraci centrální autentifikace a autorizace s~integrací do sítě eduroam. Popisuje také nastavení routerů, jedná se ale pouze o~základní konfiguraci pro fungování modelové implementace. V~reálné implementaci by konfigurace obsahovala daleko větším množstvím síťových rozhraní a komplexnější nastavení firewallu.
|
|
|
|
|
|
|
|
|
|
% ==================================================================================================================
|
|
|
|
|
\section{Síťové prostředí}
|
|
|
|
|
\label{sec:sitoveProstredi}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
% ==================================================================================================================
|
|
|
|
|
\section{Výběr softwaru pro síťové prvky a mangement síťových prvků}
|
|
|
|
|
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
% ==================================================================================================================
|
|
|
|
|
\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.
|
|
|
|
|
|
|
|
|
|
\subsubsection{Kompilace a sestavenení 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.
|
|
|
|
|
@@ -41,34 +46,238 @@ Seznam balíků, které nejsou potřeba pro provoz zařízení v~režimu příst
|
|
|
|
|
\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í packetů a další práci se síťovým provozem,
|
|
|
|
|
\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}
|
|
|
|
|
|
|
|
|
|
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}
|
|
|
|
|
Protože budeme dle definovaných požadavků v~kapitole \ref{ch:pozadavky} používat k~autentifikaci 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}
|
|
|
|
|
% \lstinputlisting[caption={Script spouštěný při prvním bootu (uci-defaults.sh)}, language=bash,]{ucidefaults.sh}
|
|
|
|
|
|
|
|
|
|
Tento script odstraní výchozí 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 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.
|
|
|
|
|
|
|
|
|
|
\subsubsection{Nahrání systému do paměti zařízení}
|
|
|
|
|
% ------------------------------------------------------------------------------------------------------------------
|
|
|
|
|
\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.
|
|
|
|
|
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{Nastavení management sítě a zřízení přístupu}
|
|
|
|
|
% ==================================================================================================================
|
|
|
|
|
\section{Konfigurace a správa přístupových bodů}
|
|
|
|
|
|
|
|
|
|
Tabulka \ref{tab:DevOpsTools} poskytuje přehled vybraných nástrojů pro správu konfigurace a jejich vlastností.
|
|
|
|
|
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 autentifikátor, tedy zprostředkovává autentizaci mezi klientským zařízením a autorizač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}
|
|
|
|
|
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
\section{Monitoring a centrální logování}
|
|
|
|
|
% ==================================================================================================================
|
|
|
|
|
\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{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 autentifiká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}
|
|
|
|
|
|
