Tyblog

” Bygga min ideala router för 50 dollar ”

Efter att min Asus N66U hade fått sparken, funderade jag på några alternativ: Jag tänkte på följande: en annan allt-i-ett-router, uppgradera till något som en EdgeRouter eller göra något eget.När jag läste Ars Technica-artikeln som förespråkade fördelarna med att bygga en egen router, var det ganska enkelt: Jag har något av ett psykologiskt komplex när det gäller att skapa mina egna överkonstruerade lösningar, men jag satte upp några allmänna mål: slutresultatet ska vara billigt, strömsnålt, ha bra stöd av Linux och vara utbyggbart. ARM-kort passar för övrigt in på många av dessa krav, och vissa, som Raspberry Pi, har skapat så mycket aktivitet i samhället att det finns ett stort stöd för ARM-plattformen, även om den kan kännas främmande jämfört med x86.

Jag har lyckats pussla ihop en enhet som inte bara är skitbillig för vad den gör, utan som också är extremt kapabel i sig. Om du är intresserad av att bygga din egen hemmarouter ska jag här visa att det inte bara är genomförbart, utan också relativt lätt att göra och att det erbjuder en enorm mängd användningsområden – från trafikformning, till nätflödesövervakning och dynamisk DNS.

Jag byggde den med hjälp av espressobin, Arch Linux Arm och Shorewall.

Denna bild visar kretskortet inneslutet i ett 3d-tryckt hölje.Tyvärr är espressobin inte tillräckligt populär för att kunna skryta med ett brett utbud av köpbara höljen som Raspberry Pi har, men det finns en del bra modeller för 3d-tryckning.

Som en sidoanmärkning är följande dokumentation inte tänkt som en omfattande steg-för-steg-guide för att göra samma sak själv.Även om jag vill täcka många av de val som gick in i byggandet, bör konfigurering av något så viktigt som en router/brandvägg verkligen inte vara ett kopiera/klistra in jobb och skulle bättre vara löst guidad av stegen här med en grundlig förståelse för hur och varför.

• Varför
• Första delen: Hårdvara
  • Hur är det med WiFi?
• Andra delen: Mjukvara
  • Driftssystem
  • Firewall
• Tredje delen: Grundläggande uppbyggnad
  • OS Install
  • OS Config
  • Firewall
  • DHCP
• Del fyra: Intermezzo
• Del fem: Uppgraderingar
  • Netflow Monitoring
  • Traffic Shaping
• Slutsats

Varför

Det finns gott om solida routrar där ute som du kan köpa och som inte är ISP-däckbrännare från lager och som förmodligen skulle vara mer än lämpliga (jag tittar kärleksfullt på dig, EdgeRouter Lite).Så varför bry sig om allt detta?Det finns några legitima fördelar här:

• Det är faktiskt mycket prisvärt. Min router har klarat mina benchmarks med bravur och har alla funktioner som jag kan få in från Linux (vilket är en lång lista).
• Det är säkert. Det känns som om en ny sårbarhet tillkännages för någon konsumentnätverksenhet varje månad. Jämför det med en självstyrande brandvägg och jag vet exakt vilka tjänster som är exponerade (och om iptables är trasig har världen större problem). För eventuella skeptiker: Den enda port som lyssnar på min brandvägg är en slumpmässigt högt numrerad port för ssh-autentisering med endast offentlig nyckel. Så ja, jag tror verkligen att den är säkrare än någon Huawei-konsumentrouter.
• Den har fantastiska funktioner. Visst, min espressobin kan dirigera och fungera som brandvägg, men jag har lagt in några andra användbara funktioner också.
• Den är effektiv. I de mindre benchmarks jag utförde kan espressobin verkligen driva trafik utan att svettas.
• Det var verkligen roligt att bygga. Om du a) behöver en ny router eller b) vill sätta tänderna i ett ARM-projekt med ett enda kort kan det här passa bra.

Del ett: Hårdvara

Tekniskt sett skulle du kunna sätta ihop en router med hjälp av vilken dator som helst med två NIC:er, men vi kan göra lika bra ifrån oss med mindre kraft, en mindre formfaktor och till ett billigare pris.ARM-kretsar träffar rätt: de är superbilliga, kraftfullare än man kan tro och har bra stöd med så många varianter på marknaden.

