Tyblog

” Az ideális routerem építése 50 dollárért ”

Miután az Asus N66U-m elpatkolt, megfontoltam néhány lehetőséget: Egy másik all-in-one router, frissíteni valami EdgeRouterre, vagy valami egyedi routerre.Amikor elolvastam az Ars Technica cikkét, amely a saját router építésének erényeit hirdette, ez nagyjából eldöntötte a kérdést:

Van egy kis pszichológiai komplexusom, amikor a saját, túlmérnöki megoldásaimról van szó, de kitűztem néhány általános célt: a végeredmény legyen olcsó, alacsony fogyasztású, Linux által jól támogatott és bővíthető.Mellesleg az ARM lapok sok ilyen követelménynek megfelelnek, és néhány, például a Raspberry Pi olyan nagy közösségi aktivitást váltott ki, hogy az ARM platform nagy támogatást élvez, még ha idegen is az x86-tól.

Sikerült összedobnom egy olyan eszközt, ami nem csak piszok olcsó ahhoz képest, amit csinál, de önmagában is rendkívül alkalmas.Ha érdekel a saját otthoni router építése, itt bemutatom, hogy ez nem csak megvalósítható, de viszonylag könnyen kivitelezhető, és rengeteg hasznos funkciót kínál – a forgalom alakításától kezdve a netflow monitorozásán át a dinamikus DNS-ig.

Az espressobin, Arch Linux Arm és Shorewall segítségével építettem.

A képen a 3d-nyomtatott tokba zárt lap látható. sajnos az espressobin nem elég népszerű ahhoz, hogy a megvásárolható tokok széles választékával büszkélkedhessen, mint a Raspberry Pi, de van néhány jó modell 3d-nyomtatásra.

Mellékesen megjegyezném, hogy az alábbi dokumentáció nem egy átfogó lépésről-lépésre történő útmutatásként szolgál ahhoz, hogy te magad is meg tudd csinálni ugyanezt.Bár sok olyan döntést szeretnék lefedni, ami az építésbe került, egy olyan fontos dolog konfigurálása, mint egy router/firewall, tényleg nem lehet copy/paste munka, és jobb lenne, ha lazán az itteni lépések alapján, a hogyan és a miértek alapos megértésével irányítanánk.

• A miért
• Első rész: Hardver
  • Mi van a WiFi-vel?
• Második rész: Szoftver
  • működő rendszer
  • Firewall
• Harmadik rész: Az alapépítés
  • OS telepítés
  • OS konfiguráció
  • Tűzfal
  • DHCP
• Negyedik rész: Közjáték
• Ötödik rész: Az alapépítés
• Az ötödik rész:
  • Netflow Monitoring
  • Traffic Shaping
• Következtetés

A miért

Bőven vannak olyan megbízható routerek, amiket meg lehet venni, de nem raktári ISP gumitüzek, és valószínűleg több mint megfelelőek lennének (szeretettel nézek rád, EdgeRouter Lite).Szóval miért bajlódsz ezzel az egésszel?Van néhány jogos előnye:

• Ez valójában nagyon megfizethető. A routerem kiválóan teljesítette a benchmarkjaimat, és minden olyan funkcióval rendelkezik, amit Linuxról be tudtam vonni (ami egy nagy lista).
• Biztonságos. Úgy érzem, mintha minden hónapban egy új sebezhetőséget jelentenének be valamilyen fogyasztói hálózati szélső eszközre. Hasonlítsd ezt össze egy önmenedzselt tűzfallal, és pontosan tudom, hogy mely szolgáltatások vannak kitéve (és ha az iptables elromlik, a világnak nagyobb gondjai vannak). Minden ellenzőnek, egyébként az egyetlen port, amit a tűzfalam figyel, egy véletlenszerű, magas számozású port a csak nyilvános kulcsú ssh-hitelesítéshez. Szóval igen, szerintem biztonságosabb, mint valami Huawei fogyasztói router.
• Nagyszerű funkciókkal rendelkezik. Persze, az én espressobinom tud útválasztani és tűzfalként szolgálni, de beiktattam néhány más hasznos képességet is.
• Teljesítőképes. Az általam elvégzett kisebb benchmarkokban az espressobin tényleg tud forgalmat bonyolítani anélkül, hogy megizzadna.
• Ez igazán szórakoztató volt építeni. Ha a) szükséged van egy új routerre, vagy b) szeretnél egy egylapos ARM-projektbe belevágni, akkor ez jó választás lehet.

