Jag har lagt märke till en trend på sistone. I stället för att byta ut en router när den bokstavligen slutar fungera har jag behövt agera tidigare – jag har bytt ut en ny utrustning eftersom en gammal router inte längre kunde hålla jämna steg med de ökande internethastigheterna i området. (Observera att jag är tacksam för detta problem.) Som det senaste exemplet svek ett helt gäng Netgear ProSafe 318G-routrar mig för sista gången när småföretag har uppgraderat från traditionella T1-anslutningar med 1,5-9 mbps till koax (kabel) med 50 mbps.
Ja, koax – inte fiber. Även koax har visat sig vara för mycket för den gamla ProSafe-serien. Dessa enheter misslyckades inte bara med att hålla jämna steg, de föll platt till marken. Ofta sänkte de gamla routrarna hastighetstestresultaten från 9 mbps med den gamla anslutningen till 3 mbps eller mindre med 50 mbps-anslutningen. Det är uppenbart att det inte fungerar.
I dessa dagar verkar svaret i allt högre grad vara trådlösa routrar. Dessa tenderar att vara långa på snygg plast och färgglada webbgränssnitt men korta på tekniska funktioner och tillförlitlighet. Vad ska en legosoldat som sysadmin göra? I grund och botten kan allt som har två fysiska nätverksgränssnitt vara en router. Och idag finns det massor av relativt snabba, billiga och (superviktigt!) helt solid-state generiska lådor där ute.
Så, tiden hade äntligen kommit. Inför åldrande hårdvara och nya konsumenterbjudanden som inte uppfyllde mina behov bestämde jag mig för att bygga min egen router. Och om dagens föränderliga anslutningslandskap gör att du befinner dig i en liknande situation, visar det sig att både byggandet och byggandet går ganska snabbt.
Varför göra det på det svåra sättet
En hel del av er mumlar antagligen: ”Visst, pfSense, visst”. Några av er kanske till och med tänker på smoothwall eller untangle NG. Jag lekte med de flesta av de brandväggsdistros som finns där ute, men jag bestämde mig för att gå mer grundläggande, mer gammaldags: en vanlig, endast CLI-installation av Ubuntu Server och några iptables-regler.
Det här är visserligen troligen inte det mest praktiska tillvägagångssättet för alla läsare, men det kändes vettigt för mig. Jag har en hel del erfarenhet av att finjustera iptables och själva Linuxkärnan för hög genomströmning i Internetskala, och ju färre glänsande funktioner och grafik och klickande saker som sätts mellan mig och brandväggsbordet, desto mindre flum måste jag få bort och desto färre nya saker som inte är tillämpliga i resten av mitt arbete måste jag lära mig. Alla regler som jag redan vet hur man skapar i iptables för att hantera åtkomsten till mina servrar vet jag också hur man tillämpar på min brandvägg, om min brandvägg kör samma distro som mina servrar.
Också, jag jobbar ganska mycket med OpenVPN, och jag vill kunna fortsätta att ställa in både dess servrar och klienter på det sätt som jag redan litar på. Vissa brandväggsdistributioner har OpenVPN-stöd inbyggt och andra inte, men även de som har inbyggt tenderar att förvänta sig att saker och ting ska fungera på ett annat sätt än vad jag gör. Återigen, ju mer systemet håller sig ur min väg, desto gladare blir jag.
Som en extra bonus vet jag att jag mycket enkelt kan hålla allting helt uppdaterat på min nya och helt vanilla Ubuntu-router. Allt stöds direkt av Canonical och alla kan (och har) automatiska uppdateringar aktiverade. Lägg till ett och annat cronjobb för att starta om routern (för att få nya kärnor), så är jag nöjd.
Hårdvara, hårdvara, hårdvara
Vi kommer att gå igenom hur man gör i en framtida artikel, men idag är det viktigt att fastställa varför ett självbyggeri av en router kan vara det bästa alternativet. För att göra det måste du först förstå dagens allmänna landskap.
I konsumentvärlden har routrar för det mesta smått och gott MIPS- CPU:er under huven utan särskilt mycket RAM-minne (för att uttrycka det milt). Dessa routrar skiljer sig till stor del från varandra baserat på gränssnittet: Hur glänsande är det? Hur många tekniska funktioner har den?
I den övre delen av SOHO-marknaden börjar man se ARM-CPU:er i smartphone-klass och mycket mer RAM. Dessa routrar – som Nightgear Nighthawk-serien, varav vi kommer att hamra på en av dem senare – har flera kärnor, högre klockfrekvenser och en hel del mer RAM. De har också mycket högre prislappar än de billigare konkurrenterna. Jag köpte en Linksys EA2750 för 89 dollar, men Netgear Nighthawk X6 som jag fick med den var nästan tre gånger dyrare (till och med på julförsäljning!) på 249 dollar.
Så ville jag ändå gå en annan väg. En hel del intressanta och rimligt billiga små x86-64 fläktlösa maskiner utan fläkt har börjat dyka upp på marknaden den senaste tiden. Tricket för att bygga en router är att hitta en med flera NIC:er. Du kan hitta ett par ganska säkra satsningar på Amazon, men de är äldre Atom-baserade processorer och jag ville ha en nyare Celeron. Efter en del gammaldags Internet-sökande och tvekan tog jag till slut steget till Alibaba och beställde mig en ny Partaker Mini PC från Shenzhen Inctel Technology Company. Efter 240 dollar för själva routern och ytterligare 48 dollar för en 120 GB Kingston SSD från Newegg hade jag spenderat ungefär 40 dollar mer på Homebrew Special än vad jag hade spenderat på Nighthawk. Skulle det vara värt det?
En utmanare dyker upp
Innan vi sätter igång med testerna ska vi ta en snabb visuell titt på konkurrenterna.
Denna Nighthawk är, i jämförelse med de andra, STOR och imponerande (ännu mer än vad bilden får den att verka). Den är faktiskt betydligt större än min Homebrew Special, som är en fullt fungerande dator för allmänna ändamål som du kan använda som ett fullt kompetent skrivbord. Det är som om DC Comics bad H.R. Giger att hjälpa till att designa en trådlös router för Batman.
Homebrew Special i sig själv är ganska bedårande. Den har en blå och en röd lysdiod inuti höljet, och på natten sprider sig ljuset från båda indirekt ut ur kylventilerna, vilket ger nätverksstacken ett festligt partyutseende. Om det fanns några fläktar som skulle orsaka ett flimmer skulle det driva mig till vansinne, men eftersom det är ett stabilt mjukt sken gillar jag det faktiskt.
Linksys och Buffalo, å andra sidan, ser ut som exakt vad de är – billiga routrar. Det är dock värt att notera att stilen på Linksys är en stor förbättring jämfört med varumärkets förflutna. Den ser mer ut som något professionellt och mindre som en barnleksak. (Men nog om stilen – det är dags att sätta dessa stackars routrar genom handsken.)
Den uppenbara första utmaningen är ett enkelt bandbreddstest. Man sätter en dator på LAN-sidan och en dator på WAN-sidan och kör ett smart litet verktyg som heter iperf genom mitten. Enkelt, eller hur?
Ja, det skulle ge en kort och tråkig artikel. Själva nätverket mäter gigabit, de tre gigabitroutrarna mäter gigabit och 100-megabitroutern mäter 100 megabit.
I själva verket börjar ett så enkelt test inte ens berätta hela historien. Den enda anledningen till att göra det kan vara att visa hur meningslöst det är. Tillverkare av routrar blir mer och mer medvetna om att folk faktiskt testar deras produkter, och ingen tillverkare vill att deras produkt ska hamna någon annanstans än i toppen av något som smallnetbuilders routertabell. I ljuset av detta jagar tillverkarna aktivt statistik nuförtiden.
Problemet är att statistik bara är statistik. Att kunna nå en hög siffra i ett rent genomströmningstest är bättre än ingenting, men det är långt ifrån hela sanningen. Jag lärde mig den läxan på det hårda sättet när jag arbetade för en T-1-leverantör i början av 2000-talet. Deras extremt dyra Adtran-modem kunde hantera 50 till 100 personers normala Internetanvändning utan problem, men en enda användare som körde Limewire eller någon annan P2P-klient skulle få hela systemet att gå omkull på ett ögonblick. (Lösningen på den tiden var att sätta en billig men fantastisk Netopia-router för 150 dollar framför det dyra Adtran-modemet. Problemet löst.)
Även för relativt enkel routning – ingen djupgående paketinspektion, ingen streaming av skadlig kod eller intrångsdetektering, ingen formning – är både CPU:n och det RAM-minne som routern förfogar över viktigt långt utöver förmågan att mätta Internetlänken. Fildelning från peer-to-peer är ungefär den mest brutala aktivitet som ett nätverk kan uppleva nuförtiden (oavsett om det är bittorrent, någon av Gnutella- eller eDonkey-varianterna eller ett spelföretags peer-to-peer-nedladdningssystem). Jag hade slutat spela WoW när Blizzards P2P-distributionssystem introducerades, men det gjorde inte min rumskamrat på den tiden. På lanseringsdagen var det nya peer-download-systemet för WoW ohjälpligt nog standardiserat till att inte ha någon strypning alls. Det försökte glatt att hitta och upprätthålla anslutningar med bokstavligen tusentals klienter samtidigt, och mitt hemnätverk gick ner som Gilbert Godfried som blev tacklad av Terry Tate. Min rumskamrat och jag hade ord.
Baserat på sådana tidigare erfarenheter vill jag inte bara minimalt ”testa” mina utmanare och sluta för dagen, jag vill verkligen få dem att svettas. Så för att göra det kommer jag att ge dem arbetsuppgifter som betonar tre problemområden: att mätta nätverkslänken, att skapa och bryta enskilda TCP/IP-anslutningar mycket snabbt och att hålla ett stort antal enskilda TCP/IP-anslutningar öppna samtidigt.
Jag har ett botnät i fickan, och jag är redo att rocka det
Jag funderade kort på att sätta upp något slags ohyggligt, Docker-drivet monster med tiotusentals Linuxcontainrar med individuella IP-adresser, som alla skriker efter anslutningar och/eller serverar webbsidor. Sedan kom jag till sans. När det gäller routrarna är det ingen skillnad mellan att upprätthålla anslutningar till tusentals enskilda IP-adresser eller bara till tusentals portar på samma IP-adress. Jag ägnade lite tid åt att förvandla Lee Hutchinsons favoritwebserver nginx till ett löjligt Lovecraftianskt monster med 10 000 huvuden och en aptit på förstörelse.
För varje router använde jag ApacheBench för att testa att ladda ner en jpeg med tre olika filstorlekar (10K, 100K och 1M) vid fyra olika concurrency-nivåer (10, 100, 1 000 och 10 000 samtidiga klienter). Detta ger oss totalt 12 tester, utan att räkna med vårt inledande iperf-test, och det är värt att se dem alla som ett slags spektrum.
I de flesta avseenden är den där 10K-filen mer utmanande. Den lilla filstorleken innebär att du kan leverera mycket mer av de enskilda filerna varje sekund innan du mättar gränssnittet, vilket innebär att du måste göra och bryta mycket fler TCP-anslutningar, vilket är ansträngande för routerns CPU. Å andra sidan innebär 1M-filen att du garanterat kommer att hålla fler anslutningar öppna på de högre samtidighetsnivåerna. Det är värt att se hur routrarna hanterar hela spektrumet, eftersom varje nivå gör ett ganska bra jobb med att modellera en ganska vanlig utmaning som en router kan behöva hantera (nedladdning eller sändning av ett stort antal e-postmeddelanden, hantering av peer-to-peer fildelning, eller allmänt surfande på webben från många användare) om den tas till en extrem nivå.
I slutändan behövde jag inte bara trimma nginx utan även själva Linuxkärnan för att på ett tillförlitligt sätt kunna leverera den typ av genomströmning som jag var ute efter. Routrarna i sig är ”stock” – även min Homebrew Special lämnades oreglerad – men testservrarna, Menhir och Monolith (var och en med AMD FX-8320 8-core CPU, 32GB DDR3 RAM och Ubuntu Trusty OS som är helt uppdaterad) behövde en ganska seriös massagebehandling för att kunna hantera den typen av belastning.
Med så mycket galenskap vill du försäkra dig om vad dina faktiska servrar och nätverk klarar av innan du drar några slutsatser om routrar som du placerar mellan dem. Till att börja med testade jag först Menhir själv på gränssnittet localhost (inget nätverk alls) och testade sedan mellan servrarna över endast min nätverksswitch (en Netgear ProSafe 16-port gigabit, om du undrar).
Resultaten för localhost kunde inte ha varit bättre – långt, långt högre genomströmning än gigabit för varje test. Faktum är att jag var tvungen att manuellt begränsa skalan på grafens Y-axel, annars hade du haft svårt att se de riktiga testerna överhuvudtaget. Testet av det direkta nätverket var inte alltför dåligt, men vi börjar uppenbarligen stöta på vissa gränser i den övre delen. Jag är inte säker på om den kämpande komponenten är själva switchen eller de inbyggda nätverksgränssnitten i båda servrarna, men något klarar inte helt av utmaningen. Det är dock tillräckligt bra att arbeta med. Dags att äntligen koppla in routrarna.
Då är det dags att göra sig redo att mullra!
Jag var lite nervös. Jag kände mig redan ganska tillgiven för min lilla hemmabyggda enhet – jag har ju trots allt byggt den själv. Jag visste att den lätt skulle dominera den äldre Buffalo som jag grävde fram ur en låda och Linksys, som bokstavligen var den billigaste saken på Staples med ett gigabitgränssnitt. Men skulle den kunna slå den laserguidade atomiska ångbombaren av en Nighthawk? Jag trodde det, men jag var inte säker.
När nedladdningstesterna var klara fanns det inga fler frågor om Homebrew Special. Ja, den kunde slå Nighthawk… och gå därifrån gäspande efteråt. Bortsett från en liten dipp vid nivån 10K filstorlek/10 samtidiga anslutningar (vilket utmanar processorn med absolut flest gjorda och avbrutna anslutningar) presterade den nästan identiskt med själva den direkta nätverksanslutningen.
Nighthawken är för övrigt verkligen en fantastisk SOHO-router som jag har satt in en hel del av. Den föll dock bort nästan omedelbart. För megabyte nedladdningar 10 åt gången var det hals och hals. Med något mer av en utmaning började prestandan att luttra kraftigt.
Den Linksys, ingen överraskning, presterade inte alls bra. Till och med en så enkel uppgift som att ladda ner 10 filer samtidigt sänkte dess genomströmning till nästan hälften av vad det naiva iperf-testet visade. Det blev bara värre därifrån och den misslyckades med att ens slutföra flera tester. På den positiva sidan gör Linksys ett bra jobb för att visa att din router verkligen spelar roll.
Till sist förtjänar den tappra lilla buffeln att få en eloge. Trots att den kostade mindre än Linksys när den var helt ny (för åtta år sedan, märk väl) och att den har legat i en skrivbordslåda i fem år, kom den ner från den ordspråksmässiga barstolen och slog faktiskt Linksys i hälften av testerna. Buffalo hade den framgången trots ett nätverksgränssnitt som var klassat för en tiondel av hastigheten. Det är modigt. Nästa gång någon gör ett billigt försök att få fram färska kinesiska produkter från båten kommer jag att ropa ”Kom ihåg Buffalo!”
För att kunna dra några slutsatser måste dock uppladdningshastigheterna räknas in.
Glckligtvis har inget riktigt förändrats i relationerna mellan routrarna här. Homebrew ser fortfarande ut som om den inte ens finns där, och matchar nästan helt och hållet en direkt nätverksanslutning. Nighthawk fortsätter att helt och hållet dominera Linksys, och den skrotlika lilla Buffalo gör fortfarande sitt föråldrade bästa. I absoluta tal kan man se att både Nighthawk och Linksys gör något bättre ifrån sig vid uppladdning än vid nedladdning, men det är inget att skriva hem om. Den här slutresultatet förblir detsamma: Homebrew Special håller jämna steg med nätverket (märkligt nog klarar den sig till och med bättre än en direktanslutning i testet med 10 000 anslutningar/10 000 filer), Nighthawk är helt klart värd sin prislapp jämfört med Linksys, och Linksys är, tja, billig.
Med den här sista grafen har vi dock en ny uppsättning resultat – de laxfärgade staplarna, som ligger ganska stabilt på drygt 200 mbit/s över hela grafen. Det är Homebrew Special som spänner sina kryptomuskler. Den har en OpenVPN-server igång. För det testet är servern på WAN-sidan, Menhir, ansluten till routerns inbyggda OpenVPN-server. Trafiken för LAN-sidan av Homebrew Special leds över VPN-tunneln, så Menhir når LAN-IP-adressen för Monolith (servern på LAN-sidan) med hjälp av en ganska imponerande 2048-bitars SSL-baserad kryptering. Med tanke på att ingen erbjuder Internetanslutningar över 200 mbit/s i mitt område ännu, får detta min inre kryptonörd att dansa av glädje. Jag skulle bokstavligen kunna kryptera varenda byte av min internettrafik, i båda riktningarna, utan att det skulle innebära någon prestandaförlust.
En snabb avslutande varning
Och hur imponerande min lilla Homebrew Special än är, så finns det en sak som den saknar, och som alla tre andra tävlande erbjuder: trådlös åtkomst. Jag skulle kunna lägga till ett trådlöst kort till Homebrew och få den att servera trådlöst, men för närvarande har jag inga planer på det. Jag är alltför bekant med vad som finns tillgängligt för trådlösa PC-kort, och de stinker alla på is. Till och med billiga enheter som Linksys eller Buffalo skulle leverera en smackdown när det gäller trådlös täckning och räckvidd, och Nighthawk är inte ens i samma liga. Det är verkligen en laserstyrd atomisk ångbom när det gäller trådlös räckvidd, täckning och samtidig uppkoppling. (Jag har en av dem som täcker 50+ användare i en anläggning på 53 000 kvadratmeter från hörn till hörn just nu.)
Med detta sagt finns det inget som hindrar dig från att använda en separat WAP (Wireless Access Point) enbart för att sköta Wi-Fi-uppgifterna. I mitt hus är det ett par Ubiquiti ”hockey puck” WAPs, en för varje våning i huset. De är lite mer jobbiga att hantera än Nighthawk, men ett par av dem kostar hälften så mycket. De är ganska vanliga Linux-enheter som man kan SSH:a direkt in i och som hanteras från ett ganska coolt litet webbprogram som man kan köra… du gissade det, direkt på Homebrew Special. (Att migrera Ubiquiti-servern från min arbetsstation till Homebrew Special kommer att bli en av mina första uppgifter efter det här stycket, och jag kommer sedan att befordra den till aktiv användning framför mitt nätverk på hemmakontoret.)
I noggrannhetens namn bör vi observera en gemensam begränsning, något som finns hos alla konsumentnätverksutrustningar som jag någonsin har hanterat: önskan att starta om efter nästan alla förändringar. Vissa av dessa omstarter tar långt över en minut. Jag har inte den blekaste aning om varför, men oavsett orsaken är Homebrew Special inte drabbad av denna industristandard. Du gör en ändring, du tillämpar den, du är klar. Och om du behöver starta om Special? Den är igång igen på 12 sekunder. (Jag tog tid genom att räkna tappade pings.)
Så om siffrorna har påverkat dig, och du vill bygga din egen Homebrew Special, är allt som krävs en dator med två fysiska nätverksgränssnitt. Det kan vara en speciell minidator som den jag använde här, eller så kan det vara vilken gammal låda som helst som du har liggande och som du kan klämma in två nätverkskort i. Låt dig inte skrämmas av den första skärmdumpen. Att bygga en egen riktigt snabb router är inte så svårt att få grepp om. Och om du skriker efter en färdplan kommer vi faktiskt att beskriva processen hela vägen från ”här är en vanlig dator” till ”här är en router och så här konfigurerar du den” inom kort.
Jim Salter (@jrssnet) är författare, talare, småföretagare, legosoldat-sysadmin och pappa till tre barn – inte nödvändigtvis i den ordningen. Han fick sitt första riktiga smakprov på öppen källkod genom att köra Apache på sin egen dedikerade FreeBSD 3.1-server 1999, och han har varit en ivrig förespråkare av FOSS ända sedan dess. Han har också skapat och underhåller http://freebsdwiki.net och http://ubuntuwiki.net.
.