Tyblog

“ Budování mého ideálního routeru za 50 dolarů “

Po tom, co mi odešel Asus N66U, jsem zvažoval několik možností: Další all-in-one router, upgrade na něco jako EdgeRouter, nebo uvařit něco vlastního.Když jsem si přečetl článek na Ars Technica, který obhajoval přednosti stavby vlastního routeru, bylo to v podstatě rozhodnuto: Mimochodem, desky ARM splňují mnoho z těchto požadavků a některé, jako například Raspberry Pi, vzbudily takovou aktivitu komunity, že platforma ARM má velkou podporu, i když se může zdát cizí platformě x86.

Podařilo se mi dát dohromady zařízení, které je na to, co dělá, nejen velmi levné, ale samo o sobě i velmi schopné.

Pokud máte zájem postavit si vlastní domácí router, ukážu vám zde, že je to nejen proveditelné, ale i relativně snadné a nabízí to obrovské množství užitečných funkcí – od tvarování provozu přes monitorování netflow až po dynamické DNS.

Sestavil jsem ho pomocí espressobinu, Arch Linuxu Arm a Shorewallu.

Tento obrázek ukazuje desku uzavřenou v pouzdře vytištěném na 3d tiskárně. espressobin bohužel není natolik populární, aby se mohl pochlubit širokou nabídkou kupovaných pouzder, jako má Raspberry Pi, ale existují dobré modely pro 3d tisk.

Ještě poznámka na okraj: Následující dokumentace není míněna jako vyčerpávající návod, jak krok za krokem udělat totéž sám.Ačkoli chci pokrýt mnoho voleb, které byly součástí sestavení, konfigurace něčeho tak důležitého, jako je router/firewall, by opravdu neměla být prací typu copy/paste a bylo by lepší se volně řídit zde uvedenými kroky s důkladným pochopením toho, jak a proč.

• Proč
• Část první: Hardware
  • Co s WiFi?
• Část druhá: Software
  • Operační systém
  • Firewall
• Část třetí: Základní sestava
  • Instalace operačního systému
  • Konfigurace operačního systému
  • Firewall
  • DHCP
• Část čtvrtá: Interludium
• Část pátá:
• Monitorování síťového toku
• Tvarování provozu

Proč

Na trhu existuje spousta solidních routerů, které si můžete koupit a které nejsou požáry pneumatik ISP a pravděpodobně by byly více než vhodné (s láskou se na tebe dívám, EdgeRouter Lite).Proč se tedy s tím vším obtěžovat? „Existují zde některé legitimní výhody:

• Je to vlastně velmi cenově dostupné. Můj router prošel mými srovnávacími testy na výbornou a má všechny funkce, které bych mohl vytáhnout z Linuxu (což je velký seznam).
• Je bezpečný. Mám pocit, že každý měsíc je oznámena nová zranitelnost nějakého zařízení na okraji spotřebitelské sítě. Když to srovnám s firewallem, který si spravuji sám, tak přesně vím, které služby jsou vystaveny nebezpečí (a pokud je iptables prolomeno, svět má větší problémy). Mimochodem, pro všechny odpůrce: jediný port, který naslouchá na mém firewallu, je náhodný port s vysokým číslem pro ověřování ssh pouze veřejným klíčem. Takže ano, myslím si, že je bezpečnější než nějaký spotřebitelský router Huawei.
• Má skvělé funkce. Jasně, můj espressobin umí routovat a slouží jako firewall, ale já jsem do něj nacpal i další užitečné funkce.
• Je výkonný. V menších srovnávacích testech, které jsem provedl, dokáže espressobin opravdu přenášet provoz, aniž by se zapotil.
• Bylo opravdu zábavné ho sestavit. Pokud a) potřebujete nový router nebo b) si chcete vylámat zuby na jednodeskovém projektu s ARMem, mohlo by se vám to hodit.

Část první: Hardware

Technicky by se dal router sestavit z libovolného počítače se dvěma síťovými kartami, ale stejně dobře si vystačíme s menším výkonem, menšími rozměry a levněji.Desky ARM se trefily do černého: jsou superlevné, výkonnější, než byste si mysleli, a dobře podporované, protože na trhu je tolik variant.