Den mest välkända utmanaren är Raspberry Pi, men utan två NIC:er eller gigabit-nätverk är det inte ett bra alternativ.Dessutom betalar du för saker som en GPU som inte är nödvändiga i en huvudlös nätverksenhet.

De goda nyheterna är att förra året släpptes espressobin, och den är superduglig.Den känns specialbyggd för den här typen av saker: gigabit-nätverk, en inbyggd switch och inga krusiduller som du annars skulle behöva för något mer allmängiltigt (det finns inte ens en displayutgång, bara en seriell konsol).

Även om kortet är ganska ungt har både Armbian och Arch Linux Arm stöd för hårdvaran, och båda projekten gör ett bra jobb med det.Om du inte har utforskat Linux på ARM finns det inte så mycket att frukta här.Armbian och Arch Linux Arm tillhandahåller allt du behöver för aarch64 nativt i distributionens repos, så det är inte mycket du kommer att stöta på som känns främmande på ett 64-bitars ARM-chip, och det känns verkligen värt det när du tar hänsyn till att hårdvaran är överkomlig och att den har ett lågt effektuttag.

Här är några av höjdpunkterna för mig:

• Kortet innehåller en inbyggd Topaz-nätverksswitch. I mina nätverkstester är trafik som bara passerar LAN-gränssnitten omöjlig att skilja hastighetsmässigt från trafik som passerar genom en vanilla-switch. Om du streamar från en NAS eller på annat sätt har höga krav på kommunikation mellan enheter som passerar routern kan detta göra stor skillnad.
• Den seriella konsolen är en första klassens medborgare. På mina Raspberry Pis blev jag ibland frustrerad över att behöva sträcka mig efter min HDMI-skärm när jag felsökte problem, men espressobin har en seriell mikro-USB-port för enkel åtkomst till konsolen.
• Aarch64-chippet har varit fantastiskt. Det har inte bara klarat allt jag har kastat på det, utan visste du att det är opåverkat av meltdown? Cortex-A53-chipen påverkas inte av felet med spekulativ exekvering, så det är en extra bonus.

Hur är det med WiFi?

Jag ska göra en liten notering här om att jag försökte använda espressobin som en trådlös åtkomstpunkt också.Kretskortet har en mini-PCIe-plats som är väl lämpad för ett trådlöst kort, och även om det borde ha fungerat, kan jag definitivt rapportera att det inte är en bra idé.

Och utan att gå in i smärtsamma detaljer finns det en mängd problem som inte gör det värt besväret. jag kunde inte få 5Ghz-banden att fungera under något scenario, min 2,4Ghz hostapd-tjänst blev okontaktbar var tolfte timme eller så, och hastigheterna var chockerande dåliga.

I allmänhet tror jag att detta är ett misslyckande för espressobin-hårdvaran. kort som annars borde ha bra stöd i Linux (några av korten jag testade var ath9k- eller ath10k-baserade) fungerar helt enkelt inte med kortets mPCIe-gränssnitt.Till och med de officiellt rekommenderade korten hade problem – RTL8191SE fungerade intermittent, och till och med kortet som produceras av Globalscale fungerar inte som annonserat.För övrigt, om du hittar ett kort med bra stöd på espressobin, var snäll och skriv ett svar på den relaterade forumtråden som jag startade för att diskutera den här frågan.

Med allt detta sagt var min avsikt i början av det här projektet att separera min AP från min router, oavsett om jag till slut använde en espressobin eller inte.Att hålla uppgifterna för brandväggar/dirigering åtskilda från det trådlösa är en trevlig åtskillnad av bekymmer, och du kan få mycket bra dedikerade AP-enheter utan någon funktion utöver att sända ut en signal för att hålla det enkelt och kraftfullt.

För vad det är värt slutade jag med att köpa en Ubiquity UniFi-enhet och har varit helt nöjd med den.

Del två: Mjukvara

Det finns två stora val här: Det första valet att göra är om du vill handrulla detta från en distribution som har stöd för aarch64 eller använda en förbyggd firmware-liknande lösning som OpenWRT.Personligen har jag upptäckt att när jag använder en krympt lösning som Tomato/OpenWrt eller FreeNAS för ett bygge blir jag oftast frustrerad utan att riktigt kunna gå in och finjustera saker och ting, så jag kommer att använda en allmängiltig Linuxdistribution för operativsystemet.

