Jeg har bemærket en tendens på det seneste. I stedet for at udskifte en router, når den bogstaveligt talt holder op med at fungere, har jeg været nødt til at handle tidligere – jeg har været nødt til at udskifte nyt udstyr, fordi en gammel router ikke længere kunne følge med de stigende internethastigheder, der er tilgængelige i området. (Bemærk, jeg er behørigt taknemmelig for dette problem.) Som det seneste eksempel har en hel flok Netgear ProSafe 318G-routere svigtet mig for sidste gang, da små virksomheder har opgraderet fra 1,5-9mbps traditionelle T1-forbindelser til 50mbps coax (kabel).
Ja, coax-ikke fiber. Selv coax har vist sig at være for meget for den gamle ProSafe-serie. Disse enheder kunne ikke bare ikke følge med, de faldt helt til jorden. Ofte tabte de gamle routere hastighedstestresultater fra 9mbps med den gamle forbindelse til 3mbps eller mindre med 50mbps-forbindelsen. Det er klart, at det ikke fungerer.
I disse dage ser svaret i stigende grad ud til at være trådløse routere. Disse har en tendens til at være lange på smart udseende plastik og farvestrålende webgrænseflader, men korte på tekniske funktioner og pålidelighed. Hvad skal en lejesoldat sysadmin gøre? I bund og grund kan alt med to fysiske netværksgrænseflader være en router. Og i dag findes der masser og masser af relativt hurtige, billige og (super vigtigt!) fuldt ud solid-state generiske bokse derude.
Så, tiden var endelig kommet. Stillet over for aldrende hardware og nye forbrugertilbud, der ikke opfyldte mine behov, besluttede jeg mig for at bygge min egen router. Og hvis dagens morphing konnektivitetslandskab efterlader dig i en lignende situation, viser det sig, at både bygningen og opbygningen er ret hurtig.
Hvorfor gøre det på den hårde måde
En masse af jer mumler sikkert: “Okay, pfSense, selvfølgelig.” Nogle af jer tænker måske endda på smoothwall eller untangle NG. Jeg har leget med de fleste af de firewall-distroer derude, men jeg besluttede mig for at gå mere grundlæggende, mere gammeldags: en almindelig, CLI-only installation af Ubuntu Server og et par iptables-regler.
Ganske vist er dette sandsynligvis ikke den mest praktiske tilgang for alle læsere, men det gav mening for mig. Jeg har en hel del erfaring med at finpudse iptables og selve Linux-kernen til høj gennemstrømning på internetskala, og jo færre skinnende funktioner og grafik og klikkende ting, der sættes mellem mig og firewallbordet, jo mindre fluff skal jeg få af vejen, og jo færre nye ikke anvendelige-i-resten-af-mit-arbejde-ting skal jeg lære. Enhver regel jeg allerede ved hvordan jeg skal oprette i iptables for at styre adgangen til mine servere, ved jeg også hvordan jeg skal anvende på min firewall – hvis min firewall kører den samme distro som mine servere gør.
Også arbejder jeg ret meget med OpenVPN, og jeg vil gerne kunne fortsætte med at opsætte både dets servere og klienter på den måde jeg allerede er afhængig af. Nogle firewall-distributioner har OpenVPN-understøttelse indbygget og andre har ikke, men selv dem med indbygget har en tendens til at forvente, at tingene skal køre anderledes end jeg gør. Igen, jo mere systemet holder sig ude af min vej, jo gladere vil jeg være.
Som en ekstra bonus ved jeg, at jeg meget nemt kan holde alting helt opdateret på min nye og helt vanilla Ubuntu-router. Det hele er understøttet direkte af Canonical, og det hele kan (og har) automatisk opdatering slået til. Tilføj lejlighedsvis et cron job til at genstarte routeren (for at få nye kerner), og så er jeg golden.
Hardware, hardware, hardware, hardware
Vi gennemgår hvordan i et senere stykke, men i dag er det vigtigt at fastslå, hvorfor et DIY router-byggeri måske er den bedste løsning. For at gøre det er du først nødt til at forstå dagens generelle landskab.
I forbrugerverdenen har routere for det meste itty-bitty-bitty små MIPS CPU’er under kølerhjelmen uden en hel masse RAM (for at sige det mildt). Disse routere adskiller sig stort set fra hinanden på baggrund af grænsefladen: Hvor skinnende er den? Hvor mange tekniske funktioner har den? Kan brugerne nemt finde ud af det?
I den højere ende af SOHO-markedet begynder man at se nogle ARM-CPU’er i smartphone-klasse og en masse mere RAM. Disse routere – som f.eks. Nightgear Nighthawk-serien, hvoraf vi vil hamre på en af dem senere – er udstyret med flere kerner, højere clockhastigheder og en hel del mere RAM. De har også meget højere prisskilte end de billigere konkurrenter. Jeg købte en Linksys EA2750 til 89 dollars, men den Netgear Nighthawk X6, som jeg fik med, var næsten tre gange så dyr (selv på feriesalg!) til 249 dollars.
Selvfølgelig ville jeg alligevel gå en anden vej. En masse interessante og rimeligt billige små x86-64-maskiner uden blæser er begyndt at dukke op på markedet på det seneste. Tricket med at bygge en router er at finde en med flere NIC’er. Du kan finde et par ret sikre bud på Amazon, men de er ældre Atom-baserede processorer, og jeg ville have en nyere Celeron. Efter lidt god gammeldags internetsøgning og tøven på internettet tog jeg endelig Alibaba-springet og bestilte mig en ny Partaker Mini PC fra Shenzhen Inctel Technology Company. Efter 240 dollars for selve routeren og yderligere 48 dollars for en 120 GB Kingston SSD fra Newegg havde jeg brugt ca. 40 dollars mere på Homebrew Special, end jeg havde brugt på Nighthawk. Ville det være det værd?
En udfordrer dukker op
Hvor vi går i gang med testen, skal vi lige tage et hurtigt visuelt kig på konkurrenterne.
Denne Nighthawk er, sammenlignet med de andre, STOR og imponerende (endnu mere end billedet får den til at se ud). Den er faktisk betydeligt større end min Homebrew Special, som er en fuldt funktionsdygtig pc til generelle formål, som du kan bruge som et helt kompetent skrivebord. Det er som om DC Comics bad H.R. Giger om at give en hånd med at designe en trådløs router til Batman.
Homebrew Special i sig selv er ret bedårende. Den har en blå og en rød lysdiode inde i kabinettet, og om aftenen strømmer lyset fra begge dele indirekte ud af køleventilerne, hvilket giver netværksstacken et festligt festligt udseende. Hvis der var nogen blæsere, der kunne forårsage et flimmer, ville det drive mig til vanvid, men da det er et stabilt, blødt lys, kan jeg faktisk godt lide det.
Linksys og Buffalo ligner derimod præcis det, de er – billige routere. Det er dog værd at bemærke, at stilen på Linksys er en stor forbedring i forhold til mærkets fortid. Den ligner mere noget professionelt og mindre som et børnelegetøj. (Men nok om stilen – det er tid til at sætte disse stakkels routere gennem handsken.)
Den oplagte første udfordring er en simpel båndbreddetest. Du sætter en computer på LAN-siden og en computer på WAN-siden, og du kører et smart lille værktøj kaldet iperf gennem midten. Simpelt, ikke sandt?
Jamen, det ville give en kort og kedelig artikel. Selve netværket måler gigabit, de tre gigabit-routere måler gigabit, og 100 megabit-routeren måler 100 megabit.
I virkeligheden begynder en så simpel test ikke engang at fortælle historien. Den eneste grund til at lave den er måske for at vise, hvor meningsløs den er. Routerproducenterne bliver mere og mere opmærksomme på at folk faktisk tester deres produkt, og ingen producent ønsker at deres produkt skal ligge andre steder end i toppen af noget som smallnetbuilders routertabel. I lyset heraf er producenterne aktivt på jagt efter stats i disse dage.
Problemet er, at stats er bare stats. At kunne ramme et højt tal på en ren gennemstrømningstest er bedre end ingenting, men det er langt fra hele historien. Jeg lærte den lektie på den hårde måde, da jeg arbejdede for en T-1-leverandør i begyndelsen af 2000’erne. Deres ekstremt dyre Adtran-modemmer kunne fint håndtere 50-100 personers normale internetforbrug, men en enkelt bruger, der kørte Limewire eller en anden P2P-klient, ville få det hele til at gå ned med et snuptag. (Løsningen dengang var at sætte en billig, men fantastisk Netopia-router til 150 dollars foran det dyre Adtran-modem. Problemet var løst.)
Selv ved relativt simpel routing – ingen dyb pakkeinspektion, ingen streaming malware-scanning eller indtrængningsdetektion, ingen formning – er både CPU’en og den RAM, routeren har til rådighed, vigtige langt ud over evnen til at mætte internetforbindelsen. Peer-to-peer-filudveksling er den mest brutale aktivitet, et netværk kan opleve i dag (uanset om det er bittorrent, en af Gnutella- eller eDonkey-varianterne eller et spilfirmas peer-to-peer-downloadsystem). Jeg var færdig med at spille WoW, da Blizzards P2P-distributionssystem blev indført, men det var min daværende værelseskammerat ikke. På lanceringsdagen var det nye WoW peer-downloadsystem ubehjælpeligt nok standardiseret til ingen throttling overhovedet. Det forsøgte lystigt at finde og opretholde forbindelser med bogstaveligt talt tusindvis af klienter på samme tid, og mit hjemmenetværk gik ned som Gilbert Godfried, der blev tacklet af Terry Tate. Min værelseskammerat og jeg havde ord.
Baseret på sådanne tidligere erfaringer vil jeg ikke bare minimalt “teste” mine udfordrere og kalde det en dag, jeg vil virkelig give dem sved på panden. Så for at gøre det vil jeg give dem arbejdsbyrder, der lægger vægt på tre problemområder: at mætte netværksforbindelsen, at oprette og afbryde individuelle TCP/IP-forbindelser meget hurtigt og at holde et stort antal individuelle TCP/IP-forbindelser åbne på samme tid.
Jeg har et botnet i lommen, og jeg er klar til at rocke det
Jeg overvejede kortvarigt at opsætte et eller andet hæsligt, Docker-drevet monstrum med titusindvis af Linux-containere med individuelle IP-adresser, der alle skriger efter forbindelser og/eller serverer websider. Så kom jeg til fornuft. Hvad angår routerne, er der ingen forskel på at opretholde forbindelser til tusindvis af individuelle IP-adresser eller blot til tusindvis af porte på den samme IP-adresse. Jeg brugte lidt tid på at forvandle Lee Hutchinsons yndlingswebserver nginx til et latterligt Lovecraftiansk monster med 10.000 hoveder og en appetit på ødelæggelse.
For hver router brugte jeg ApacheBench til at teste downloading af en jpeg med tre forskellige filstørrelser (10K, 100K og 1M) ved fire forskellige concurrency-niveauer (10, 100, 1.000 og 10.000 samtidige klienter). Det giver os i alt 12 tests, når vi ikke medregner vores indledende iperf-test, og det er værd at se dem alle som en slags spektrum.
I de fleste henseender er den 10K-fil mere udfordrende. Den lille filstørrelse betyder, at du kan levere langt flere af de enkelte filer hvert sekund, før du mætter grænsefladen, hvilket betyder, at du skal oprette og afbryde langt flere TCP-forbindelser, hvilket er belastende for routerens CPU. På den anden side betyder 1M-filen, at du er garanteret at holde flere forbindelser åbne på de højere samtidighedsniveauer. Det er værd at se, hvordan routerne håndterer hele spektret, fordi hvert niveau gør et ret fornuftigt stykke arbejde med at modellere en ret almindelig udfordring, som en router kan være nødt til at håndtere (downloading eller afsendelse af et stort antal e-mails, håndtering af peer-to-peer-fildeling eller generel webbrowsing fra mange brugere), hvis det tages til et ekstremt niveau.
I sidste ende endte det med, at jeg ikke kun måtte tune nginx, men også selve Linux-kernen for pålideligt at kunne levere den form for gennemløb, jeg søgte. Selve routerne er “stock” – selv min Homebrew Special blev ikke tunet – men testserverne, Menhir og Monolith (hver med AMD FX-8320 8-core CPU, 32 GB DDR3 RAM og Ubuntu Trusty OS, der er patchet helt op til dato) havde brug for nogle ret seriøse masseringer for at kunne håndtere den slags belastning.
Med så meget galskab vil du gerne sikre dig, hvad dine faktiske servere og netværk er i stand til, før du drager forhastede konklusioner om routere, du sætter imellem dem. Til at begynde med testede jeg først Menhir alene på localhost-grænsefladen (intet netværk overhovedet) og testede derefter mellem serverne kun på tværs af min netværksswitch (en Netgear ProSafe 16-port gigabit, hvis du skulle undre dig).
Resultaterne for localhost kunne ikke have været bedre – langt, langt højere gennemløb end gigabit for hver test. Faktisk var jeg nødt til manuelt at begrænse skalaen på grafens Y-akse, ellers ville du have svært ved at se de rigtige tests overhovedet. Testen af det direkte netværk var ikke så slem, men vi er tydeligvis begyndt at ramme nogle grænser i den øvre ende. Jeg er ikke sikker på, om det er selve switchen eller de indbyggede netværksinterfaces i begge servere, der har problemer, men der er noget, der ikke helt lever op til udfordringen. Det er dog godt nok til at arbejde med. Tid til endelig at sætte routerne i gang.
Lad os gøre os klar til at rumble!
Jeg var lidt nervøs. Jeg følte mig allerede ret kærlig over for min lille homebrew-enhed – jeg har jo trods alt selv bygget den. Jeg vidste, at den nemt ville dominere den ældre Buffalo, som jeg gravede op af en skuffe, og Linksys’en, som bogstavelig talt var den billigste ting i Staples med et gigabit-interface. Men kunne den slå den laserguidede atomdamphammer af en Nighthawk? Det troede jeg, men jeg var ikke sikker.
Når download-testene var færdige, var der ikke flere spørgsmål om Homebrew Special. Ja, den kunne slå Nighthawk … og gå gabende væk bagefter. Bortset fra et lille dyk på niveauet 10K filstørrelse/10 samtidige forbindelser (som udfordrer CPU’en med de absolut fleste oprettede og afbrudte forbindelser), klarede den sig næsten identisk med selve den direkte netværksforbindelse.
Nighthawk er i øvrigt virkelig en fantastisk SOHO-router, som jeg har indsat en hel del af. Den faldt dog af næsten med det samme. For megabyte downloads 10 ad gangen, var det hals og hoved. Med nogen mere udfordring begyndte ydelsen at skride kraftigt nedad.
Linksys’en klarede sig, ingen overraskelse, slet ikke godt. Selv en så simpel opgave som at downloade 10 filer på samme tid reducerede dens gennemstrømning til næsten halvdelen af, hvad den naive iperf-test viste. Det blev kun værre derfra, og den undlod endda at gennemføre flere tests. På den positive side gør Linksys et godt stykke arbejde med at demonstrere, at din router virkelig betyder noget.
Endeligt fortjener den tapre lille bøffel at blive hyldet. På trods af at den kostede mindre end Linksys’en da den var helt ny (for otte år siden, vel at mærke) og at den har ligget i en skrivebordsskuffe i fem år, så kom den ned fra den berømte barstole og slog faktisk Linksys’en i halvdelen af testene. Buffalo havde denne succes på trods af en netværksgrænseflade, der var vurderet til en tiendedel af hastigheden. Det er modigt. Næste gang nogen tager en billig stikning til nyligt afbudsrejste, kinesisk fremstillede produkter, vil jeg råbe: “Husk Buffalo!”
Hvor man drager nogen konklusioner, skal der dog tages højde for upload-hastighederne.
Glædeligt nok er der ikke rigtig ændret noget i forhold til relationerne mellem routerne her. Homebrew’en ser stadig ud som om den slet ikke er der, idet den næsten helt matcher en direkte netværksforbindelse. Nighthawk fortsætter med at dominere Linksys fuldstændigt, og den skrabede lille Buffalo gør stadig sit forældede bedste. I absolutte tal kan man se, at både Nighthawk og Linksys klarer sig lidt bedre på upload end de gjorde på download, men det er ikke noget at skrive hjem om. Denne bundlinje er stadig den samme: Homebrew Special holder trit med netværket (mærkeligt nok klarer den sig endda bedre end en direkte forbindelse i testen med 10.000 forbindelser/10K filer), Nighthawk er klart sin pris værd i forhold til Linksys, og Linksys er, ja, billig.
Med denne sidste graf har vi dog et nyt sæt resultater – de laksefarvede søjler, som ligger ret stabilt på lidt over 200mbps på tværs af grafen. Det er Homebrew Special, der spiller med sine kryptomuskler. Den har en OpenVPN-server kørende. I denne test er serveren på WAN-siden, Menhir, forbundet med routerens indbyggede OpenVPN-server. Trafikken til LAN-siden af Homebrew Special bliver dirigeret over VPN-tunnelen, så Menhir rammer LAN-IP-adressen på Monolith (LAN-sidens server) ved hjælp af en ret imponerende 2048-bit SSL-baseret kryptering. I betragtning af at ingen tilbyder internetforbindelser over 200 mbps i mit område endnu, får det min indre kryptonørd til at danse af glæde. Jeg kunne bogstaveligt talt kryptere hver eneste byte af min internettrafik, i begge retninger, uden at det ville gå ud over ydeevnen.
En hurtig afsluttende advarsel
Så imponerende som min lille Homebrew Special er, er der én ting, den mangler, hvilket alle tre andre deltagere tilbyder: trådløs adgang. Jeg kunne tilføje et trådløst kort til Homebrew’en og få den til at servere trådløst, men på nuværende tidspunkt har jeg ingen planer om det. Jeg er alt for bekendt med hvad der findes af trådløse kort til PC’er, og de stinker alle sammen på is. Selv billige enheder som Linksys eller Buffalo ville levere et smæk for trådløs dækning og rækkevidde, og Nighthawk er ikke engang i samme liga. Det er virkelig en laserstyret atomisk damphammer, når det gælder trådløs rækkevidde, dækning og samtidig tilslutningsmuligheder. (Jeg har en af dem, der dækker 50+ brugere i et 53.000 kvadratmeter stort anlæg fra hjørne til hjørne lige nu.)
Når det er sagt, er der intet, der forhindrer dig i at bruge en separat WAP (Wireless Access Point) udelukkende til at varetage Wi-Fi-opgaver. I mit hus er det et par Ubiquiti “hockey puck” WAP’er, en for hver etage i huset. De er lidt mere besværlige at administrere end Nighthawk, men et par af dem koster halvt så meget. De er ret standard Linux-enheder, som man kan SSH’e direkte ind på, og de styres fra en ret cool lille webapplikation, som man kan køre… du gættede det, direkte på Homebrew Special. (At migrere Ubiquiti Server fra min arbejdsstation til Homebrew Special bliver en af mine første opgaver efter dette stykke, og jeg vil derefter fremme den til aktiv brug foran mit netværk på hjemmekontoret.)
I grundighedens navn bør vi observere en fælles begrænsning, noget ved alt forbrugernetværksudstyr, som jeg nogensinde har administreret: ønsket om at genstarte efter næsten enhver ændring. Nogle af disse genstarter tager langt over et minut. Jeg har ikke den fjerneste anelse om hvorfor, men uanset hvad årsagen er, så er Homebrew Special ikke ramt af denne industristandard. Du foretager en ændring, du anvender den, og så er du færdig. Og hvis du har brug for at genstarte Special’en? Så er den oppe igen på 12 sekunder. (Jeg tog tid ved at tælle tabte pings.)
Så hvis tallene har påvirket dig, og du ønsker at bygge din egen Homebrew Special, er det eneste, der kræves, en pc med to fysiske netværksinterfaces. Det kan være en speciel mini-pc som den jeg har brugt her, eller det kan være en hvilken som helst gammel kasse du har liggende, som du kan proppe to netværkskort ind i. Lad dig ikke skræmme af det første skærmbillede. At bygge din egen virkelig hurtige router er ikke så svært at få styr på. Og hvis du skriger efter en køreplan, vil vi faktisk snart skitsere processen hele vejen fra “her er en almindelig computer” til “her er en router, og her er hvordan du konfigurerer den”.
Jim Salter (@jrssnet) er forfatter, taler, ejer af en lille virksomhed, lejesoldat-systemsadmin og far til tre – ikke nødvendigvis i den rækkefølge. Han fik sin første rigtige smagsprøve på open source ved at køre Apache på sin helt egen dedikerede FreeBSD 3.1-server tilbage i 1999, og han har været en ivrig fortaler for FOSS lige siden. Han har også oprettet og vedligeholder http://freebsdwiki.net og http://ubuntuwiki.net.