Első rész: Hardver

Technikailag bármilyen két hálózati kártyával rendelkező számítógépből összeállíthatsz egy routert, de kevesebb energiával, kisebb formafaktorral és olcsóbban is ugyanolyan jól meg tudjuk csinálni.Az ARM lapok eltalálták az édes pontot: szuperolcsók, erősebbek, mint gondolnánk, és jól támogatottak, mivel nagyon sok változatuk van a piacon.

A legismertebb versenyző a Raspberry Pi, de két NIC vagy gigabites hálózat nélkül nem jó választás.Ráadásul olyan dolgokért fizetsz, mint a GPU, amikre nincs szükség egy fej nélküli hálózati eszközben.

A jó hír, hogy tavaly megjelent az espressobin, ami szuper képességű.Úgy érzem, hogy kifejezetten erre a típusra készült: gigabites hálózat, beépített kapcsoló, és semmi olyan sallang, amire egyébként szükséged lenne valami általánosabb célú dologhoz (még kijelző kimenet sincs, csak soros konzol).

Bár a lap elég fiatal, mind az Armbian, mind az Arch Linux Arm támogatja a hardvert, és mindkét projekt remek munkát végez.Ha még nem fedezted fel a Linux világát ARM-en, akkor nem kell nagyon félned.Az Armbian és az Arch Linux Arm natívan biztosít mindent, amire az aarch64-hez szükséged van a disztribúciók repos-aiban, így kevés olyan dologba fogsz belefutni, ami idegenül hat egy 64 bites ARM chipen, és az biztos, hogy megéri, ha figyelembe veszed a hardver megfizethetőségét és az alacsony energiaigényt.

Itt van néhány kiemelkedő dolog számomra:

• A lapka tartalmaz egy beépített Topaz hálózati kapcsolót. Hálózati tesztjeim során a csak a LAN-interfészeken áthaladó forgalom sebesség szempontjából megkülönböztethetetlen egy vanília switchen áthaladó forgalomtól. Ha NAS-ról streamel, vagy egyébként magas követelményeket támaszt az eszközök közötti kommunikációval szemben, amely áthalad az útválasztón, ez nagy különbséget jelenthet.
• A soros konzol első osztályú állampolgár. Az én Raspberry Pimnél néha frusztrált voltam, hogy a HDMI-kijelzőmért kellett nyúlnom, amikor hibakeresést végeztem, de az espressobin rendelkezik egy mikro-USB soros porttal a konzol egyszerű eléréséhez.
• Az aarch64 chip nagyszerű volt. Nem csak, hogy mindent kezelt, amit hozzávágtam, de tudtad, hogy nem érinti a meltdown? A Cortex-A53 chipeket nem érinti a spekulatív végrehajtási hiba, szóval ez egy plusz bónusz.

Mi van a WiFi-vel?

Egy kis megjegyzés itt, hogy megpróbáltam az espressobint vezeték nélküli hozzáférési pontként is használni.A lapon van egy mini PCIe foglalat, ami jól használható egy vezeték nélküli kártyához, és bár működnie kellett volna, határozottan jelenthetem, hogy ez nem jó ötlet.

Fájdalmas részletekbe nem bocsátkozva, egy sor olyan probléma van, ami miatt nem éri meg az erőfeszítést. 5Ghz-es sávokat semmilyen forgatókönyv szerint nem tudtam működésre bírni, a 2,4Ghz-es hostapd szolgáltatásom körülbelül tizenkét óránként reagálatlanná vált, és a sebességek megdöbbentően rosszak voltak.

Általánosságban azt hiszem, ez az espressobin hardver hibája. olyan kártyák, amelyeknek egyébként jól támogatottnak kellene lenniük Linux alatt (néhány általam tesztelt kártya ath9k vagy ath10k alapú volt) egyszerűen nem működnek a kártya mPCIe interfészével.Még a hivatalosan ajánlott kártyákkal is voltak problémák – az RTL8191SE csak időszakosan működött, és még a Globalscale által gyártott kártya sem úgy működik, ahogyan azt hirdetik.Egyébként, ha találsz egy jól támogatott kártyát az espressobinon, kérlek, írj egy választ a kapcsolódó fórumtémára, amit a probléma megvitatására indítottam.