Som jag nämnde tidigare har Armbian och Arch Linux ARM stöd för kortet, och espressobin har officiell dokumentation för Ubuntu (liksom Yocto, som jag inte kände till förrän nu).Även om jag inte kommer att tala om för dig vilket som är bäst för ditt användningsområde, så här är varför jag föredrog Arch Linux Arm:

• Jag är helt och hållet såld på distributioner med rullande utgåvor.
• Jag är också såld på att köra på topp blödande cutting-edge-distributioner. När det gäller en router är det trevligt att vara nära uppströms när potentiellt säkerhetsrelaterade uppdateringar släpps.
• Arch kommer att ge oss en ren skiffer att bygga på utan några främmande tjänster. Detta innebär att vi, med en minimal bas, kan veta exakt vad vi kommer att ha installerat, exponerat och kört efter att ha satt ihop bitarna.
• Jag känner och gillar Arch Linux ARM-folket. Hej WarheadsSE!

Firewall

Några namn som PFSense kommer jag genast att tänka på, men jag skulle verkligen vilja köra något på Linux eftersom jag känner till det mycket bättre än en BSD (plus att de bästa operativsystemsalternativen för espressobin är Linuxbaserade).

Linux brandväggslandskap är ganska brett. även om vi nästan säkert kommer att använda något iptables-baserat, finns det gott om tjänster på högre nivå som sitter ovanpå iptables (ufw, firewalld, etc.).) Även om du skulle kunna skriva din egen enkla iptables-regelsamling och fortsätta med det, valde jag att använda en brandväggstjänst eftersom vi på så sätt får en del trevlig stamkunskap som Linuxgemenskapen har utvecklat under de många år som de har hanterat iptables-brandväggar.

En bra brandväggsdemon bör generellt sett:

• Passa in i profilen för ett ”hälsosamt OSS-projekt”. Detta innebär att den bör underhållas aktivt, ha funnits ett tag och ha en hyfsad acceptans.
• Undervika komplexitet. Enkla konstruktioner är lättare att felsöka, utöka och använda.
• Stöd för vissa funktioner som är trevliga att ha, t.ex. stöd för trafikformning och enkel konfiguration av portforwarding.

Efter att ha snokat runt ett tag bestämde jag mig för Shorewall.Här är några av de mer anmärkningsvärda anledningarna till att jag valde den:

• Konfigurationsflödet är kompilera-och-så-tillämpa. Detta säkerställer att vår regeluppsättning är sund innan den tillämpas, vilket också innebär att det inte finns någon resident daemon som förbrukar enhetens resurser, vilket är relevant på en liten enbordsdator.
• Den kommer med massor av trevlig historisk kunskap inbyggd, så iptables-reglerna som spottas ut hanterar massor av kantfall som du normalt sett inte skulle tänka på.
• Jag kommer att täcka mer av detta senare, men paketmarkering och inbyggt stöd för trafikformning gör klassmässiga qdiscs enkla.

Del tre: Det här inlägget är inte tänkt att vara en omfattande guide, men jag ville inkludera de breda punkterna så att det är uppenbart hur lätt det här är att sätta ihop.

OS-installation

Det här är enkelt – följ bara Arch Linux Arm espressobin-sidan.Det är särskilt viktigt att notera de tillagda flaggorna på mkfs.ext4-kommandot och den extra U-Boot-konfigurationen.

OS Config

I allmänhet är Arch Linux Arm-installationer ganska väl inställda från början.Naturligtvis vill du konfigurera en icke-root-användare att administrera med som inte är standardkontot, så kom ihåg att inaktivera alarm-användaren, ändra alla lösenord och uppdatera systemet.

Som en sidoanteckning kan jag starkt rekommendera att du installerar pacmatic-paketet och använder det i stället för vanliga pacman.Det kommer automatiskt att upptäcka uppdateringar av konfigurationsfiler och hjälpa till att sammanfoga dem, samt inline viktiga nyheter för brytande paketändringar.

Därutöver föreslår jag att du ställer in etckeeper för att spåra din brandväggskonfiguration (Arch-wikin har en bra introduktion).Jag ställde in min så att den automatiskt pushar till en gitolite-repo med privat värdskap.För att vara helt ärlig så ogillar jag alla lösningar för konfigurationshantering som finns, och nästan alla våra ändringar är begränsade till /etc, så det här är en tillräckligt bra backup-lösning åtminstone för mig.