Nejznámějším soupeřem je Raspberry Pi, ale bez dvou síťových karet nebo gigabitové sítě to není dobrá volba.Navíc platíte za věci, jako je GPU, které u bezhlavého síťového zařízení nejsou nutné.

Dobrou zprávou je, že loni vyšel espressobin, který je super schopný.Připadá mi, že je pro tento typ věcí přímo stvořený: gigabitová síť, vestavěný přepínač a žádné výstřelky, které byste jinak potřebovali pro něco univerzálnějšího (není tu ani výstup na displej, jen sériová konzole).

Přestože je deska poměrně mladá, Armbian i Arch Linux Arm hardwarově podporují a oba projekty to dělají skvěle. pokud jste svět Linuxu na ARMu ještě neprozkoumali, není se čeho bát.Armbian a Arch Linux Arm poskytují vše potřebné pro aarch64 nativně v repozitářích distribucí, takže na 64bitovém čipu ARM narazíte jen na máloco, co by vám bylo cizí, a určitě se to vyplatí, když vezmete v úvahu cenovou dostupnost hardwaru a nízkou spotřebu.

Tady jsou některé pro mě nejdůležitější věci:

• Deska obsahuje vestavěný síťový přepínač Topaz. Při mém síťovém testování je provoz, který prochází pouze přes rozhraní LAN, rychlostně k nerozeznání od provozu procházejícího přes vanilla switch. Pokud streamujete z NAS nebo máte jinak vysoké požadavky na komunikaci mezi zařízeními, která prochází přes router, může to znamenat velký rozdíl.
• Sériová konzole je občanem první třídy. Na mých Raspberry Pis mě občas frustrovalo, že jsem při ladění problémů musel sahat po displeji HDMI, ale espressobin má sériový port micro USB pro snadný přístup ke konzoli.
• Čip aarch64 byl skvělý. Nejenže zvládl všechno, co jsem na něj hodil, ale věděli jste, že není ovlivněn meltdownem? Čipy Cortex-A53 nejsou ovlivněny chybou spekulativního vykonávání, takže to je bonus navíc.

Co WiFi?

Zde udělám malou poznámku, že jsem se pokusil použít espressobin i jako bezdrátový přístupový bod. deska má mini PCIe slot dobře uzpůsobený pro bezdrátovou kartu, a i když by to mělo fungovat, mohu definitivně oznámit, že to není dobrý nápad.

Aniž bych zabíhal do bolestivých detailů, je tu spousta problémů, kvůli kterým to nestojí za námahu. 5Ghz pásma se mi nepodařilo zprovoznit za žádného scénáře, moje 2,4Ghz služba hostapd přestala reagovat každých zhruba dvanáct hodin a rychlosti byly šokující.

obecně si myslím, že je to chyba hardwaru espressobinu. karty, které by jinak měly být v Linuxu dobře podporovány (některé z karet, které jsem testoval, byly založené na ath9k nebo ath10k), prostě s rozhraním mPCIe na desce nefungují.Dokonce i oficiálně doporučované karty měly problémy – RTL8191SE fungovala přerušovaně, a dokonce ani karta vyráběná společností Globalscale nefunguje tak, jak je inzerováno. mimochodem, pokud najdete dobře podporovanou kartu na espressobin, napište prosím odpověď do souvisejícího vlákna na fóru, které jsem kvůli tomuto problému založil.

Při tom všem jsem měl na začátku tohoto projektu v úmyslu oddělit svůj AP od routeru, ať už nakonec použiji espressobin, nebo ne.Oddělení úkolů firewallu/směrování od bezdrátového připojení je příjemným oddělením starostí a můžete si pořídit velmi dobrá specializovaná zařízení AP bez jakékoli funkce mimo vysílání signálu, aby byla jednoduchá a výkonná.

Pokud to má cenu, nakonec jsem si koupil zařízení Ubiquity UniFi a byl jsem s ním naprosto spokojený.