Mindezek mellett a projekt kezdetén az volt a szándékom, hogy elválasszam az AP-t a routeremtől, akár espressobin-t használok, akár nem.A tűzfal/útválasztás feladatainak a vezeték nélküli hálózattól való elkülönítése szépen elkülöníti az aggodalmakat, és nagyon jó dedikált AP-eszközöket lehet kapni, amelyek nem rendelkeznek semmilyen funkcióval a jelszó sugárzásán kívül, hogy egyszerű és erős maradjon.

Amiért érdemes, végül egy Ubiquity UniFi eszközt vásároltam, és teljesen elégedett voltam vele.

Kettedik rész: Szoftver

Itt két nagy választás van: OS és tűzfal szoftver.

Operating System

Az első választás az, hogy kézzel akarod-e ezt egy aarch64-et támogató disztribúcióból, vagy egy előre elkészített firmware-szerű megoldást, például az OpenWRT-t használod.Én személy szerint azt tapasztaltam, hogy valahányszor egy olyan zsugorított megoldást használok egy buildhez, mint a Tomato/OpenWrt vagy a FreeNAS, általában frusztrált leszek anélkül, hogy igazán bele tudnék nyúlni és finomhangolni a dolgokat, ezért egy általános célú Linux disztribúciót fogok használni az operációs rendszerhez.

Mint már említettem, az Armbian és az Arch Linux ARM támogatja a táblát, és az espressobin hivatalos dokumentációval rendelkezik az Ubuntu számára (valamint a Yocto, amelyet eddig nem ismertem).Bár nem fogom megmondani, hogy melyik a legjobb a te felhasználási esetedhez, itt van, hogy miért részesítettem előnyben az Arch Linux Arm-ot:

• Teljesen odavagyok a gördülő kiadású disztribúciókért.
• Az is odavagyok, hogy a vérző élvonalbeli disztribúciókat futtassam. Egy router esetében jó közel lenni az upstreamhez, amikor potenciálisan biztonsággal kapcsolatos frissítések jelennek meg.
• Az Arch egy tiszta lapot biztosít számunkra, amire építhetünk, mindenféle idegen szolgáltatások nélkül. Ez azt jelenti, hogy egy minimális bázissal pontosan tudhatjuk, hogy a darabok összerakása után mit fogunk telepíteni, kitenni és futtatni.
• Az Arch Linux ARM embereit ismerem és kedvelem. Szia WarheadsSE!

Firewall

Néhány név, mint például a PFSense azonnal eszembe jut, de nagyon szeretnék valamit Linuxon futtatni, mivel azt sokkal jobban ismerem, mint egy BSD-t (ráadásul az espressobin legjobb OS opciók Linux alapúak).

A Linux tűzfal tájkép elég széles. bár szinte biztos, hogy valami iptables-alapút fogunk használni, rengeteg magasabb szintű szolgáltatás van, ami az iptables tetején helyezkedik el (ufw, firewalld, stb.)Bár megírhatod a saját egyszerű iptables szabályrendszeredet, és mehetsz vele, én úgy döntöttem, hogy egy tűzfal szolgáltatást használok, mivel ezzel szép törzsi tudást szerzünk, amit a Linux közösség az iptables tűzfalakat kezelő sok év alatt fejlesztett ki.

Általában egy jó tűzfal démonnak:

• Az “egészséges OSS projekt” profilba kell illeszkednie. Ez azt jelenti, hogy aktívan karbantartottnak kell lennie, már egy ideje léteznie kell, és megfelelő elfogadottsággal kell rendelkeznie.
• Kerülje a bonyolultságot. Az egyszerű terveket könnyebb hibakeresni, bővíteni és üzemeltetni.
• Támogasson néhány jótékony funkciót, például a forgalom alakításának támogatását és a porttovábbítás egyszerű konfigurálását.

Egy ideig tartó nézelődés után a Shorewall mellett döntöttem.Íme néhány fontosabb ok, amiért ezt választottam:

• A konfigurációs folyamat a fordítás-utána-alkalmazás. Ez biztosítja, hogy a szabályrendszerünk épelméjű legyen, mielőtt alkalmaznánk, ami azt is jelenti, hogy nincs rezidens démon, amely az eszköz erőforrásait fogyasztja, ami egy kis egylapos számítógépen lényeges.
• Ez rengeteg szép történeti tudást tartalmaz, így a kiköpött iptables szabályok rengeteg olyan szélestörvényt kezelnek, amire normális esetben nem is gondolnánk.
• Ezzel később még többet fogok foglalkozni, de a csomagjelölés és a forgalom alakításának natív támogatása megkönnyíti az osztályos qdisek használatát.

Harmadik rész:

Ez a bejegyzés nem egy átfogó útmutatónak készült, de a főbb pontokat szerettem volna megadni, hogy látható legyen, milyen könnyű ezt összerakni.

OS telepítése

Ez egyszerű – csak kövesd az Arch Linux Arm espressobin oldalát. különösen fontos megjegyezni a hozzáadott zászlókat a mkfs.ext4 parancson és a további U-Boot konfigurációt.

OS Config

Az Arch Linux Arm telepítések általában már a kezdetektől fogva elég jól be vannak állítva.Természetesen be kell állítanod egy nem root felhasználót a rendszergazdához, ami nem az alapértelmezett fiók, ezért ne feledd letiltani a alarm felhasználót, megváltoztatni minden jelszót és frissíteni a rendszert.

Mellékesen megjegyzem, hogy nagyon ajánlom a pacmatic csomag telepítését és használatát a szokásos pacman helyett.Automatikusan észleli a konfigurációs fájlok frissítéseit, és segít egyesíteni őket, valamint beilleszti a fontos híreket a törő csomagok változásaihoz.

Az etckeeper beállítását javaslom továbbá a tűzfal konfigurációjának nyomon követésére (az Arch wikiben van egy jó bevezető).Én úgy állítottam be az enyémet, hogy automatikusan egy privát tárhelyű gitolite repóba tolja.Hogy teljesen őszinte legyek, nem kedvelem az összes létező konfigurációkezelő megoldást, és szinte minden változtatásunk a /etc-re korlátozódik, így ez legalábbis nekem elég jó backup megoldás.

Megjegyzem, hogy az espressobin alapértelmezett hálózati konfigurációja jól működik a router használati esethez:

• Mindkét lan interfész, lan0 és lan1, a br0 interfészre van áthidalva. Ez lehetővé teszi, hogy a magánhálózatra néző dolgokat, mint például a dnsmasq, egyetlen virtuális interfészen központosítsuk.
• A nyilvánosra néző interfész a wan. A címét a DHCP-n keresztül kapja az upstream ISP-től.

Az egyetlen változtatás, ami ahhoz szükséges, hogy a br0 és a wan beállítható legyen a routerünk számára, két kiegészítés: először is statikus IP-t kell rendelni a LAN-interfészhez, mivel ez lesz a router, és engedélyezni kell az IP-továbbítást és az IP-maszkírozást a /etc/systemd/network/br0.network-ben:

Address=192.168.1.1/24IPForward=ipv4IPMasquerade=yes

És annak megerősítése, hogy a WAN felé néző interfész kérjen címet az ISP-től a /etc/systemd/network/wan.network-ban:

DHCP=yesIPForward=ipv4UseDNS=no

A UseDNS=no-t itt állítottam be, mivel én inkább OpenNIC szervereket használok az upstream ISP-k helyett – később megemlítem, hol kell ezeket beállítani.

Firewall

Az Arch Linux ARM aarch64 tárolókban megtalálható a Shorewall legújabb verziója, amit én is használtam. az én konfigurációim nem túl fantáziadúsak, és ha komolyan fontolgatod a Shorewall telepítését a vad internetkapcsolattal, nagyon ajánlom, hogy olvasd el a Shorewall teljes bevezetését egy két interfészes tűzfalhoz.Ez lefedi az alapokat, hogyan kell beállítani a dolgokat egy szép összefoglalóval az útválasztásról és a tűzfalról általában.