Notera att standardnätverkskonfigurationen för espressobin fungerar bra för routerns användningsfall:

• Båda langränssnitten, lan0 och lan1, är bryggade till br0-gränssnittet. På så sätt kan vi centralisera saker som är vända mot det privata nätverket, t.ex. dnsmasq, på ett enda virtuellt gränssnitt.
• Det offentliga gränssnittet är wan. Det hämtar sin adress från uppströms-ISP:n via DHCP.

De enda ändringar som krävs för att få br0 och wan inställda för vår router är två tillägg: för det första att tilldela LAN-gränssnittet en statisk IP eftersom det kommer att vara routern, och att aktivera IP-forwarding och IP-masquerading i /etc/systemd/network/br0.network:

Address=192.168.1.1/24IPForward=ipv4IPMasquerade=yes

Och bekräfta att WAN-gränssnittet kommer att begära en adress från ISP:n i /etc/systemd/network/wan.network:

DHCP=yesIPForward=ipv4UseDNS=no

Jag ställer in UseDNS=no här eftersom jag föredrar att använda OpenNIC-servrar i stället för min uppströms-ISP:s – jag nämner var du ska ställa in dessa senare.

Firewall

Arch Linux ARM aarch64 repositories har fått den senaste versionen av Shorewall, vilket är vad jag använde mig av. Mina konfigurationer är inte så avancerade, och om du seriöst överväger att använda Shorewall med en anslutning till det vilda internet rekommenderar jag starkt att du läser hela Shorewalls introduktion till en brandvägg med två gränssnitt.Den täcker grunderna för hur du ska ställa in saker och ting med en trevlig sammanfattning av routing och brandväggar i allmänhet.

I grund och botten ska du sätta br0– och wan-gränssnittet i rätt zoner och ställa in eventuella nödvändiga regler i /etc/shorewall/rules.Kom ihåg att låta värdar på ditt LAN använda din DNS-server:

DNS(ACCEPT) loc $FW

Du bekräftar att DHCP är tillåtet på LAN-gränssnittet i filen interfaces.

Jag noterar här att jag stötte på en bugg med Shorewall under min brandväggsinstallation som jag upptäckte att den var korrigerad bokstavligen dagen innan – och Arch Linux ARM hade redan det uppdaterade paketet i uppströmsförråden.En poäng för att använda uppdaterade distributioner.

DHCP

dnsmasq passar perfekt för en hemrouter. den samlar ihop en DNS- och DHCP-server i en lättviktig daemon som hanterar allt du behöver för ett litet nätverk, och den är tillräckligt mogen för att det finns gott om dokumentation som använder den för just det här användningsfallet.

Note: Jag försökte använda systemd:s inbyggda DHCP-server som du kan ställa in med DHCPServer= i .network-filer, eftersom det verkade vara ett lättviktigt sätt att köra en DHCP-server utan extra mjukvara.Utan att vara alltför utförlig är det inte värt det, en viktig orsak är att det inte finns något sätt att hitta aktuella adressuthyrningar.

Det finns många alternativ som bör ställas in här, men de viktigaste är:

# 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

Om du behöver statiska tilldelningar eller alias är dessa lätta att lägga till också.

Del fyra: Intermezzo

Med espressobin som betjänar DHCP- och DNS-förfrågningar på br0, brandväggar via Shorewall och dirigerar paket mellan LAN och WAN är det en fungerande router. vid det här laget är det enda som behövs att ansluta WAN-porten till ISP:n uppströms och de två lan0/lan1-portarna till enheter eller en annan switch.

Det är dock bara en början.Om vi verkligen vill betrakta det här som en routerersättning finns det några riktigt häftiga saker vi kan göra för att ytterligare förbättra dess kapacitet så att det inte känns som en nedgradering från något som min gamla Asus N66U.

Del fem: Uppgraderingar

Jag bultade på följande funktioner till min vanilla espressobin-router, som jag kommer att behandla i tur och ordning:

• Nätflödesövervakning
• Trafikformning

Nätflödesövervakning