Druhá část: Software

Existují zde dvě velké možnosti:

Operační systém

První volba, kterou je třeba učinit, je, zda si to chcete ručně převést z distribuce, která podporuje aarch64, nebo použít předpřipravené řešení podobné firmwaru, jako je OpenWRT.Osobně jsem zjistil, že kdykoli použiji pro sestavení smrsknuté řešení, jako je Tomato/OpenWrt nebo FreeNAS, obvykle jsem frustrovaný, aniž bych se tam mohl pořádně dostat a něco doladit, takže pro operační systém budu používat univerzální linuxovou distribuci.

Jak jsem již zmínil, Armbian a Arch Linux ARM deska podporuje a espressobin má oficiální dokumentaci pro Ubuntu (stejně jako Yocto, které jsem doposud neznal).I když vám neřeknu, co je pro váš případ použití nejlepší, zde je důvod, proč jsem dal přednost Arch Linuxu Arm:

• Jsem naprosto zapálený pro distribuce s rolling release.
• Jsem také zapálený pro běh na krvácejících nejmodernějších distribucích. V případě routeru je příjemné být blízko upstreamu, když jsou vydávány aktualizace potenciálně související s bezpečností.
• Arch nám poskytne čistý štít, na kterém můžeme stavět bez jakýchkoli cizích služeb. To znamená, že s minimálním základem můžeme přesně vědět, co budeme mít nainstalované, vystavené a spuštěné po sestavení jednotlivých částí.
• Znám lidi z Arch Linux ARM a mám je rád. Ahoj WarheadsSE!

Firewall

Některá jména jako PFSense mě napadají okamžitě, ale opravdu bych rád provozoval něco na Linuxu, protože ho znám mnohem lépe než BSD (navíc nejlepší možnosti OS pro espressobin jsou na bázi Linuxu).

Prostředí linuxových firewallů je docela široké. i když budeme téměř jistě používat něco na bázi iptables, existuje spousta služeb vyšší úrovně, které stojí nad iptables (ufw, firewalld atd.)Ačkoli byste si mohli napsat vlastní jednoduchou sadu pravidel iptables a pokračovat s ní, rozhodl jsem se použít firewallovou službu, protože tím získáme příjemné kmenové znalosti, které linuxová komunita získala za mnoho let správy firewallů iptables.

Všeobecně by dobrý firewallový démon měl:

• Zapadat do profilu „zdravý OSS projekt“. To znamená, že by měl být aktivně udržován, měl by existovat nějakou dobu a měl by mít slušné přijetí.
• Vyhnout se složitosti. Jednoduché projekty se snáze ladí, rozšiřují a provozují.
• Podporovat některé příjemné funkce, jako je podpora tvarování provozu a snadná konfigurace přesměrování portů.

Po chvíli zkoumání jsem se rozhodl pro Shorewall.Zde jsou některé z nejvýznamnějších důvodů, proč jsem se pro něj rozhodl:

• Konfigurační tok je zkompilovat a pak použít. To zajišťuje, že náš soubor pravidel je před použitím příčetný, což také znamená, že neexistuje žádný rezidentní démon, který by spotřebovával prostředky zařízení, což má význam na malém jednodeskovém počítači.
• Je v něm zabudována spousta pěkných historických znalostí, takže vyplivnutá pravidla iptables zvládají spoustu okrajových případů, na které byste normálně nepomysleli.
• Podrobněji se tomu budu věnovat později, ale označování paketů a nativní podpora tvarování provozu usnadňují třídní qdisky.

Díl třetí:

Instalace operačního systému

Tento příspěvek si neklade za cíl být vyčerpávajícím průvodcem, ale chtěl jsem uvést obecné body, aby bylo zřejmé, jak snadné je to sestavit.

Instalace operačního systému

Tato je snadná – stačí postupovat podle stránky Arch Linux Arm espressobin.Zvláště důležité je všimnout si přidaných příznaků u příkazu mkfs.ext4 a další konfigurace U-Boot.

Konfigurace operačního systému