Lényegében a br0 és wan interfészeket a megfelelő zónákba helyezzük, és a /etc/shorewall/rules-ban beállítjuk a szükséges szabályokat.Ne feledje, hogy a LAN-on lévő hosztok használhassák a DNS-kiszolgálót:

DNS(ACCEPT) loc $FW

A interfaces fájlban megerősíti, hogy a DHCP engedélyezett a LAN-interfészen.

Megjegyezném itt, hogy a tűzfal beállítása során beleütköztem egy hibába a Shorewallal, amit szó szerint előző nap találtam javítva – és az Arch Linux ARM már rendelkezett a frissített csomaggal az upstream tárolókban. egy pont a naprakész disztrók használatáért.

DHCP

a dnsmasq tökéletes választás egy otthoni routerhez. egy DNS és DHCP szervert foglal egy könnyű démonba, ami mindent kezel, amire egy kis hálózaton szükséged lehet, és elég érett ahhoz, hogy rengeteg dokumentáció van róla, ami pontosan erre a felhasználási esetre használja.

Note: Megpróbáltam használni a systemd beépített DHCP-kiszolgálóját, amelyet a .network fájlokban a DHCPServer=-vel állíthatsz be, mivel ez egy könnyű módnak tűnt egy DHCP-kiszolgáló futtatására extra szoftver nélkül.Anélkül, hogy túl bőbeszédű lennék, nem éri meg, az egyik jelentős ok, hogy nincs mód az aktuális címbérletek megtalálására.

Egy csomó opciót kell itt beállítani, de a legfontosabbak:

# 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

Ha statikus hozzárendelésekre vagy aliasokra van szükséged, ezeket is könnyű hozzáadni.

Negyedik rész: Közjáték

Az espressobin kiszolgálja a DHCP és DNS kéréseket a br0-en, tűzfalat épít a Shorewallon keresztül, és útválasztja a csomagokat a LAN és a WAN között, ez egy működő router.Ezen a ponton már csak a WAN portot kell csatlakoztatni az ISP upstream-hez és a két lan0/lan1 portot eszközökhöz vagy egy másik switchhez.

Ez azonban csak a kezdet.Ha valóban router-helyettesítőnek akarjuk tekinteni, akkor van néhány igazán klassz dolog, amit tehetünk, hogy tovább erősítsük a képességeit, hogy ne érezzük úgy, hogy ez egy downgrade valamihez képest, mint az én régi Asus N66U-m.

Ötödik rész:

A vaníliás espressobin routeremre a következő funkciókat csavaroztam rá, amelyeket sorra veszek:

• Netflow monitoring
• Traffic shaping

Netflow Monitoring

A forgalom láthatósága olyasmi, amit nagyon értékesnek találtam az Asus Merlin firmware-emmel a használat nyomon követéséhez.A Netflow a de facto szabvány az ilyesmire, és a rendelkezésre álló lehetőségek közül az ipt-netflowt nagyon kedvelem, mert ez egy natív kernel modul, így nagyon kevés az overhead, és nagyon aktívan karbantartják.

Kiderült, hogy valószínűleg én vagyok az első, aki aarch64 architektúrán használja, mert kaptam némi segítséget, hogy az aarch64 chipseten is támogatott legyen. a projekt karbantartója szuperül reagált (és reagál) a hibajavításokra, így nem volt semmi gondom azzal, hogy a modul a legújabb kerneleken is támogatott legyen, amelyeken az Arch Linux ARM projekt fut.

A használata az AUR-ból a ipt-netflow-dkms-git csomag telepítésével történik.A te kerneledhez fog épülni, mert a dkms félelmetes, és a következőket dobtam be a /etc/modules-load.d/ipt-netflow.conf

ipt_NETFLOW

Ez fogja betölteni, és a /etc/modprobe.d/ipt-netflow.conf-ben konfigurálod:

options ipt_NETFLOW destination=$ip:2055 protocol=5

Hol $ip a netflow célállomásod.Végül a forgalmat egy speciális iptables célpontba áramoltatva kapjuk el, amit közvetlenül a shorewallból is megtehetünk, kényelmesen.A /etc/shorewall/start:

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