Trafiköversikt är något som jag tyckte var riktigt värdefullt med min fasta programvara Asus Merlin för att spåra användningen.Netflow är de facto-standarden för den här typen av saker, och bland alla tillgängliga alternativ gillar jag verkligen ipt-netflow eftersom det är en inhemsk kärnmodul så det finns väldigt lite overhead och den underhålls väldigt aktivt.

Det visar sig att jag förmodligen är den första personen som använder den på aarch64-arkitekturen, eftersom jag fick hjälp med att få stöd för den på aarch64-chipset. projektets underhållare var (och har varit) superresponsiv på buggfixar, så jag har inte haft några problem med att se till att modulen stöds på de senaste kärnorna som Arch Linux ARM-projektet körs på.

Att använda den är en fråga om att installera paketet ipt-netflow-dkms-git från AUR.Det kommer att byggas för din kärna eftersom dkms är grymt bra, och jag släppte följande i /etc/modules-load.d/ipt-netflow.conf

ipt_NETFLOW

Det laddar den, och du konfigurerar den i /etc/modprobe.d/ipt-netflow.conf:

options ipt_NETFLOW destination=$ip:2055 protocol=5

Varvid $ip är din netflow destination.Slutligen fångas trafiken upp genom att flöda in i ett speciellt iptables-mål, vilket kan göras direkt från shorewall, på ett bekvämt sätt.I /etc/shorewall/start:

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

Detta styr alla paket på routern att först gå in i NETFLOW-målet innan något annat, som bearbetar paketen och skickar dem tillbaka för att flödet ska passera genom de normala reglerna som Shorewall sätter upp.

Självklart behöver ipt-netflow en plats att skicka nätflödesloggar till, men det ligger utanför ramen för det här inlägget.I mitt fall har jag en Logstash-instans som körs på mitt nätverk med netflow-modulen som körs och aggregerar händelser i ett Elasticsearch-kluster, vilket ger mig några bekväma instrumentpaneler och möjlighet att visualisera en mängd olika typer av information om mitt nätverk.Det finns några standardinstrumentpaneler:

Inklusive några ganska häftiga, som en Geo-IP dashboard:

Det mest relevanta måttet jag är intresserad av är dock min totala bandbreddsanvändning eftersom jag har en antediluviansk internetleverantör som bryr sig om datakrav.Lyckligtvis är det enkelt med de nätflödesdata jag samlar in: vi kan bara be Elasticsearch att summera några fält och få fram dessa mätvärden på ett enkelt sätt.Följande instrumentpanel har två visualiseringar:

• Mätaren jämför summan under tidsperioden i fråga med det tak som min internetleverantör har satt upp för mig, så att jag enkelt kan se var min nuvarande användning ligger i förhållande till taket.
• Tidsserien visar bandbredd i byte över tiden för att se när jag använder den bandbredden.

Något särskilt häftigt med den här konfigurationen är att eftersom vi lagrar nätflödesmätvärdena i Elasticsearch i stället för i någon annan datalager- eller tidsseriedatabas kan jag faktiskt fokusera förfrågningarna för de här instrumenttavlorna så att jag kan göra saker som att bara summera totala bytes för vissa CIDR-områden, eftersom den underliggande lagringsmotorn (Lucene) förstår IP-adresser.Till exempel följande fråga i Kibana:

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

Filtrerar effektivt bort potentiellt stora mängder bandbredd som sker mellan värdar på mitt LAN, till exempel streaming mellan min Kodi värd och min NAS-maskin.Coolt.

Traffic Shaping

Det här blev ett ganska stort åtagande som var ett fascinerande kaninhål att försvinna in i.Vissa standardprogram och de flesta anpassade routerfirmwares erbjuder någon form av QoS eller trafikformning, så jag hoppades kunna göra detsamma på min anpassade router för att skydda en del av min trafik (som Overwatch) från höga latenstider.

Världen för QoS-teknik är en fascinerande plats.Även om man kan förlita sig på några enkla system som ett HTB-filter (hierarchical token bucket) är utvecklingen inom paketfiltrering förvånansvärt aktiv och det finns många intressanta tillvägagångssätt.

Det jag slutligen bestämde mig för var ett HFSC-filter (hierarchical fair-service curve).Jag ska vara ärlig: matematiken bakom det är så pass oöverskådlig att jag var tvungen att läsa flera sammanfattningar som försökte bryta ner den för normala människor, och den bästa förklaringen som var vettig för mig var en utmärkt gist som jag snubblade över från GitHub-användaren eqhmcow som förklarar fördelarna med och användningen av HFSC i praktiken.