Obecně jsou instalace Arch Linuxu Arm od začátku docela dobře nastavené. samozřejmě budete chtít nastavit uživatele, který není root a který bude spravovat systém a není výchozím účtem, takže nezapomeňte zakázat uživatele alarm, změnit všechna hesla a aktualizovat systém.

Jako poznámku na okraj vřele doporučuji nainstalovat balíček pacmatic a používat ho místo běžného pacman.Automaticky zjistí aktualizace konfiguračních souborů a pomůže je sloučit, stejně jako vloží důležité zprávy o změnách v balíčcích.

Dále bych doporučil nastavit etckeeper pro sledování konfigurace firewallu (na Arch wiki je dobrý úvod). já jsem si nastavil automatické odesílání do soukromě hostovaného gitolite repo.Abych byl zcela upřímný, nemám rád všechna řešení pro správu konfigurace a téměř všechny naše změny jsou omezeny na /etc, takže toto je alespoň pro mě dostatečně dobré záložní řešení.

Všimněte si, že výchozí konfigurace sítě pro espressobin funguje dobře pro případ použití routeru:

• Obě lan rozhraní, lan0 a lan1, jsou přemostěna na rozhraní br0. To nám umožňuje centralizovat věci směřující do soukromé sítě, jako je dnsmasq, na jediném virtuálním rozhraní.
• Rozhraní směřující do veřejné sítě je wan. Svou adresu získá od poskytovatele připojení prostřednictvím DHCP.

Jedinými změnami nutnými k nastavení br0 a wan pro náš směrovač jsou dva doplňky: zaprvé přiřazení statické IP rozhraní LAN, protože to bude směrovač, a povolení předávání IP a maškarády IP v /etc/systemd/network/br0.network:

Address=192.168.1.1/24IPForward=ipv4IPMasquerade=yes

A potvrzení, že rozhraní WAN si vyžádá adresu od poskytovatele připojení v /etc/systemd/network/wan.network:

DHCP=yesIPForward=ipv4UseDNS=no

Tady jsem nastavil UseDNS=no, protože raději používám servery OpenNIC než servery mého poskytovatele připojení – o jejich nastavení se zmíním později.

Firewall

V repozitářích Arch Linux ARM aarch64 je k dispozici nejnovější verze Shorewallu, kterou jsem použil. moje konfigurace nejsou nijak náročné, a pokud vážně uvažujete o nasazení Shorewallu s připojením k divokému internetu, vřele doporučuji přečíst si celý úvod k Shorewallu s dvěma rozhraními firewallu.Obsahuje základy toho, jak byste měli vše nastavit, s pěkným shrnutím směrování a firewallu obecně.

Zásadně umístíte rozhraní br0 a wan do správných zón a nastavíte všechna potřebná pravidla v /etc/shorewall/rules.Nezapomeňte hostitelům v síti LAN povolit používání serveru DNS:

DNS(ACCEPT) loc $FW

V souboru interfaces potvrdíte, že na rozhraní sítě LAN je povolen protokol DHCP.

Tady bych poznamenal, že jsem při nastavování firewallu narazil na chybu v Shorewall, kterou jsem našel opravenou doslova den předtím – a Arch Linux ARM už měl aktualizovaný balíček v upstreamových repozitářích. 1 bod za používání aktuálních distribucí.

DHCP

dnsmasq se perfektně hodí pro domácí router. spojuje DNS a DHCP server do lehkého démona, který zvládne vše, co byste potřebovali od malé sítě, a je natolik vyspělý, že existuje spousta dokumentace, která ho používá právě pro tento případ použití.

Poznámka: Pokusil jsem se použít vestavěný server DHCP systemd, který lze nastavit pomocí DHCPServer= v souborech .network, protože se mi to zdálo jako lehký způsob, jak spustit server DHCP bez dalšího softwaru.Aniž bych byl příliš upovídaný, nestojí to za to, jedním z důležitých důvodů je, že neexistuje žádný způsob, jak zjistit aktuální pronájmy adres.

Tady je třeba nastavit spoustu voleb, ale nejdůležitější jsou:

# Listen for requests on this interfaceinterface=br0# Address range to draw fromdhcp-range=192.168.1.5,192.168.1.250,255.255.255.0,24h# Default route for clients (the address we used in /etc/systemd/network/br0.network)dhcp-option=option:router,192.168.1.1# Instead of doling out DNS servers from your upstream ISP who may do dumb# things for things like unresolvable names, you can rely on other DNS servers.# These are from OpenNIC.server=192.52.166.110server=66.70.211.246server=69.195.152.204server=158.69.239.167

Pokud potřebujete statická přiřazení nebo aliasy, ty lze také snadno přidat.

Část čtvrtá: Interludium

S espressobinem obsluhujícím požadavky DHCP a DNS na br0, firewallem přes Shorewall a směrováním paketů mezi LAN a WAN je to funkční směrovač. v tuto chvíli stačí připojit port WAN k upstreamu poskytovatele a dva porty lan0/lan1 k zařízením nebo jinému přepínači.

To je však jen začátek.

Pokud chceme tento router skutečně považovat za náhradu, můžeme udělat několik skutečně skvělých věcí, kterými jeho schopnosti dále posílíme, aby nepůsobil jako downgrade oproti něčemu, jako je můj starý Asus N66U.

Část pátá: Upgrady

Do svého vanilkového routeru espressobin jsem přidal následující funkce, které postupně popíšu:

• Monitorování síťového toku
• Tvarování provozu

Monitorování síťového toku

Přehled o provozu je něco, co jsem u svého firmwaru Asus Merlin považoval za opravdu cenné pro sledování využití.Netflow je de facto standard pro tyto věci a ze všech dostupných možností se mi velmi líbí ipt-netflow, protože je to nativní modul jádra, takže má velmi malou režii a je velmi aktivně udržován.

Ukázalo se, že jsem pravděpodobně první člověk, který ho používá na architektuře aarch64, protože mi pomohl zajistit jeho podporu na čipové sadě aarch64. správce projektu byl (a je) super citlivý na opravy chyb, takže jsem neměl žádné problémy se zajištěním podpory modulu na nejnovějších jádrech, na kterých běží projekt Arch Linux ARM.

Používání je otázkou instalace balíčku ipt-netflow-dkms-git z AUR.Bude se sestavovat pro vaše jádro, protože dkms je úžasný, a do /etc/modules-load.d/ipt-netflow.conf

ipt_NETFLOW

To ho načte a vy ho nakonfigurujete v /etc/modprobe.d/ipt-netflow.conf:

options ipt_NETFLOW destination=$ip:2055 protocol=5

Kde $ip je váš cíl netflow.Nakonec se provoz zachytí tak, že proudí do speciálního cíle iptables, což lze pohodlně provést přímo ze shorewallu.V /etc/shorewall/start:

run_iptables -I INPUT -j NETFLOWrun_iptables -I FORWARD -j NETFLOWrun_iptables -I OUTPUT -j NETFLOWreturn 0

To nasměruje všechny pakety na směrovači, aby nejprve vstoupily do cíle NETFLOW, který pakety zpracuje a předá je zpět k toku přes běžná pravidla, která nastaví Shorewall.

Samozřejmě, že ipt-netflow potřebuje místo, kam bude posílat protokoly netflow, ale to je mimo rozsah tohoto příspěvku.V mém případě mám v síti spuštěnou instanci Logstash se spuštěným modulem netflow, který agreguje události v clusteru Elasticsearch, čímž získávám praktické dashboardy a možnost vizualizovat nejrůznější informace o své síti.K dispozici jsou některé výchozí dashboardy:

Včetně některých docela zajímavých, jako je například dashboard Geo-IP:

Nejdůležitější metrikou, která mě zajímá, je však celkové využití šířky pásma, protože mám předpotopního poskytovatele internetu, který se stará o datové limity.Naštěstí je to s daty netflow, která sbírám, snadné: stačí požádat Elasticsearch, aby sečetl některá pole, a tyto metriky snadno získáme.

