Linuxový router PC – Kompletace a postřehy (3)


Úvod

Jestliže jste četli předchozí dva díly tohoto třídílného seriálu, tak jistě víte, že nám počítač funguje správně, a to jak po stránce hardwarové, tak softwarové. Stejně tak ale víte, že přístup k síti by zevnitř mělo pouze jedno zařízení, protože do domácí sítě vede z tohoto PC pouze jeden Ethernetový port. To je první věc, kterou se v tomto díle budu zabývat a tou druhou věcí budou nějaké postřehy, které jsem zaznamenal během více než měsíčního provozu tohoto projektu. Nuže, pojďme na to! :-)


Distribuce sítě po domě

Do této chvíle zprostředkovával funkci domácího routeru MikroTik hAP lite RB941 (webové stránky, CZC.cz). Zařízení od MikroTiku jsou obecně známé svými rozsáhlými konfiguračními možnostmi, čehož využijeme i teď a router nastavíme tak, aby se choval jako takový chytřejší managed switch a Wi-Fi AP v jednom. Na pár útržků z takovéhoto nastavení se podívejme prostřednictvím obrázků. Jesliže pro vás bude některý z obrázků příliš malý, můžete si jej samozřejmě rozkliknout! :-)

Nastavení bridge na MikroTiku
Základem klasického switche je to, že je na všech jeho portech připojen do jednoho L2 segmentu. Spojení více portů do jednoho segmentu se na routerech řeší pomocí bridge, do něhož jsem přidal i port ether1, který by jinak sloužil jako WAN rozhraní.

Nastavení firewallu pro IPv4
Nastavení firewallu pro IPv6
Firewall je rovněž poněkud jiný, než byste našli na klasickém routeru. Vyznačuje se třeba tím, že neobsahuje žádná FORWARD pravidla a chrání tedy pouze sám sebe a nikoliv zbytek sítě. To nám ale nevadí, protože před padouchy z internetu nás chrání samotný RouterPC. :-) Podobná „sebeobranná“ pravidla aplikujeme jak pro IPv4, tak pro IPv6.

DHCP server na switchi neexistuje
RA server je na switchi vypnutý
DHCPv6 server na switchi neexistuje
Ke každému domácímu (!) routeru dnes neodmyslitelně patří také DHCP server pro IPv4 a RA/DHCPv6 server pro IPv6, aby se na každém zařízení nemusela nastavovat statická IP adresa (třeba Android dokonce ve výchozím stavu ani nastavení statické IPv6 neumožňuje). Ani jedna z těchto dvou věcí avšak na switchi nemá co dělat. O všechno se přece stará RouterPC. :-)

Router se tedy chová jako switch + AP a zařízení v domácí síti mají připojení. Výborně! :-)

Ačkoliv jsou Ethernetové porty na switchi pouze standardu Fast Ethernet (100Mb/s) a AP pouze na frekvenci 2,4GHz (802.11n max), mě to nevadí. Moje internetové připojení to zvládne přenášet v jeho plné rychlosti, a to ještě s velmi slušnou rezervou a upgrade tohoto připojení se neplánuje (zatím není potřeba). Na přenosy po LAN to také nějak extra velký vliv nemá – ačkoliv takto občas nějaká data přenáším, povětšinou nejsou nijak zvláště objemná.


Postřehy z provozu a několik změn

V době, kdy tento článek píši, už běží počítač nepřetrižitě více jak měsíc. Můžu se s vámi tedy podělit o pár zkušeností z provozu a změn, které jsem za tu dobu udělal. :-)

V minulém díle jsem psal, že po 14 dnech provozu mám ve firewallu zhruba 270 pravidel. Od té doby jsem jich ještě pár pozměnil, ale žádné extra zásadní změny učiněny nebyly. Spíše se jedná jen o menší optimalizaci a zpřehlednění (rozdělení pravidel do více řetežců, atd.). Větší změny se ovšem odehrály v serverových službách. Kompletně jsem totiž vypnul NTP server a HTTP proxy server.