Tl;dr är detta: med en HFSC-trafikstyrningsklass kan du mycket effektivt prioritera trafik och uppnå en bra balans mellan strömmar som kräver hög bandbredd och låg latens. det är ingen magisk kula – du måste fortfarande markera vilka typer av trafik som är latenskänsliga – men det har fungerat ganska bra för mig.Utan reglerna på plats kommer en nedladdning av Steam eller Blizzard Launcher att ta död på ping-tiderna, medan aktiva HFSC-regler kommer att skära ner dessa tunga delar av trafiken på ett elegant sätt för att se till att interaktiva strömmar inte påverkas.Det är verkligen bra!

Den tidigare nämnda gisten gör ett bra jobb med att lägga ut hur du ställer in dina tc-klasser från början.Men Shorewall kan faktiskt hantera klassvis trafikstyrning nativt, så vi kan ställa in kraftfulla QoS-regler ganska enkelt.Följande konfigurationsfiler är baserade på mina uppmätta bandbreddshastigheter, som är ungefär 230 nedåt och 10 uppåt.

Det första steget är att ställa in relevanta tc-klasser för varje enhet i tcdevices-filen:

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

Här får LAN-gränssnittet br0 full gigabit, men WAN-gränssnittet wan får 97 % av sin nedåtgångshastighet och 90 % av min tillgängliga uppåtgångshastighet.Resonemanget för dessa siffror förklaras i kärnan – vi återskapar i huvudsak denna regeluppsättning i Shorewall-termer.

Nästan definierar du hur paketmarkeringar ska mappas till tc klasser i tcclasses-filen:

# 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

Detta kommer att släppa viktig/interaktiv trafik till klasser som får högre prioritet.Naturligtvis måste vi också markera de paket som ska få den högre prioriteringen, vilket görs i 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

Detta ställer in de högprioriterade markeringarna (1 och 2) som hanteras av vår tc-klass.Exemplet inkluderar ICMP-pings, ssh, vissa Blizzard-spel och lokal trafik.

Reloading shorewall bör sätta dessa i kraft. slutresultatet bör tillåta bulktrafik som nedladdningar eller strömmar utan att negativt påverka latenstiden för interaktiv trafik som ssh, ping-tider i spel och så vidare. mina informella tester har bekräftat detta – observera att om du bestämmer dig för att verifiera detta själv, kan du observera latensspikar omedelbart efter en inledande explosion av bulktrafik, men HFSC ingriper snabbt för att genomdriva gränser för att hålla latenstiderna låga för interaktiv trafik.

Jag har ett par uppsättningar benchmarks som visar HFSC i aktion, men här är ett litet exempel: hur pinglatensiteten påverkas när iperf körs i bakgrunden.

Som du kan se, utan några regler för trafikkontroll, kan utbrott av bulktrafik ha ganska negativa effekter på interaktiv trafik som är känslig för höga latenstider. med HFSC kan vi undvika dessa problem.

Slutsats

Jag har använt min hemmabyggda router i flera månader nu och den verkar fungera utmärkt.Jag har inte upplevt några mystiska anslutningsavbrott, hastighetsproblem eller hårdvaruproblem under hela perioden av kontinuerlig drift, så jag skulle betrakta byggandet som en framgång.Uppgraderingar går också bra; efter en normal sudo pacmatic -Syu och omstart kommer systemet tillbaka online med alla iptables-regler och andra tjänster som förväntat, så att hålla sig uppdaterad med de senaste kärnorna och andra paket är okomplicerat.

För att sammanfatta:

• För en driftskunnig eller tekniskt lagd person är ett eget routerbygge mycket görbart. ARM-enkortsdatorer gör det billigt och bekvämt att komma igång.
• OSS-lösningar för brandväggar, trafikformning och nätverksövervakning är mogna och lätta att arbeta med. Framför allt är finföråldrade lösningar som Shorewall och dnsmasq mycket väldokumenterade och många års arbete har lagts ner på deras dokumentation och funktionsuppsättning.
• Men medan routing + DNS + DHCP är en slam dunk kan OSS WiFi vara en hit or miss. Din erfarenhet kan variera, men min espressobin är helt enkelt inte en bra åtkomstpunkt.