• Následující dashboard má dvě vizualizace:
  • Měřidlo porovnává součet za dané časové období s limitem, který mi nastavil můj ISP, takže snadno vidím, kde leží moje aktuální využití vzhledem k limitu.
  • Časová řada vykresluje šířku pásma v bytech v čase, abych viděl, kdy tuto šířku pásma využívám.

  

  Něco obzvlášť skvělého na tomto nastavení je, že protože ukládáme metriky netflow v Elasticsearch namísto v nějakém jiném datovém úložišti nebo databázi časových řad, mohu skutečně zaměřit dotazy pro tyto dashboardy, abych mohl dělat věci, jako je součet celkových bajtů pouze pro určité rozsahy CIDR, protože základní úložný engine (Lucene) nativně rozumí IP adresám.Například následující dotaz v Kibaně:

  NOT (netflow.dst_addr:"192.168.1.0/24" AND netflow.src_addr:"192.168.1.0/24")

  Efektivně odfiltruje potenciálně velké kusy šířky pásma, které se odehrávají mezi hostiteli v mé síti LAN, například streamování mezi mým hostitelem Kodi a počítačem NAS. super.

  Traffic Shaping

  Z toho se stal docela masivní podnik, do kterého bylo fascinující zmizet v králičí noře.Některé základní a většina vlastních firmwarů routerů nabízí nějakou formu QoS nebo tvarování provozu, takže jsem doufal, že totéž provedu na svém vlastním routeru, abych ochránil některé své přenosy (například Overwatch) před vysokými latencemi.

  Svět technologie QoS je fascinující místo.I když se můžete spolehnout na některá jednoduchá schémata, jako je filtr HTB (hierarchical token bucket), pokrok ve filtrování paketů je překvapivě aktivní a existuje spousta zajímavých přístupů.

  To, na čem jsem se nakonec usadil, byl filtr HFSC (hierarchical fair-service curve).Budu upřímný: matematika, která za ním stojí, je tak mimo mou ligu, že jsem si musel přečíst několik shrnutí, která se to pokoušela rozebrat pro normální lidi, a nejlepší vysvětlení, které mi dávalo smysl, byl vynikající gist, na který jsem narazil od uživatele GitHubu eqhmcow, který vysvětluje výhody a použití HFSC v praxi.

  Tl;dr je následující: pomocí třídy řízení provozu HFSC můžete velmi efektivně upřednostňovat provoz a dosáhnout dobré rovnováhy mezi toky, které vyžadují vysokou šířku pásma a nízké latence. není to kouzelná kulka – stále budete muset označit, které typy provozu jsou citlivé na latenci – ale mně se to docela osvědčilo.Bez zavedených pravidel bude stahování služby Steam nebo Blizzard Launcher zabíjet časy pingu, zatímco aktivní pravidla HFSC budou tyto náročné části provozu elegantně ořezávat, aby se zajistilo, že interaktivní streamy nebudou ovlivněny. je to opravdu skvělé!

  Výše zmíněný gist dobře popisuje, jak nastavit třídy tc od nuly.Shorewall však ve skutečnosti zvládá řízení provozu podle tříd nativně, takže můžeme poměrně snadno nastavit výkonná pravidla QoS.Následující konfigurační soubory jsou založeny na mých naměřených rychlostech přenosového pásma, které jsou přibližně 230 směrem dolů a 10 směrem nahoru.

  Prvním krokem je nastavení příslušných tříd tc pro každé zařízení v souboru tcdevices:

  # cat /etc/shorewall/tcdevices#INTERFACE 97%_down 90%_up options(set hfsc)wan 224mbit:200kb 9mbit hfscbr0 1000mbit:200kb 1000mbit hfsc

  Tady rozhraní br0 směřující do sítě LAN dostane plný gigabit, ale rozhraní WAN wan dostane 97 % své rychlosti směrem dolů a 90 % mé dostupné rychlosti směrem nahoru.Zdůvodnění těchto čísel je vysvětleno v gistu – v podstatě znovu vytváříme tuto sadu pravidel v podmínkách Shorewall.

  Dále definujte, jak se budou značky paketů mapovat na třídy tc v souboru tcclasses:

  # cat /etc/shorewall/tcclasses#INTERFACE MARK RATE CEIL PRIO OPTIONSwan:10 1 full/2:10ms:1540 full 1 tcp-ackwan:11 3 full/2:10ms:1540 full/2 2 defaultbr0:20 2 full*9/10:10ms:1540 full*9/10 1 tcp-ackbr0:21 3 115mbit:10ms:1540 224mbit 2 default

  Tím se důležitý/interaktivní provoz zařadí do tříd, které dostanou vyšší prioritu.Samozřejmě musíme také označit pakety, které mají dostat tuto vyšší prioritu, což provedeme v souboru mangle:

  # cat /etc/shorewall/mangle# ICMP pingMARK(1-2) 0.0.0.0/0 0.0.0.0/0 icmp echo-requestMARK(1-2) 0.0.0.0/0 0.0.0.0/0 icmp echo-reply# sshMARK(1-2) 0.0.0.0/0 0.0.0.0/0 tcp ssh# Overwatch, Hearthstone, Diablo. 3478-3497 are very general RTP ports.MARK(1-2) 0.0.0.0/0 0.0.0.0/0 tcp,udp bnetgame,blizwow,6113MARK(1-2) 0.0.0.0/0 0.0.0.0/0 udp 3478-3497,5060,5062,6120,6250,12000-64000# Local trafficMARK(1-2) 192.168.1.0/24 192.168.1.0/24

  Tím nastavíme značky s vysokou prioritou (1 a 2), které bude zpracovávat naše třída tc. příklad zahrnuje ICMP pingy, ssh, některé hry Blizzard a místní provoz.

  Načítání shorewall by je mělo uvést v platnost. konečný výsledek by měl umožnit hromadný provoz, jako je stahování nebo streamy, a zároveň negativně neovlivnit latenci interaktivního provozu, jako je ssh, časy pingů ve hrách apod. mé neformální testy to potvrdily – upozorňuji, že pokud se to rozhodnete ověřit sami, můžete pozorovat nárůst latence bezprostředně po počátečním náporu hromadného provozu, ale HFSC rychle zasáhne a vynutí omezení, aby latence interaktivního provozu zůstala nízká.

  Mám několik sad benchmarků, které ukazují HFSC v akci, ale zde je malý příklad: jak jsou ovlivněny latence pingu, když je iperf spuštěn na pozadí.

  

  Jak vidíte, bez jakýchkoli pravidel řízení provozu mohou mít přívaly hromadného provozu docela negativní dopady na interaktivní provoz citlivý na vysoké latence. pomocí HFSC se těmto problémům můžeme vyhnout.

  Závěr

  Svůj domácí směrovač používám již několik měsíců a zdá se, že funguje skvěle.Za celou dobu nepřetržitého provozu jsem nezaznamenal žádné záhadné výpadky spojení, problémy s rychlostí ani hardwarové problémy, takže bych sestavení považoval za úspěšné.Také aktualizace jsou v pořádku; po běžném sudo pacmatic -Syu a restartu se systém vrátí do provozu se všemi pravidly iptables a dalšími službami podle očekávání, takže udržovat krok s nejnovějšími jádry a dalšími balíčky je jednoduché.

  Shrnuto:

  • Pro provozně zdatného nebo technicky zaměřeného člověka je vlastní sestavení routeru velmi dobře proveditelné. Díky jednodeskovým počítačům ARM je začátek levný a pohodlný.
  • OSS řešení pro brány firewall, tvarování provozu a monitorování sítě jsou vyspělá a snadno se s nimi pracuje. Zejména jemně zestárlá řešení jako Shorewall a dnsmasq jsou velmi dobře zdokumentovaná a mají za sebou mnoho let práce vložené do jejich dokumentace a sady funkcí.
  • Zatímco směrování + DNS + DHCP je hračka, OSS WiFi může být trefa do černého. Vaše zkušenosti se mohou lišit, ale můj espressobin prostě není dobrý přístupový bod.