U první zmiňované služby byl problém s tím, že se server horko težko synchronizoval s upstream servery. Ačkoliv jsem jich zkoušel několik (včetně třeba výchozího Debian NTP poolu), vždy nejméně jednou za pár dnů dobu došlo k "rozladění" v řádu několika (desítek) milisekund, což NTP server začal považovat za obrovskou nepřesnost a při žádosti o synchronizaci času z vnitřní sítě odpovídal s tím, že má stratum 16, což efektivně znamená, že si od něj žádající zařízení nemá čas nastavovat, protože může být nepřesný. Dalším problémem bylo to, že málo operačních systémů respektuje údaj o NTP serveru z DHCP, takže bych na většině zařízení musel NTP server nastavovat ručně. Nakonec jsem dospěl k závěru, že bude nejjednodušší NTP server úplně vypnout a nechat zařízení synchronizovat čas z těch serverů, které mají samy nastavené (time.windows.com, debian.pool.ntp.org apod.). Pokud by ovšem přece jen nějaké zařízení chtělo používat NTP server z DHCP (či od OpenVPN serveru), tak jsem do jejich konfigurací umístil adresy NTP serverů Googlu.

U HTTP proxy mě ani tak netrápily nějaké problémy, ale spíše neefektivita. Když na domácím připojení přenesete data v řádu stovek gigabajtů měsíčně a HTTP proxy zacahuje tak maximálně nižší stovky megabajtů, začnete si pokládat otázku, jestli to má cenu. Podle mého názoru ne, a tak jsem proxy zrušil. Další komplikací byla samotná distribuce informace o tom, že se v síti proxy nachází, a to sice prostřednictvím protokolu WPAD – ani ten totiž vždy nefungoval tak, jak bych si představoval. Celkový běh sítě změna nijak neovlivnila a tak asi není o čem polemizovat. :-)

Asi poslední (významnější) změnou bylo změnění intervalu rozesílání Router Advertisement zpráv v konfiguraci démona RADVD, a to směrem nahoru. Původní interval (10-90s) činil problémy některým Android zařízením (zpozoroval jsem to u svého telefonu s Androidem 9.0, ale je možné, že se to projevovalo i jinde), jež se kvůli tomu po právě cca 90 sekundách vždy samy odpojily a ihned následně připojily k Wi-Fi. To mi způsobovalo problémy například při videokonferencích a videohovorech, které jsou obzvláště v současném koronavirovém období běžné. Po nastavení intervalu na 600-1200 sekund tyto problémy ustaly a jako u všech předchozích řešených potíží jsem žádné jiné dopady na provoz sítě nezpozoroval. Nevím přesně, co telefonu tak vadilo, protože RA by rozhodně neměly způsobovat odpojení od sítě (maximálně by měly prodlužovat dobu platnosti vygenerovaných IPv6 adres) a ani jsem to nijak do detailu nezkoumal. Hlavní je, že je věc vyřešena.

Obecně lze ale říci, že vše běhá, jak má – router routuje, služby plní svůj účel a třeba ten osobní cloud, který je na tomto PC mimo jiné také provozován, velmi často využívám. Zvýšení rychlosti připojení internetu žádné nepociťuji, ale na druhou stranu ani žádné zpomalení. Co se ale určitě zvýšilo, je bezpečnost – třeba díky možnosti DNSSEC validace nebo díky o mnoho pokročilejší implementaci protokolu OpenVPN (na RouterOS nejsou podporovány šifry z rodiny AES-GCM a MAC funkce lepší jak SHA-1). Další plus je podpora OpenVPN po UDP, která v RouterOS v době psaní článku neexistuje (ale prý existovat bude). Ani zde mě ale nechápejte nijak špatně – MikroTiky svému původnímu účelu (routování) slouží velmi dobře, ale prostě mám trochu jiné požadavky, než by člověk od by-definition routerů očekával, a proto si stavím setup vlastní, když mám tu potřebu a možnost. :-)


Závěr

Gratuluji vám – dostali jste se až na konec této třídílné série, která je co do počtu slov trochu delší, než jsem původně očekával. Kdybyste se pouštěli do podobného projektu a měli jste nějaké otázky ohledně mých dalších zkušeností či doporučení, dosažitelný pravděpodobně budu na Twitteru nebo na e-mailu kontakt(-zavináč-)ethernetlord(-tečka-)eu (spousta věcí se ale dá vygooglit, takže to berte spíše jako možnost zeptat se mě na nějakou zkušenost, tip nebo jinou věc, kterou jsem zde třeba nezmínil úplně do detailu, což se klidně mohlo stát; nezapomínejte, že Google či manuálové stránky budou většinou rychlejší na nalezení nějaké nejasnosti v konfiguraci apod., než já). :-)

Stejně tak se mě neváhejte kontaktovat, kdybyste našli nějaký překlep či faktickou chybu – i to se mohlo stát a budu rád, když si toho někdo všimne. V každém případě děkuji za přečtení a doufám, že se vám série líbila. :-)