Ez minden csomagot arra irányít a routeren, hogy először a NETFLOW célpontba kerüljön, mielőtt bármi másba, ami feldolgozza a csomagokat, és visszaadja őket, hogy a Shorewall által beállított normál szabályokon keresztül áramoljanak.

A ipt-netflow természetesen kell egy hely, ahová a netflow naplókat küldhetjük, de ez nem tartozik ennek a bejegyzésnek a tárgykörébe.Az én esetemben egy Logstash példány fut a hálózatomon, ahol a netflow modul fut, és az eseményeket egy Elasticsearch fürtben aggregálja. így kapok néhány kényelmes dashboardot, és sokféle információt tudok vizualizálni a hálózatomról.Van néhány alapértelmezett dashboard:

Beleértve néhány nagyon klasszat, például egy Geo-IP dashboardot:

Az engem leginkább érdeklő mérőszám azonban a teljes sávszélesség-felhasználásom, mert van egy antediluviánus internetszolgáltatóm, aki törődik az adatkorlátokkal.Szerencsére ez egyszerű az általam gyűjtött netflow-adatokkal: egyszerűen megkérhetjük az Elasticsearchet, hogy összegezzen néhány mezőt, és könnyen megkapjuk ezeket a mérőszámokat.A következő műszerfal két megjelenítést tartalmaz:

• A mérőszám összehasonlítja a kérdéses időszak összegét az ISP által számomra meghatározott felső határral, így könnyen láthatom, hogy a jelenlegi felhasználásom hol helyezkedik el a felső határhoz képest.
• A timeseries a sávszélességet bájtokban ábrázolja az időben, hogy lássam, mikor használom a sávszélességet.

Ezzel a beállítással kapcsolatban különösen jó, hogy mivel a netflow-mérőszámokat nem más adattárolóban vagy idősoros adatbázisban, hanem az Elasticsearchben tároljuk, a lekérdezéseket ezekre a műszerfalakra összpontosíthatom, hogy például csak bizonyos CIDR-tartományok összesített bájtjait összegezzem, mivel a mögöttes tárolómotor (Lucene) natívan érti az IP-címeket.Például a következő lekérdezés a Kibana-ban:

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

Ez hatékonyan kiszűri a potenciálisan nagy sávszélesség-tömegeket, amelyek a LAN-on lévő hosztok között történnek, például a Kodi host és a NAS-gépem közötti streaminget.Király.

Traffic Shaping

Ez egy elég hatalmas vállalkozássá vált, ami egy lenyűgöző nyúlüreg volt, amelyben eltűnt.Néhány stock és a legtöbb egyéni router firmware valamilyen formában kínál QoS-t vagy forgalomformázást, így reméltem, hogy ugyanezt megtehetem az egyéni routeremen, hogy megvédjem a forgalom egy részét (például az Overwatch-ot) a nagy késleltetéstől.

A QoS technológia világa lenyűgöző hely.Bár támaszkodhatsz néhány egyszerű sémára, például egy HTB (hierarchical token bucket) szűrőre, a csomagszűrés fejlődése meglepően aktív, és rengeteg érdekes megközelítés létezik.

Amire végül rátaláltam, az egy HFSC (hierarchical fair-service curve) szűrő volt.Őszinte leszek: a mögötte álló matematika annyira nem az én súlycsoportom, hogy több összefoglalót kellett elolvasnom, amelyek megpróbálták lebontani a normális emberek számára, és a legjobb magyarázat, amely értelmet adott számomra, egy kiváló gist volt, amelyre a GitHub felhasználó eqhmcow-tól bukkantam, amely elmagyarázza a HFSC előnyeit és használatát a gyakorlatban.

A tl;dr a következő: egy HFSC forgalomirányító osztállyal nagyon hatékonyan lehet priorizálni a forgalmat, és jó egyensúlyt lehet elérni a nagy sávszélességet és alacsony késleltetést igénylő adatfolyamok között. ez nem egy csodafegyver – még mindig meg kell jelölni, hogy milyen típusú forgalom érzékeny a késleltetésre – de nekem elég jól bevált.A szabályok nélkül a Steam vagy a Blizzard Launcher letöltése megöli a ping-időket, míg az aktív HFSC-szabályok kegyesen levágják a forgalom e nehéz részeit, hogy az interaktív streameket ne befolyásolja.Ez tényleg nagyszerű!

A fent említett gist jó munkát végez abban, hogyan kell beállítani a tc osztályokat a semmiből.A Shorewall azonban valóban képes natívan kezelni az osztályos forgalomszabályozást, így elég könnyen beállíthatunk erős QoS-szabályokat.A következő konfigurációs fájlok az általam mért sávszélességi sebességeken alapulnak, amelyek körülbelül 230 lefelé és 10 felfelé:

Az első lépés a megfelelő tc osztályok beállítása az egyes eszközökhöz a tcdevices fájlban:

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

Itt a LAN felé néző br0 interfész teljes gigabitet kap, de a WAN interfész wan a lefelé sebesség 97%-át és az elérhető felfelé sebesség 90%-át kapja.Ezeknek a számoknak az indoklása a lényegi résznél van elmagyarázva – lényegében ezt a szabályrendszert Shorewall-nyelven újraalkotjuk.

Következő lépésként határozzuk meg, hogy a csomagjelölések hogyan fognak megfeleltetni a tc osztályoknak a tcclasses fájlban:

# 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

Ez a fontos/interaktív forgalmat a magasabb prioritást kapó osztályokba dobja.Természetesen meg kell jelölnünk azokat a csomagokat is, amelyeknek ezt a magasabb prioritást kell kapniuk, ami a mangle-ben történik:

# 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

Ez beállítja a magas prioritású jelöléseket (1 és 2), amelyeket a tc osztályunk kezel. a példa ICMP pingeket, ssh-t, néhány Blizzard játékot és helyi forgalmat tartalmaz.

A shorewall újratöltésének ezeket kell életbe léptetnie.A végeredménynek lehetővé kell tennie az olyan tömeges forgalmat, mint a letöltések vagy streamek, miközben nem befolyásolja hátrányosan az interaktív forgalom késleltetését, mint az ssh, a játékon belüli ping-idők és így tovább.Az informális tesztjeim megerősítették ezt – vegye figyelembe, hogy ha úgy dönt, hogy maga ellenőrzi ezt, akkor a kezdeti tömeges forgalom után azonnal késleltetési csúcsokat figyelhet meg, de a HFSC gyorsan lép közbe, hogy korlátokat érvényesítsen, hogy az interaktív forgalom késleltetését alacsonyan tartsa.

Van néhány benchmarkom, amely a HFSC-t akcióban mutatja, de itt egy apró példa: hogyan befolyásolja a ping-késleltetést, ha az iperf a háttérben fut.

Amint látható, forgalomszabályozási szabályok nélkül a tömeges forgalom kitörései elég negatív hatással lehetnek a nagy késleltetésre érzékeny interaktív forgalomra.A HFSC-vel elkerülhetjük ezeket a problémákat.

Következtetés

Már több hónapja használom a saját fejlesztésű routeremet, és úgy tűnik, remekül működik.A folyamatos működés teljes időtartama alatt nem tapasztaltam semmilyen rejtélyes kapcsolatszakadást, sebességproblémát vagy hardverproblémát, így sikeresnek tartom az építést.A frissítések is rendben vannak; egy normál sudo pacmatic -Syu és újraindítás után a rendszer az összes iptables-szabállyal és egyéb szolgáltatással a vártaknak megfelelően újraindul, így a legújabb kernelek és egyéb csomagok frissítése egyszerű.

Összefoglalva:

• Egy üzemeltetéshez értő vagy műszaki beállítottságú személy számára egy egyéni router-építés nagyon is kivitelezhető. Az ARM egylapos számítógépek olcsón és kényelmesen kezelhetővé teszik a munkát.
• A tűzfal, a forgalom alakítása és a hálózatfelügyeletOSS-megoldásai kiforrottak és könnyen kezelhetőek. Különösen az olyan szépkorú megoldások, mint a Shorewall és a dnsmasq nagyon jól dokumentáltak, és sok évnyi munka van a dokumentációjukban és a funkciókészletükben.
• Míg az útválasztás + DNS + DHCP egy slam dunk, az OSS WiFi lehet találat vagy hiba. A te véleményed eltérhet, de az én espressobinom egyszerűen nem jó hozzáférési pont.